神兽道游大厅集合版：棋牌H5开源源码的搭建与运维指南

简介：整套《神兽道游大厅集合版》棋牌类开源H5源码，面向从零学习游戏开发与服务器运维的初学者，覆盖前端界面、后端逻辑、数据库设计、部署及维护全流程。资源包共2000个文件，约171.77MB，以737个HTML、331个JS、311个CSS和313个PNG等前端资源为主，配合209个PHP后端文件、26个DB与2个SQL数据库文件，以及TXT/MD说明文档和部署脚本，目录结构清晰，可按模块对照学习，已有907人学习。教程文件夹和程序介绍会引导完成Node.js与Web服务器环境配置、数据库初始化及源码调试；数据库部分涵盖了用户信息、游戏记录、道具分数等常用表结构，便于理解数据持久化。深入源码可学习玩家请求处理、数据验证与状态同步机制，同时掌握SQL注入防范、性能优化和日志分析等维护技能。对希望获得可运行项目、系统掌握H5游戏前后端全流程的初学者而言，是一份不可多得的实战资料。

1. 神兽道游大厅集合版是什么：一套不是一键安装的棋牌H5开放源码

棋牌类开源H5源码其实不少，但大多数拆开只有一个游戏页，没有大厅、没有服务端，跑起来还要自己补一堆协议。神兽道游大厅集合版是少见的把“大厅+多个游戏子应用+服务端+运营后台”打包在一起的开源H5源码，前端用浏览器直接打开，后端负责房间、用户态和牌局流程。它解决的是从零搭建棋牌平台时最费时间的部分：登录、房间列表、匹配开局、中途状态同步，这些都写好了，你要做的是读懂它，然后换皮、加玩法、部署上线。适合有Linux和Node.js基础的开发者、想研究棋牌H5长连接通信的进阶学习者，以及需要快速出技术原型的小团队。注意它不是一键安装包，集群方案、安全加固、机房网络这些生产环境功课都得另外补，后面几章按选型、搭建、配置、排坑的顺序把这条路趟完。

2. 选型先看清架构：LayaBox前端、Node游戏服与Redis/MySQL的分工

动手之前先把项目技术选型读明白。很多搭建翻车不是因为命令错了，而是不理解前端H5和服务端的连接关系，改配置时乱改一通，最后连日志都看不明白。这一章把客户端、服务端、数据层的分工讲清楚。

2.1 客户端渲染选型：为什么棋牌H5常用LayaBox而不是直接写DOM

棋牌这种H5项目对交互延迟极其敏感，牌桌上一张牌翻起来，手指点下去到画面反馈超过100毫秒，玩家就会觉得卡。纯DOM方案在这种高频小区域刷新场景下容易触发浏览器重排，帧率不稳；而LayaBox、Cocos这类引擎走的是Canvas/WebGL渲染，动画性能稳定得多。这套大厅集合版的客户端资源通常在工程的 client 或 h5 目录下，编译后发布出来的是一个静态站点加一堆JS和图片资源，正好可以直接交给Nginx托管。

从维护角度看，引擎方案还有一个隐藏好处是资源处理统一。牌面、背景、特效都以资源包形式存在，改UI不用动逻辑代码，换皮时替换图片目录就行。大厅列表、房卡数量这类界面由引擎内的List组件渲染，数据来源是WebSocket推送的JSON消息，不是服务端渲染HTML。这一点决定了后面调试时你要把精力放在接口数据和消息推送两条链路上，而不是去看页面源码里有没有接口地址。

2.2 服务端拓扑：网关连接、房间进程与大数据库之间的消息链路

服务端常见做法是采用Pomelo这类Node.js分布式框架的孪生结构：一个入口网关负责客户端连接和鉴权，多个游戏服进程分管不同玩法，数据库服统一处理读写。这套结构虽然老，但胜在清晰稳定。网关监听一个对外端口，客户端连上后先做握手、登录校验，然后根据大厅列表的房间号，把连接转发到对应的游戏服端口。

