服务端节点与分布式协调 private
服务端节点与分布式协调
回答“每类服务节点做什么、ZooKeeper 如何发现节点、Manager 如何按负载分配 Worker”。
5. 服务端节点与分布式协调
5.1 节点职责
| 节点 | 主要职责 | 关键协作者 |
|---|---|---|
| Login | 登录入口、平台认证、战区校验、登录令牌 | Redis、PlayerMgr |
| PlayerMgr | 会话分配、角色装载/保存、Lobby 负载选择 | Lobby、Redis、MySQL |
| Lobby | 玩家 Actor、养成/背包/任务、组队和战斗入口 | PlayerMgr、TeamMgr、BattleMgr |
| TeamMgr / Team | 队伍节点分配、队伍 Actor、准备和开战 | Lobby、Matching、BattleMgr |
| Matching | 匹配队列，成功后创建战斗 | Team、BattleMgr |
| BattleMgr | 管理 Battle 节点连接，按负载选择节点 | Battle |
| Battle | 权威战斗实体、地图、刷怪、结算和状态同步 | Lobby、Ranking、Agent |
| ChannelMgr / Channel | 频道分配、世界/公会聊天 | Lobby、Redis |
| Ranking | 排行榜和房间令牌索引 | Redis |
| Agent | 定时任务、赛季/活动、运维辅助 | Redis、各业务节点 |
| Gateway | 网关能力，是否进入链路取决于部署 | 下游节点 |
| IdipFcm / IdipWeb | 运营管理、战区数据维护 | Redis、MySQL、ZooKeeper |
5.2 服务发现与负载
- ZooKeeper 用临时节点表示进程存活，连接消失后节点会自动删除。
ZKClient管理 Watch，并每 60 秒刷新监控项，减少漏事件风险。- Lobby/Battle/Team/Channel Worker 连接对应 Manager 并持续上报能力值。
NodeMgr -> ZoneMgr按负载比把节点放入 Low/Middle/High/Full 区。GetFreeNode()优先取低负载节点；GetFreeNodeEx()必要时也检查 Full 区。
sequenceDiagram
participant Caller as Lobby/Team/Matching
participant BM as BattleMgr
participant NM as NodeMgr/ZoneMgr
participant BN as Battle Node
participant BA as Battle Actor
Caller->>BM: TaskBattleMgr_CreateBattle
BM->>NM: GetFreeNodeEx()
NM-->>BM: 低负载 Battle 节点
BM->>BN: TaskRequest(CreateBattle)
BN->>BA: ActorOf + CreateRequest
BN->>BN: DicBattles[battleId] = actor
BN-->>BM: BattleId
BN->>BM: SetParam(当前战斗数)
BM-->>Caller: BattleId
每场战斗是一个独立 Actor。Battle 节点用当前战斗数量作为 Ability 上报，因此可以横向扩容；带 BattleId 的请求必须路由回持有该 Actor 的节点。
5.3 Redis、MySQL 与内存状态
- Redis：登录令牌、战区列表、在线会话、排行、房间索引、离线消息、全局活动状态。
- MySQL：账号、角色、充值和日志等长期数据。
- Lobby Player Actor：玩家在线期间的内存工作副本。
- PlayerMgr：协调缓存读取、Lobby 归属和保存；角色数据由 Protobuf 对象承载。
MySQL 使用 DbShardAuth、DbShardPlayer 等按 key 选分片。新增持久字段不能只改 Lobby 对象，还要检查 proto、EF Entity/Context、旧数据兼容、Redis 缓存和保存时机。
现有 YAML 含敏感配置。不要把密码、平台密钥复制进文档或提交记录；隔离配置应由本地文件或环境注入维护。