全栈攻城狮

Appearance

综合实战：多人实时休闲游戏服务器（下） ​

概述 ​

在实时对战服务器（上）的基础上补齐大规模运营能力：匹配池（快速组队）、分布式分片（水平扩展）、弹性伸缩（按需扩容）、反外挂行为检测（实时风控）、全链路监控（可观测）。五块能力让实时游戏从"单服能跑"走向"集群可运营"。

一、匹配池 ​

1.1 匹配设计 ​

匹配需求（弹射对战）：
  快速组队：目标 3s 内匹配成功
  实力均衡：按段位/胜率匹配
  同段优先、跨段兜底（渐进放宽）

实现（见匹配章节）：
  匹配池：按段位分池（Redis 队列/ZSet）
  匹配器：定时扫描 → 组队 → 开房
  超时放宽：等待越久，匹配范围越大
// 匹配池入队
redis.zadd("match:pool:" + rank, score, playerId);

// 定时匹配器
// 每 500ms 扫描各段位池
// 同段人数够 → 组队开房
// 等待超时 → 放宽到相邻段位
List team = matchPool.tryForm(rank, timeout);   // 匹配到的玩家列表
if (team.size() == 4) { roomService.create(team); }

1.2 匹配体验优化 ​

体验优化：
  队长选择：段位最高/等待最久者当队长
  秒开模式：人数不足给 AI 补位（休闲玩法）
  匹配中取消：出队（幂等，防重复出队）
  匹配通知：成功后推送房间信息
// 匹配超时与 AI 补位
if (waitTime > 10s && allowAi) {
    fillAi(team);            // 补 AI，保证开局
}

二、分布式分片 ​

2.1 分片方案 ​

分片需求（多节点集群）：
  房间分片：房间落在固定节点（跨节点通信难）
  玩家路由：按玩家 ID 哈希定位所在节点

方案（见分片章节）：
  一致性哈希（Ketama）：玩家/房间 → 节点
  网关按哈希转发（房间路由表）
  分片迁移：节点扩缩容时迁移房间

本项目：
  网关无状态（Redis 全局会话）
  房间分片：roomId 哈希 → 逻辑节点
  跨节点邀请/观战：gRPC 转发（见跨服章节）
// 房间路由
long node = ketama.getNode(roomId);      // 一致性哈希
gateway.forward(channel, node, frame);   // 网关转发
// 房间节点表（Redis）
redis.hset("room:route", roomId, nodeId);

2.2 分片一致性 ​

分片注意：
  同房间玩家 → 同节点（哈希保证）
  玩家不在其房间节点时 → 转发
  节点故障 → 房间迁移/重建（快照恢复）
  跨节点操作（好友邀请）→ RPC 转发
// 故障迁移
if (nodeDown(room.nodeId)) {
    RoomSnap snap = snapshotStore.load(roomId);
    long newNode = ketama.getNode(roomId);   // 重新路由
    roomService.recover(roomId, snap, newNode);
}

三、弹性伸缩 ​

3.1 扩容触发 ​

扩容依据：
  节点 CPU/在线人数（HPA 指标）
  匹配等待时间（业务指标）
  开服尖峰（预设容量 + 自动扩容）

扩缩容（K8s，见容器化章节）：
  HPA：CPU > 70% → 加副本
  摘流缩容：先摘流 → 等对局结束 → 优雅关闭
  扩容新增节点 → 网关路由自动感知（服务发现）
// HPA 参考（CPU + 自定义在线指标）
metrics:
  - type: Resource
    resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
  - type: Pods
    pods: { metric: { name: game_online }, target: { type: AverageValue, averageValue: "5000" } }

3.2 缩容安全 ​

缩容保护：
  不杀对局中节点：先停止新匹配 → 等待存量对局
  房间迁移：快照 → 新节点重建
  连接摘流：网关从路由表摘除
  全部排空 → 优雅关闭（见灰度章节）

开服尖峰预案：
  提前扩容（容量规划）
  排队系统（登录限流排队，见运营章节）

四、反外挂行为检测 ​

4.1 实时行为检测 ​

实时游戏外挂：
  加速（移动速度异常）
  透视（视野外攻击/预判）
  自动操作（弹射脚本：固定角度力度）

检测（见反脚本章节）：
  频次：操作频率超人类上限
  节奏：间隔过于规律（脚本特征）
  合理性：速度/落点异常（服务端物理校验）
  设备：同设备多账号
// 速度异常检测（服务端权威）
double speed = posDelta / dt;
if (speed > MAX_SPEED * 1.5) {
    risk.mark(p, "速度异常");
    revertPosition(p);            // 回滚到合法位置
}
// 操作节奏
if (intervalVariance(p) < EPSILON) risk.mark(p, "节奏异常");

4.2 处置与合规 ​

处置梯度：
  轻：验证码 / 限速
  中：限制收益 / 降匹配优先级
  重：封禁（设备 + 账号）
  全程留日志（TraceId 可追溯）

合规联动：
  防沉迷（未成年人时长/充值限制）
  敏感词过滤（对局聊天/昵称）
  隐私脱敏（见合规章节）

五、全链路监控 ​

5.1 指标监控 ​

监控面板（见监控章节）：
  实时：在线数、房间数、匹配等待、QPS/RT
  资源：CPU/内存/GC/连接数
  业务：对局数、掉线率、匹配成功率

告警：
  匹配等待 > 10s（匹配服务异常）
  掉线率 > 5%（网络/节点问题）
  节点 CPU > 80%（扩容触发）
  告警 → 钉钉/企微（见监控章节）
// PromQL 示例
// 匹配等待 P95
histogram_quantile(0.95, sum(rate(match_wait_seconds_bucket[5m])) by (le))
// 在线人数
sum(game_online_total)

5.2 日志与链路 ​

日志（见日志章节）：
  对局日志（输入/状态/结果，可回放）
  异常日志（风控命中/错误）
  全量操作日志（审计）

链路追踪（见追踪章节）：
  TraceId：网关 → 逻辑 → DB/Redis → MQ
  慢链路定位（对局卡顿排查）
  与监控/日志三平台联动

回放能力：
  对局全程录制（快照 + 输入流）
  客服/反外挂复盘用

六、实现要点 ​

实时对战（下）清单：
  匹配池：分段匹配 + 超时放宽 + AI 补位
  分片：一致性哈希房间路由 + 故障迁移
  伸缩：HPA 扩容 + 摘流缩容 + 尖峰预案
  反外挂：速度/节奏检测 + 处置梯度
  监控：指标 + 告警 + 日志 + 链路 + 回放

常见坑：
  匹配池无超时兜底 → 玩家无限等待
  缩容杀对局节点 → 掉线事故
  只检测不处置 → 外挂泛滥
  监控无告警闭环 → 出事才发现

与其他系统衔接：
  全部复用前 13 周对应章节方案
  弹性伸缩 → 容器化/灰度章节
  反外挂 → 安全章节
  监控 → 运维章节