消息链路大致是这样的：玩家进入大厅，向网关发 login 和 joinRoom 消息；网关查Redis确认账号在线状态，再到MySQL里确认房卡余额；通过后返回房间服地址，客户端断开网关的连接，直连房间服端口；之后的出牌、托管、解散都在房间服内广播。把连接拆成“大厅短连接”和“对局长连接”两层，是为了让房间服可以水平扩展——哪个玩法人数多了，就多开一个进程，然后在大厅分配逻辑里把新玩家路由过去，不用重启已经运行的房间。

这个设计对新手有个很实际的提醒：你打开服务端代码会看到好几组端口，不要只盯一个入口。凡是网络排查都先问一句“这一步连接的是网关还是房间服”，否则会在错误端口上浪费大量时间。

2.3 数据层分工：Redis管实时状态、MySQL管账号与牌局记录

数据层在这套源码里分得很明确：Redis负责所有需要“马上看到”的状态，比如在线玩家列表、房间当前人数、对局中的手牌缓存、房卡库存增减的初始扣减；MySQL负责所有需要“以后还能查”的记录，比如账号信息、充值订单、牌局流水、每日对局统计。

为什么要这样拆？棋牌场景里有大量高频短生命周期数据。一盘斗地主就几分钟，手牌和出牌记录如果每次都写MySQL，光事务提交就能把数据库拖垮。Redis的读写是内存级，key过期机制还能顺手把“已结束房间”的缓存清掉。而账号余额和牌局回放必须落盘，否则服务器一重启，用户数据全没了。所以你在配置文件里会看到两套连接参数：REDIS_HOST 指向 6379，MYSQL_HOST 指向 3306。连接池大小、超时时间要分开调，不能用一套参数走天下。

2.4 协议与心跳：JSON消息格式、超时踢人参数从哪调

客户端和服务端的消息格式在这类开源项目里大多是JSON，一条消息长这样：{“type”:“joinRoom”,“roomId”:10086,“token”:“xxx”}。用JSON的好处是调试方便，直接看日志就能读懂消息内容，不用先解包；缺点是体积比二进制大，但对棋牌这种低吞吐场景完全够用。如果你后续要自己加玩法，照着现有type类型扩展就行。

心跳参数值得单独拿出来讲。棋牌H5对“掉线重连”要求很高，网络波动时不能立刻把用户踢出房间，否则体验很差。常见方案是客户端每5秒发一个心跳，服务端如果连续30秒没收到心跳，就判定为掉线，把座位托管给系统。这两个参数通常在服务端的 config/服务器配置 里调，字段名一般是 heartbeatInterval 和 heartbeatTimeout，测试环境可以把心跳拉长到10秒，降低调试时的连接中断频率，生产再改回5秒。理解这组参数，后面排查“对局中途掉线”时会快很多。

3. 服务器搭建步骤：从系统初始化到Nginx转发的可复现流程

这一章是纯操作路径，照着做就能把一套神兽道游大厅集合版源码跑起来。前提是你手里有一台干净的Linux服务器，Ubuntu 22.04 LTS是很少出错的发行版选择；本地虚拟机也行，但生产别用Windows当宿主，文件句柄、端口转发这些在Windows上全要额外折腾。

3.1 服务器规格与系统初始化：文件句柄数、时区、swap的预调

先说规格。4核8G内存起步，磁盘至少40G SSD，这套源码里包含客户端资源包和MySQL数据文件，磁盘给小了跑几个月就会报警。系统初始化我一般固定在四件事：升级软件包、打开文件句柄限制、统一时区、确认swap。很多棋牌服务端默认需要的并发连接数不小，但Linux默认的 nofile 限制只有1024，开发时看不出来，生产一放量立刻报错。

# 调整系统文件句柄数，重启后依然生效 cat >> /etc/security/limits.conf << 'EOF' * soft nofile 65535 * hard nofile 65535 EOF # 统一时区为上海，避免日志时间错乱 sudo timedatectl set-timezone Asia/Shanghai # 创建项目目录 sudo mkdir -p /data/www/ssdy sudo chown -R $(whoami) /data/www

