Java游戏服务端核心架构：Netty长连接与状态管理实践

简介这是一套基于 SpringBoot 的游戏服务网站 Java 源码面向计算机、电子信息工程等专业学习者适用于毕业设计、课程设计或期末大作业能够帮助快速搭建并理解前后端分离项目的完整流程与核心设计并附带相关文档说明。压缩包共 646 个文件、约 22.18MB其中 Java 后端逻辑文件 163 个、Vue 前端页面文件 117 个占比最高另有 SVG 图标、JavaScript/CSS 交互样式、XML/yml 配置、bat 启动脚本及 docx 说明文档等适配 JDK1.8、Mysql 5.7、Tomcat 8.0/9.0 环境目录结构清晰便于按模块检索。目前已有 593 人浏览学习。代码完整覆盖游戏服务网站的前后端功能经严格测试可运行包含可参考的界面页面与后端接口调用逻辑既可以作为毕业设计项目骨架进行二次开发也能作为课程设计或期末大作业的完整实例是计算机相关专业实践学习的高分参考。1. Java 游戏服务网站核心是“状态”不是“接口”游戏服务网站和普通业务网站最大的区别在于“状态”二字。普通网站处理完一个请求就可以把连接断开游戏服务却要长期维护成千上万个在线连接每个连接背后都是一个实时变化的玩家状态。Java 在后端常被选中靠的不是单机性能极致而是生态完整、内存模型可控、团队里出了问题容易找到人接手。下面按游戏后端行业常见的工程路径把架构拆分、核心代码、参数调优到部署验证完整走一遍。这套方案对正在做游戏服务端、以及准备从 Web 后端往游戏方向转的工程师都有参考价值。2. Java 游戏服务端架构Netty 管长连接Spring Boot 管后台2.1 为什么网关层必须单独拆出来游戏服务网站的网络流量可以分成两类。一类是玩家客户端的实时通信走 TCP 长连接客户端登录之后连接一直保持随时收发消息另一类是运营后台、排行榜查询、支付回调这类 HTTP 请求一次请求一次应答。两类流量的特征差异很大如果合并在同一个服务进程里长连接的 I/O 阻塞会把 HTTP 请求也拖入排队玩家多的区服偶尔出现一个异常连接后台接口可能整体无响应。生命周期管理方式不同也需要分开部署。HTTP 服务可以随时重启长连接网关重启一次就意味着几千个在线玩家同时掉线、同时重连重连风暴可能把登录接口打到瘫痪。因此实际项目里我一般会把网关和后台拆成两个可独立部署的服务后台接口的发版就不会影响在线玩家。工程上按三个 Maven 模块组织父工程只放公共依赖和版本管理game-server/ ├── game-gateway/ # Netty 网关连接管理、心跳检测、消息转发 ├── game-core/ # 游戏逻辑层玩家状态、战斗结算、背包服务 └── game-admin/ # Spring Boot 后台运营接口、公告、日志查询模块依赖是单向的。game-gateway和game-admin都依赖game-coregame-core不依赖任何网络框架。这样单元测试可以直接 new 一个 Service 来跑不需要启动网络服务纯逻辑的测试耗时极短。以后如果要换协议层比如从 TCP 迁移到 WebSocket网关整体替换即可核心逻辑代码一行不用改。对比项长连接网关HTTP 后台连接生命周期分钟到小时级单次请求重启影响在线玩家掉线基本无感扩容指标在线人数请求 QPS故障特征大量断线重连请求超时2.2 Netty 服务端的启动骨架与线程参数网关层基于 Netty 的ServerBootstrap启动一组引导参数基本决定了单节点的连接承载能力EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(Runtime.getRuntime().availableProcessors() * 2); ServerBootstrap bootstrap new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .childOption(ChannelOption.TCP_NODELAY, true) .childOption(ChannelOption.SO_KEEPALIVE, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new GameMessageDecoder()); ch.pipeline().addLast(new GameMessageEncoder()); ch.pipeline().addLast(new GameServerHandler()); } }); bootstrap.bind(8801).sync(); // 同步阻塞启动失败直接抛异常这段代码的作用是启动一个监听 8801 端口的 TCP 服务。bossGroup 只放 1 个线程专门 accept 新连接workerGroup 按 CPU 核数两倍创建线程负责已建立连接的消息读写和业务分发initChannel把编解码器和业务处理器按 decoder → encoder → handler 的顺序挂到管道上消息到达时按这条链路依次流动。参数里有几个关键点SO_BACKLOG1024TCP 握手时内核保持的等待队列长度。万人同时在线的游戏服务1024 只是起步值还要跟系统的net.core.somaxconn配套调整TCP_NODELAYtrue关闭 Nagle 算法。Nagle 会把小包合并发送来提升带宽利用率但代价是增加延迟游戏消息多数是小包必须关掉SO_KEEPALIVEtrueTCP 层保活默认探测频率是 2 小时只能作为兜底不能替代应用层心跳workerGroup 的线程数值得单独说清楚。NIO 模型下一个 event loop 线程通过 selector 管理成百上千个 Channel线程数和在线人数不是线性关系。2 倍 CPU 核数是均衡的起点如果游戏逻辑以计算为主可以减少到核数加一把计算任务放到业务线程池里处理。线程比核数多得多时上下文切换会吃掉性能这一点在压测结果里表现得很明显。2.3 协议设计长度头加消息 ID 与 Protobuf 编解码长连接消息最常见的封装是“总长度 4 字节 消息 ID 4 字节 协议体”。协议体推荐用 Protocol Buffers 定义相比 JSON 传输体积小 30% 到 50%字段带编号后可以随时追加新字段老客户端解析也不会报错。syntax proto3; message LoginRequest { string account 1; string token 2; } message LoginResponse { int32 code 1; string playerName 2; int64 playerId 3; }解码器是整条链路上最容易写错的地方核心要处理 TCP 的粘包拆包public class GameMessageDecoder extends ByteToMessageDecoder { Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) { if (in.readableBytes() 8) { return; // 长度头还没收齐 } in.markReaderIndex(); // 记住当前读位置便于半包回退 int length in.readInt(); if (length 0 || length 65535) { ctx.close(); // 非法长度直接断开连接 return; } if (in.readableBytes() length) { in.resetReaderIndex(); // 数据未到齐等下一次 decode return; } int msgId in.readInt(); byte[] data new byte[length - 4]; in.readBytes(data); out.add(new GameMessage(msgId, data)); } }这里的逻辑是拿到总长度后判断当前缓冲区里有没有攒够这么多字节不够就把读指针回退到标记位置等下一次数据到达时重新解析。长度限制在 0 到 65535是为了防止攻击者伪造超大长度字段让解码器一直等待永远到不齐的数据消耗服务端内存和连接资源。解码完成后网关只根据消息 ID 做路由具体业务数据交给游戏逻辑层处理。3. 游戏逻辑代码的三件事登录鉴权、心跳检测与状态同步3.1 登录鉴权网关只认 token不认密码游戏服务的登录流程分两步。客户端先用账号密码或第三方凭证走一遍 HTTP 接口换取 token再拿着 token 建立游戏长连接。网关收到登录请求后只验证 token 有效性验证不通过直接断开密码明文永远不出现在长连接里。用 Redis 保存 token 是常见做法public class LoginService { private final StringRedisTemplate redis; public void verifyToken(String token, String account) { String key login:token: account; String cached redis.opsForValue().get(key); // 不存在或已过期都判定为无效 token if (cached null || !cached.equals(token)) { throw new AuthException(token expired); } } }这段代码的作用是校验登录时签发的 token 是否仍然有效。key 用login:token:前缀加账号名同一个账号的历史登录信息会集中在一组 key 上方便排查问题。比较 token 时用常量时间比较避免通过响应时间差做 token 枚举。验证通过后网关要把“连接”和“玩家 ID”绑定起来。Netty 的 Channel Attribute 是干这个最合适的地方public static final AttributeKeyLong PLAYER_ID AttributeKey.valueOf(playerId); // 登录成功后绑定 ctx.channel().attr(PLAYER_ID).set(playerId); // 后续任何 handler 需要玩家身份时取出 Long playerId ctx.channel().attr(PLAYER_ID).get();这里有两个容易踩的坑。第一个是 token 有效期必须长于单次游戏会话又不能无限期有效。一般设 24 小时客户端每 4 小时调一次刷新接口刷新时检查剩余有效期不足 8 小时才签发新 token。第二个坑是玩家掉线后立刻重连旧连接如果没及时关闭会出现两个 Channel 指向同一个 playerId。处理逻辑上要把旧连接踢下线再绑定新连接否则背包、货币这类数据会被并发操作写出问题。3.2 心跳检测应用层才能判断连接真假TCP 的 keepalive 在游戏场景下不够用默认探测间隔 2 小时而且只能证明网络通路通不能证明对端应用还活着。游戏服务端通常在应用层加心跳协议客户端每 20 到 30 秒发一次心跳服务器超过 60 秒没收到任意数据就判定掉线。最简洁的方式是直接用 Netty 的IdleStateHandler// 读空闲 60 秒判定掉线写空闲不启用 ch.pipeline().addLast(new IdleStateHandler(60, 0, 0, TimeUnit.SECONDS)); ch.pipeline().addLast(new GameServerHandler());IdleStateHandler三个参数分别表示读空闲超时、写空闲超时、读写全部空闲超时。游戏服务器只关心读空闲也就是 60 秒没有从客户端收到任何字节判定对方已经断开。写空闲和全空闲置 0 表示不启用。超时触发后的动作放在业务处理器里Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) { if (evt instanceof IdleStateEvent) { // 先清理在线状态再关闭连接 onlineManager.remove(ctx.channel()); ctx.close(); } }这里要注意顺序必须先把玩家从在线列表和场景管理器里移除再关闭连接。如果省略清理步骤会出现“玩家已掉线但场景里还站着它的角色”的鬼魂问题——其他玩家能看到这个角色站着不动攻击也打不到它。清理逻辑要和登录绑定逻辑放在同一个服务里通过playerId关联操作。心跳超时的具体数值和游戏类型强相关参考值如下游戏类型心跳间隔断开判定考虑因素休闲养成30 秒90 秒玩家频繁切后台容错要放宽MMORPG20 秒60 秒挂机场景多取中间值实时对战10 秒30 秒低延迟优先尽快释放死连接心跳超时不能用一个绝对值套所有游戏。移动网络切换、玩家切后台再回来通信空窗可能达到 30 到 60 秒。判断过短会让正常玩家反复掉线重连重连风暴反过来压垮服务器。3.3 状态同步减少广播范围比压缩包体更有效状态同步指的是把一个玩家的位置、血量、背包变化告诉其他需要知道的玩家。MMORPG 一个场景最多上千人但一个玩家的变化其实只需要广播给周围同屏协同的玩家。需要避免的初始写法是每次移动都遍历全场景所有玩家。人数小于 200 时问题不大超过 500 时每个移动事件都要做 500 次距离判断100 个玩家同时移动就是 5 万次运算服务器算力全浪费在无意义的遍历上。最常见的解法是“格子”空间索引public class GridScene { private static final int GRID_SIZE 40; // 格子边长单位同坐标 private final MapLong, SetPlayer grids new ConcurrentHashMap(); public SetPlayer queryAround(Player player) { SetPlayer result new HashSet(); int cx player.getX() / GRID_SIZE; int cy player.getY() / GRID_SIZE; for (int gx cx - 1; gx cx 1; gx) { for (int gy cy - 1; gy cy 1; gy) { SetPlayer grid grids.get(gridKey(gx, gy)); if (grid ! null) { result.addAll(grid); } } } return result; } private long gridKey(int gx, int gy) { // 二维转一维避免字符串拼接产生垃圾对象 return ((long) gx 32) | (gy 0xffffffffL); } }这段代码把地图切成边长 40 的格子查询时只取目标周围 3×3 共 9 个格子里的玩家集合而不是遍历全地图。格子大小要和广播半径匹配广播半径 100、格子边长 40 时周围 3×3 能覆盖半径 80 到 120 的范围格子内玩家数量也不会太多。跨格移动时还要更新玩家所在的格子索引这一步要用ConcurrentHashMap保证并发安全。格子 key 用位运算拼成一个 long是为了避免每次查询都拿字符串拼接当 key。这类小优化在大规模访问下能明显降低 GC 压力内存分配少了停顿自然减少。状态同步还有一个容易被忽略的规则广播包内容要精简。客户端需要什么就给什么——同步位置就发playerId x y direction同步血量就发playerId hp mp不要把整个玩家对象序列化发出去。广播基数大时包体多出的每个字节都要乘以接收人数累积起来相当可观。4. 数据库与线程池参数游戏后端稳定性的关键4.1 玩家热数据的缓存与落库策略游戏里的热数据比如位置、血量、背包物品既不能每次读写都走数据库也不能全放内存。前者性能不够后者服务器一崩全丢。实际项目的策略分三层内存中维护完整玩家热数据所有逻辑读写都在内存完成脏数据定期同步到 Redis 做缓存防止崩溃后从零恢复玩家下线时把完整状态写入 MySQL作为最终持久化定期同步最需要注意的是时间错峰。5000 人在线每个人都 5 分钟同步一次如果同步周期都从同一时间点起算数据库每秒会收到大量写入请求。做法是给每个玩家的同步周期加一个随机偏移让同步操作均匀散落在时间轴上而不是在整点瞬间集中爆发。异常下线时Redis 里的近实时缓存可以把玩家状态恢复到最多丢失几分钟的进度对绝大多数游戏来说可接受。如果要求更高就要引入消息队列把每个关键操作落日志成本会高一个数量级。4.2 HikariCP 连接池游戏配置和 Web 应用的差别数据库连接池用 HikariCP 是默认选项。游戏服务的连接池配置和普通 Web 后端差别很大核心差异是游戏里的数据库操作等不起。spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 3000 max-lifetime: 1800000各参数的含义和选择理由connection-timeout: 3000单位毫秒。拿不到连接最多等 3 秒超时立即报错返回给客户端而不是让玩家一直转圈。普通 Web 应用可能设 30 秒游戏客户端等 30 秒已经足够产生大量投诉maximum-pool-size: 20连接池上限。很多团队习惯性配到 200实际上超过了数据库的执行能力只会加剧锁竞争minimum-idle: 5保持 5 个空闲连接。游戏流量是突发型的空闲连接太多是浪费max-lifetime: 180000030 分钟回收连接防止数据库端连接已失效而客户端还在使用连接池大小可以按平均查询耗时毫秒× 并发查询 QPS / 1000估算。比如平均查询耗时 5 毫秒目标并发查询 4000 QPS池大小约等于 20。同一个数据库如果池子超过 50通常说明业务逻辑有问题应该先加缓存或拆分表而不是继续调大连接池。各类场景的参数参考值参数普通 Web 应用游戏服务说明connection-timeout(ms)300003000游戏超时即报错maximum-pool-size50~10020~30按估算公式调整minimum-idle105减少空闲占用max-lifetime(ms)18000001800000防失效连接4.3 把游戏逻辑从 Netty IO 线程里搬出去游戏消息处理不能直接在 Netty 的 IO 线程里跑业务。IO 线程负责读写Read 到消息后如果直接在 IO 线程里执行数据库查询一次查询耗时 5 到 10 毫秒这个线程管理的几百个连接就全都得不到及时读写玩家侧表现为“整个服卡住”。标准做法是在解码器之后引入独立业务线程池static final ExecutorService GAME_EXECUTOR new ThreadPoolExecutor(16, 32, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(1024), // 排队上限防止积压过深 new ThreadPoolExecutor.AbortPolicy());其中 16 是核心线程数32 是最大线程数60 秒是空闲线程回收等待时间LinkedBlockingQueue(1024)是任务排队上限AbortPolicy是队列满时的拒绝策略。在 ChannelHandler 里把任务提交到线程池Override protected void channelRead0(ChannelHandlerContext ctx, GameMessage msg) { GAME_EXECUTOR.submit(() - { try { dispatcher.dispatch(ctx, msg); } catch (Exception e) { log.error(dispatch message failed, msgId{}, msg.msgId(), e); } }); }直接向线程池提交有一个并发隐患同一个玩家的多条消息可能被不同线程并发执行导致位置回跳、背包数量错乱。解决办法是按玩家 ID 做分片让同一个玩家永远进入同一个单线程执行器ExecutorService[] shards new ExecutorService[16]; void submit(Long playerId, Runnable task) { int idx (int) (playerId % shards.length); shards[idx].submit(task); // 同一玩家的消息串行执行 }分片方式下一个玩家的消息排在一个线程里串行处理天然避免了同一玩家数据被并发修改。16 个分片在 5000 人左右在线时够用在线人数继续增长后把分片调到 32 或按区服拆分。这种按 ID 分片的路由思路在处理玩家数据隔离和分布式路由时同样适用。拒绝策略选AbortPolicy而不是无界队列是想让系统在过载时快速失败。游戏场景里任务排队超过 1024 说明系统已经忙不过来继续等待只会让玩家体验更差直接拒绝并返回“系统繁忙”是更优的选择。5. 游戏服务部署与 JVM 调优从开发到上线的最后一公里5.1 JVM 参数怎么配才能少卡顿游戏服务的 JVM 参数和普通 Web 应用最大的区别在关注点。Web 应用更在意吞吐量游戏服务更在意延迟和停顿时间。玩家正在团战时服务器 Full GC 停 2 秒体验损失远大于普通网页慢 2 秒。Java 17 后的推荐配置# 堆固定 4G避免扩容触发 GC java -Xms4g -Xmx4g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis100 \ -XX:ParallelGCThreads4 \ -XX:ConcGCThreads2 \ -jar game-gateway.jar参数含义和选择理由-Xms4g -Xmx4g初始堆和最大堆保持一致避免运行期堆扩容触发不必要的 GC。具体大小先按每玩家 50KB 常驻对象估算5000 人在线 4G 够用后续根据监控调整-XX:MaxGCPauseMillis100G1 的停顿时间优化目标。100 毫秒是不容易引发感知卡顿、又不需要过高 CPU 开销的起点值-XX:ParallelGCThreads4并行 GC 线程数。物理核数多时不要堆满GC 线程要和业务线程抢 CPU-XX:ConcGCThreads2并发标记线程数通常取 ParallelGCThreads 的一半注意MaxGCPauseMillis是软目标不是硬性上线。内存分配速率过高时G1 无论如何也压不住停顿所以这个参数要配合 GC 日志一起看只配参数不观察效果是常见误区。5.2 延迟敏感场景再考虑 ZGCJava 17 开始 ZGC 已经相当成熟停顿时间可以稳定压在 1 毫秒以内代价是额外的 CPU 开销。实时对战这类延迟敏感的游戏可以考虑普通 MMORPG 和休闲游戏用 G1 就够了。# 延迟优先场景启用 ZGC java -Xms4g -Xmx4g -XX:UseZGC -jar game-gateway.jar两种垃圾回收器的对比对比项G1ZGC停顿目标可配置通常 100ms约 1msCPU 额外开销低中高适合堆大小64G 以下体验好可达 TB 级适用游戏MMORPG、休闲实时对战、竞技如果业务没有硬性延迟指标G1 是更稳妥的选择。ZGC 在低核数机器上 CPU 开销占比偏高反而可能挤占业务线程的算力。5.3 上线前必须检查的系统参数游戏服压测经常遇到“代码没问题环境拖后腿”的情况。下面这份清单每一项在首次上线前都值得过一遍检查项检查命令参考值影响文件描述符上限ulimit -n65535默认 1024 会拒接新连接端口监听netstat -an | grep 8801LISTEN确认服务已启动时区dateUTC8跨服活动时间错乱内核 somaxconnsysctl net.core.somaxconn1024低于应用 backlog 会丢连接磁盘空间df -h剩余 20%日志写满会引发连锁故障文件描述符最常见的问题不是没改而是改了不生效。systemd 启动的服务必须单独设置[Service] LimitNOFILE65535net.core.somaxconn要和 Netty 的SO_BACKLOG配套。应用层设 1024内核队列上限如果只有 128高并发下大量连接会被丢弃。修改方式echo net.core.somaxconn1024 /etc/sysctl.conf sysctl -p磁盘监控要同时盯着存档目录和 GC 日志目录。存档写不进去会引发存档流程异常GC 日志打满磁盘会导致 JVM 无法输出新日志间接放大停顿。6. 压测验证与线上排错手法让游戏服务网站代码可维护6.1 用最小代码做连接数压测自己写一个最小连接压测客户端比先搭压测工具更直接可以快速验证网关的承载上限和死连接回收能力public class ConnectionProbe { public static void main(String[] args) throws Exception { int total Integer.parseInt(args[0]); // 要建立的连接数 for (int i 0; i total; i) { Socket socket new Socket(127.0.0.1, 8801); socket.setKeepAlive(true); System.out.println(connected: (i 1)); } Thread.sleep(10 * 60 * 1000L); // 保持 10 分钟观察回收 } }压测时观察三个指标内存曲线是否持续上升、有没有Too many open files报错、ESTABLISHED连接数和实际创建数是否一致。任何一个异常都要停下来排查不要硬扛着跑完。6.2 线上问题排查先 GC、再线程、后网络游戏服务“时快时慢”是最常见的线上问题排查顺序固定为 GC、线程、网络# 查看 FGC 增长频率和耗时 jstat -gcutil pid 1000 # 抓线程栈 jstack pid thread_dump.txtjstat -gcutil输出里的FGC列持续增长说明有内存泄漏或堆配置偏小。jstack抓到的栈里如果大量卡在数据库驱动等待状态优先怀疑连接池配置不够。两者都正常时再用ss -tan | awk {print $1} | sort | uniq -c统计连接状态分布。固定这个顺序可以快速排除低概率因素把问题收敛到具体层级。6.3 一个容易被忽略的压测前提压测机本身的连接数有上限不是想建多少连接就建多少。Linux 默认本地端口范围有限压测超过两万连接时先调压测机sysctl -w net.ipv4.ip_local_port_range1024 65535 sysctl -w net.ipv4.tcp_tw_reuse1tcp_tw_reuse对出站连接生效压测机作为客户端时开启它才能复用 TIME_WAIT 端口。服务器端出现大量 TIME_WAIT 由对端先断开触发和这个参数无关。配置完成后用sysctl -p生效再用ss -s对比压测机和服务器两端的连接计数差值过大时重点检查防火墙和负载均衡的连接淘汰策略。本文还有配套的精品资源点击获取