代码逻辑说明：

• 第一段把当前用户的最大可用文件句柄数提高到65535。服务端每建立一个TCP连接就占用一个文件句柄，默认1024意味着最多约1000个在线连接，这对棋牌项目远远不够。limits.conf 的写法是软限制和硬限制一起改，写完后要重新登录终端才生效。
• 第二段统一时区。云服务器默认是UTC时间，日志时间和你的手表差8小时，排查线上问题时每一条记录都要脑内换算，非常误事。
• 第三段把项目放在 /data/www/ssdy，规范路径后就算重装系统，备份和恢复也只用看这一个目录。

3.2 拉取源码与目录结构：client/server/admin三层对应的作用

源码拉下来后先看目录结构，不要急着启动。这套集合版通常分为三个顶层目录：client 是H5前端工程，server 是Node.js服务端，admin 是运营后台；还有一个 doc 或 sql 目录放数据库脚本和部署文档。

cd /data/www/ssdy git clone <源码仓库地址> . # 查看顶层目录结构 ls -la

代码逻辑说明：

• git clone 后面的仓库地址换成你实际拿到的源码地址。如果是从网盘下载的压缩包，解压后手动把内容移到 /data/www/ssdy 即可，效果一样。clone 到当前目录的方式适合后续拉更新；压缩包方式适合第一次部署，我一般用压缩包，解压完顺手把压缩包留到备份目录，方便回滚。
• ls -la 检查目录时重点看 server/package.json 和 sql/init.sql 是否存在。有这两个文件说明服务端代码和建库脚本齐全，可以往下走；如果找不到 init.sql，后面建表会无从下手，要立刻联系源码提供方确认。

3.3 初始化数据库与配置：init.sql、.env 复制与基线参数

服务端通常要求你先建库，再改配置文件。源码里一般会带 .env.example 或 config.js.example，复制一份成实际配置后，把数据库账号密码填进去。

# 进入服务端目录 cd /data/www/ssdy/server # 安装依赖，推荐使用国内镜像加速 npm ci --registry=https://registry.npmmirror.com # 复制环境变量模板 cp .env.example .env # 根据 sql 目录下的脚本初始化 MySQL mysql -u root -p < ../sql/init.sql

代码逻辑说明：

• npm ci 和 npm install 的区别在于 npm ci 会严格按照 package-lock.json 锁定版本安装，避免依赖版本漂移导致代码跑不起来。第一次部署用 npm ci，后续要升级依赖再用 npm install。
• .env 文件是服务端启动时读取的环境配置，里面至少要改三处：MYSQL_HOST、MYSQL_PASSWORD、REDIS_HOST。如果源码用的不是 .env 而是 config.js，改动位置类似，改完注意不要把这个文件提交到仓库，里面全是明文密码。
• init.sql 是整个项目的建库建表脚本，包含账号表、订单表、牌局记录表，以及运营后台需要的权限表。执行后可以用 mysql -e "show databases;" 确认新库已经出现。这里有个细节：如果服务端代码里写死的库名和 init.sql 里的库名不一致，后面启动一定会报数据库不存在，先 grep 一下代码里的 database 名称再执行更稳妥。

3.4 用 PM2 启动服务端并把 H5 静态资源交给 Nginx 托管

Node.js 服务端不能直接裸跑，否则终端一关进程就没了。PM2 是常见选择，它能守护进程、崩溃自动重启、还能看实时日志。启动前先确认 Redis 和 MySQL 都活着，否则服务端起来也会在握手阶段报错。

# 安装进程守护工具 sudo npm install -g pm2 # 以 JSON 配置方式启动，配置文件里会写明启动哪些进程、用什么端口 pm2 start start.json --env production # 查看进程状态 pm2 status # 保存当前监听端口，确认网关和房间服都起来了 ss -lntp | grep -E '3000|8001|8002'

代码逻辑说明：

• start.json 里定义了多个进程，常见包含网关进程和房间服进程，还有管理后台进程。production 环境变量会告诉代码读取 .env 里的生产配置，不传这个参数可能读到开发环境默认端口，导致端口冲突或数据库连错。
• ss 命令检查端口监听。看到 3000 或 8001 处于 LISTEN 状态，说明服务端启动成功；如果只看到部分端口，说明某些进程启动时崩了，用 pm2 logs 看具体报错。这里建议把 start.json 里的实例数先改成1，别生产配置直接拉多进程，初学阶段多进程会把问题复杂度放大。

3.5 把 H5 静态资源交给 Nginx 托管并转发 WebSocket 流量

客户端是静态页面，直接让 Nginx 托管，同时把 /socket.io 这类长连接路径转发到 Node 网关端口。这套源码的客户端如果走的是 WebSocket，路径一般是 /socket.io 或自定义的 /ws，要先在服务端代码里确认前缀。

# /etc/nginx/sites-available/ssdy.conf server { listen 80; server_name _; # H5 静态资源目录 location / { root /data/www/ssdy/client/release; index index.html; try_files $uri $uri/ /index.html; } # HTTP 接口转发到 Node 网关 location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # WebSocket 长连接转发到网关 location /socket.io/ { proxy_pass http://127.0.0.1:8001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; } }

配置逻辑说明：

• root 指向客户端编译产物的目录，注意不是 client 工程源码目录，而是编译后的 release 或 dist 目录。如果你拿到的源码里没有这个目录，需要先在前端工程里执行一次构建脚本，常见命令是 npm run build，产物会输出到发布目录。
• /api/ 转发一段把大厅列表、登录接口转发到 Node 的 3000 端口，客户端在页面里请求的 /api/xxx 最终打到服务端逻辑。
• /socket.io/ 是长连接转发核心。WebSocket 连接从 HTTP 升级时需要带 Upgrade 和 Connection 请求头，这两行配置缺失会直接导致客户端连不上网关，浏览器控制台报 400 或握手失败。proxy_read_timeout 300s 防止 Nginx 默认60秒就掐断空闲连接，棋牌对局里有大量思考时间，超时设短了会误判掉线。

# 启用站点配置并重载 sudo ln -s /etc/nginx/sites-available/ssdy.conf /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx

4. 配置参数与热更新：HTTP/WebSocket、Redis、MySQL的必调清单

服务端跑起来只是第一步，真正决定线上稳定的是配置参数。很多人部署翻车就翻在不看默认参数，结果所有服务看起来都在运行，玩家一多就卡死。这一章给出一套基线配置，生产环境在这个基础上再按机器规格微调。

4.1 端口规划：哪些必须暴露、哪些只允许本机访问

先画一张端口清单，部署时按这个映射去放安全组和防火墙规则。一个常见的反面案例是：图省事把 8001 到 8005 全部暴露公网，被扫描器爆破出管理端口，服务器直接变成矿机。正确的做法是只有 80/443 对外，其余端口全部只允许本机访问，由 Nginx 转发。

端口只允许本机访问，就要把防火墙默认策略改成拒绝外部访问：

# 仅放行 80/443，其余外部访问一律拒绝 sudo ufw default deny incoming sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable

这里有个坑：如果你用的是云服务器，光改系统防火墙不够，控制台里的安全组规则也必须同步收紧，两边不一致时以安全组为准。默认拒绝后记得把自己开发机的SSH端口放出来，否则下次登录不上去，只能去控制台用VNC救急。

4.2 Redis 参数：内存上限、淘汰策略与在线状态的TTL

Redis 在这套项目里存的是在线状态、房间缓存和库存流水，高峰期内存涨得快。如果放任不管，Redis 会把服务器内存吃满触发 OOM，服务端全部崩。配置里至少改这几个值：

# /etc/redis/redis.conf maxmemory 512mb maxmemory-policy allkeys-lru

参数说明：

• maxmemory 512mb 是摸顶上限，根据机器内存调整，8G内存的机器给1G也合理。别把 Redis 当成无限大的缓存池，它一旦占用内存超过系统可用量，性能会雪崩。
• maxmemory-policy allkeys-lru 决定了内存满时怎么淘汰。lru 会优先干掉最少使用的 key，对棋牌场景很合适：房间缓存和在线状态本来就是热数据驱动，冷房间被淘汰后读一次MySQL重建就行。

业务侧也要配合设置 key 的过期时间。常见写法是在服务端代码里对房间信息 key 设置过期：

// redis 里房间列表的 key 过期时间设置为 15 分钟 await redisClient.set(`room:info:${roomId}`, JSON.stringify(roomInfo), 'EX', 900);

为什么是900秒？一局棋牌从开房到打完通常不超过15分钟，房间结束后这个 key 就没用了，设置过期可以避免垃圾数据堆积。如果全局都走“永不过期”的默认值，跑一周后 Redis 里全是死房间缓存，查询速度会肉眼可见地下降。

4.3 MySQL 连接数与慢查询：防止“too many connections”的基线

服务端每个进程默认会建一个数据库连接池，棋牌项目里建议连接池大小控制在10到20之间。连接池太小，高峰时排队；太大，进程数一多会把 MySQL 连接数打满。MySQL 默认的 max_connections 是151，一个项目如果开了4个Node进程、每进程20连接，还没算后台和管理工具就已经占用了80个，留给运营后台的余量很小。

# /etc/mysql/mysql.conf.d/mysqld.cnf max_connections = 500 innodb_buffer_pool_size = 2G slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1

参数说明：

• max_connections 调到500，对应你实际预估的在线人数。一个玩家在网关和房间服之间通常占用1到2个后台连接，500连接够几千人同时在线的棋牌平台。不要无脑调成2000，连接数越高，MySQL 线程切换开销越大，反而可能拖慢响应。
• innodb_buffer_pool_size 是 InnoDB 引擎的缓存池，8G机器建议给2G，占内存的25%。这里能缓存索引和热行数据，命中率高时查询快一倍以上。
• 慢查询日志记录超过1秒的SQL。排查掉线或卡顿时，这条日志能直接告诉你瓶颈是不是某个查询没走索引。很多棋牌项目数据库表不大，但随着对局记录堆叠，几百万行后一条 status 查询就能扫几百毫秒，慢日志是最先暴露问题的黑匣子。

4.4 客户端与热更新：资源版本号怎么避免读旧缓存

H5 项目每次发版最头疼的是客户端缓存。浏览器对静态资源有默认缓存策略，同一个 index.html 里引用的 JS 文件名不变，客户端就一直用旧版本，导致服务端更新了玩法规则，玩家端还是老代码。开源项目常见做法是手动维护一个资源版本号，拼到资源URL后面。

// 客户端版本号，每次发版手动+1 const RELEASE_VERSION = '20250412'; // 加载主逻辑脚本 loadScript('/js/main.js?v=' + RELEASE_VERSION);

参数说明：

• 版本号放到 URL 的 query 参数里，让浏览器把带新参数的 URL 当成新资源去拉取，绕过本地缓存。服务端每次发版前把这个数字改成当天日期，玩家刷新页面后就会自动拉新版本。
• 这个机制只对“引用的HTML页面本身没有缓存”的情况有效。因此还要在 Nginx 里对 index.html 设置禁用缓存：

location = /index.html { add_header Cache-Control "no-cache, no-store"; }

如果不加这段，HTML 本身被缓存后，版本号更新永远不生效，这正是很多团队“发版后玩家白屏”的原因——不是代码问题，是缓存策略没闭环。

5. 搭建维护中的高频踩坑：从端口被占到对局掉线的排查清单

运行一段时间后，问题会集中在“起不来、连不上、掉线、卡死”四类。这一章的每一条都是我踩过的真实场景，按现象、原因、解决三段写，排查时可以当作一份最简急诊手册。

5.1 服务起不来且报 EADDRINUSE：端口占用与残留进程处理

现象：执行 pm2 start start.json 提示错误，日志里出现 EADDRINUSE: address already in use :::3000。

原因：之前手动启动过测试进程，或者上一个环境没清干净，3000端口被残留进程占住。最常见的是你在终端按了 Ctrl+C，但子进程没被杀干净。Node 的守护进程有时也会在一段时间内占用端口不释放。

解决：先查占用，再决定是杀进程还是改端口。

# 找到占用端口的进程 lsof -i :3000 # 确认是残留进程后杀掉 kill -9 <PID> pm2 start start.json --env production

不要一上来就改服务端端口，改端口会引发客户端连接配置不同步，问题面会扩大。正确顺序是清理占用、确认端口空闲，再启动。如果 kill 后端口还是被占用，用 ss -lntp | grep 3000 再查一次，有时 TIME_WAIT 状态的连接要等一会儿才会释放。

5.2 网关正常但登录失败：检查Redis bind、防火墙与安全组

现象：客户端能打开大厅页面，但点登录后一直转圈，服务端日志没有任何报错，浏览器控制台显示 WebSocket 连接失败或接口超时。

原因：服务端和 Redis 的连接被防火墙或 Redis 本身的 bind 配置挡了。最常见的是 Redis 只监听了 127.0.0.1，服务端在另一台机器上根本连不上；或者云服务器安全组没放行服务端到 Redis 的网络。

解决：先确认服务端能不能 ping 通 Redis 主机，再确认 Redis 配置。

# 从服务端测试 Redis 连通性 redis-cli -h 127.0.0.1 -p 6379 ping # 检查 Redis 是否只绑定了本机 grep '^bind' /etc/redis/redis.conf

如果 bind 里只有 127.0.0.1，说明 Redis 只对本机开放。单机部署时服务端和 Redis 在同一台机器，这个配置没问题；分布部署时要把 bind 改成内网IP，并设置 requirepass 密码，否则基线风险太大。另一个隐藏点是云安全组：即使 Redis 配置文件全对了，安全组不放行内网IP段一样连不上，排查时别只顾看 Redis 配置。

5.3 对局进行十几分钟就掉线：Nginx的超时时间设置

现象：玩家进房间没问题，开局也正常，但打了几分钟到十几分钟就集体掉线，重新连又能继续。

原因：Nginx 的 proxy_read_timeout 默认值只有60秒。当客户端和服务端的 WebSocket 连接空闲超过60秒，也就是玩家正在思考出牌、没有任何消息交互时，Nginx 主动断开了连接。掉线瞬间没有重连机制的老版本客户端，玩家直接弹出结算界面，体验特别差。

解决：把长连接的转发超时调到300秒甚至更长。

location /socket.io/ { proxy_pass http://127.0.0.1:8001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; proxy_send_timeout 300s; }

这里有个判断技巧：如果掉线时间集中在60秒或120秒附近，基本可以断定是超时问题；如果掉线时间随机，就要去看房间服的日志和心跳超时参数。上一次遇到类似问题，我同时调了 Nginx 超时和服务端心跳间隔，反而掩盖了真正原因，后来只改 Nginx 就恢复正常了。

5.4 MySQL 出现连接数打满：连接池未释放与 max_connections 调整

现象：服务端运行几天后，日志频繁报 too many connections，大厅口开始卡顿，重启 MySQL 能好一阵，但很快又复发。

原因：连接池溢出通常是某个查询写得太慢，占住连接不放，新请求排队把连接池占满；或者 Node 进程崩溃重启时旧连接没被回收，MySQL 侧满是 TIME_WAIT 状态。

解决：先重启连接，再看慢查询定位慢SQL。

# 查看当前MySQL连接数与进程状态 mysql -u root -p -e "SHOW PROCESSLIST;" # 临时回收所有空闲连接 mysql -u root -p -e "FLUSH CONNECTIONS;" # 确认慢查询 tail -f /var/log/mysql/slow.log

慢日志里如果看到某条 SQL 每次执行超过1秒，就要考虑给相关表加索引。最常见的几十万行的牌局记录表按 userId 筛选时没走索引，每查一次就是全表扫描，连接自然释放不了。加上联合索引后，慢日志里的记录会很快消失，问题连根拔掉。

5.5 热更新后玩家白屏或报错：版本号与缓存策略不统一

现象：发版后自己访问新功能正常，但一部分玩家打开页面白屏，或者功能还是旧的，过两天才慢慢恢复。

原因：版本号更新了，但玩家浏览器之前缓存了 index.html，导致页面用的还是旧 JS 引用；或者版本号只改了主入口，子模块的资源没带版本号，混用新旧资源后报什么错都有可能。

解决：对入口 HTML 禁用缓存，并检查所有动态加载的资源都带版本号。

# 确认 index.html 的响应头，必须有 no-cache curl -I http://your-domain.com/index.html

响应头里如果没看到 Cache-Control: no-cache，就按本文 4.4 小节的配置加上。另外检查客户端代码里所有 loadScript / 图片资源拼接版本号的逻辑，遗漏一个，下次发版还会有人出问题。

6. 上生产前的验证与压测：给网关做连接数摸底和备份回滚的日常

部署完不等于能上线。我发现很多项目只验证了“能访问首页”，没验证并发和异常恢复，上线头一天就被玩家打挂。最后一章分享一套我自己的上线前验证流程，以及每天巡检要看的三个数据。

6.1 用连接脚本给网关做一次摸顶测试

不需要专业压测工具，先拿简单脚本验证网关的连接上限和内存占用趋势。下面的脚本用短连接模拟大量客户端同时握手：

# 模拟 500 个并发连接网关，观察系统负载 for i in $(seq 1 500); do (echo -e '{"type":"ping"}\n' | nc -w 1 127.0.0.1 8001 > /dev/null 2>&1 &) sleep 0.02 done # 看连接数和系统负载 ss -s free -h

如果执行过程中出现大量 TIME_WAIT 或内存快速上涨，说明当前实例数不够，或者 Node 进程的内存泄漏已经存在。摸顶测试后记得重启一次服务端，观察内存是否能回落到初始水平，回不去说明有泄漏，要尽早用 heapdump 定位。

6.2 数据备份与回滚：mysqldump、Redis BGSAVE 与日志快照

上线后每天要做一次完整备份，这不是给多人看的，而是给自己留后悔药。MySQL 用 mysqldump 落库，Redis 用 BGSAVE 落RDB，两步可以写在同一个定时任务里：

# 每天凌晨3点备份 0 3 * * * /usr/bin/mysqldump -u root -p'你的密码' ssdy_db > /data/backup/ssdy_$(date +\%F).sql 0 3 * * * /usr/bin/redis-cli bgsave # 保留7天，超过的自动清理 0 4 * * * find /data/backup -name "*.sql" -mtime +7 -delete

回滚时先恢复MySQL，再恢复Redis。注意顺序不能反：先MySQL后Redis，Redis恢复后在线状态会从旧快照重建，玩家会被踢下线重连，这是可接受的；反过来操作会让 MySQL 里的账号数据和服务端内存状态错位，可能产生对局数据不一致。

6.3 每天看日志的三个固定动作

我每天巡检只看三个东西：昨天是否有大规模掉线、慢查询有没有新增、磁盘剩余空间。前两个用 grep 就行：

# 昨日是否有掉线或错误关键字 grep -E "disconnect|error" /data/www/ssdy/server/logs/*.log | date # 慢查询日志是否增长 ls -l /var/log/mysql/slow.log df -h

棋牌项目日志增长速度超过预期，最常见原因是加了无谓的 debug 日志。上生产前要把服务端 log level 从 debug 改成 info，否则磁盘写满只是时间问题。这套流程走完后，我对这套源码的态度是：它能帮你省掉搭框架的时间，但生产环境的稳定要自己背。当年我第一次部署时没调 nofile，玩家到两百人服务器就卡死，后来把这份检查清单打印出来贴工位，再没有半夜爬起来救火。希望帮到你。

本文还有配套的精品资源，点击获取