聊天服拓扑关系

1. 聊天服独立于游戏服，客户端直连聊天服
2. 客户端按 PlayerID 散列，连接聊天服
3. 有涉及扣道具才能发言的等（必须依赖游戏服功能的），先走游戏服，其他均可以直接走聊天服

聊天频道 - 世界频道

1. 客户端请求游戏服，发送世界频道聊天
2. 检查 CD 、 扣道具
3. 游戏服请求所有聊天服发送一条世界频道消息
4. 聊天服按批次给玩家发送世界频道消息

类似的，系统频道

聊天频道 - 附近频道

1. 游戏服获取 PlayerID 集合
2. 游戏服根据散列算法得若干个 PlayerID 子集合，发送给对应的聊天服
3. 对应聊天服按 PlayerID 子集合，给对应玩家发送消息

私聊

1. 聊天赋独立 DB 保存离线消息、私聊历史
2. 玩家给聊天服发送私聊
3. 聊天服根据散列算法，把消息投递到对应聊天服
4. 对应聊天服给目标玩家发送消息或保存离线消息
5. 玩家登录从聊天服获取离线消息
6. 玩家可以通过聊天服获取私聊历史

组队聊天

类似还有公会聊天、好友群组聊天

1. 游戏服需要把组队相关事件，转化为对应聊天服对应群组管理 API 调用
2. 聊天服把群组信息存 DB
   • 组队时效性短可以用 Redis + LRU 缓存
   • 公会、好友群组可以用 MySQL + LRU 缓存
   • 群组都要有 UUID ，散列聊天服
3. 玩家给聊天服发送群组消息
   • 聊天服转发给对应的聊天服
4. 聊天服获取 PlayerID 集合
5. 聊天服根据散列算法得若干个 PlayerID 子集合，发送给对应的聊天服
6. 对应聊天服按 PlayerID 子集合，给对应玩家发送消息
7. 聊天服需要存储群组聊天历史、玩家获取历史记录功能

玩家是否在线

• 群组聊天，玩家获取群组信息，需要显示是否在线
• 聊天服群发消息时，可以根据玩家是否在线，减少发送消息量

因此：

• 聊天服定期同步自身有哪些玩家给其他聊天服
  • 其他聊天服上的群组，可以根据这信息确定这些玩家在线
  • 群组成员维护心跳时间，可以确定玩家已经下线
• 聊天服重启，或遇到 LRU 缓存中无的群组，LRU 缓存后，聊天服可以慢速向其他聊天服询问某玩家是否在线

是否需要引入消息队列 Kafka

• 一般不需要
• 如果聊天服消息处理不过来，再引入 Kafka
• 重构的代码很少
  • 原来聊天服给其他聊天服转发消息的地方，改为向 Kafka 发送消息
  • 原来监听处理其他聊天服到来的消息的地方，改为从 Kafka 消费消息

哈希算法定位玩家路由

用哈希算法做玩家-聊天服的路由，是最轻量。但是对于聊天服失效、扩容、缩容需要做些而外的处理

（如果感觉复杂，可以把路由信息所有聊天服同步、全量路由副本）

额外处理：

• 如果是私聊，聊天服返回 MOVE 消息，玩家需要重新连接新聊天服
• 玩家与聊天服定期心态，聊天服返回 MOVE 消息，玩家需要重新连接新聊天服

这样机制，失效、扩容、缩容时，玩家可能会丢失 1 个心跳期间的消息，但是不重要可以接受

• 世界频道聊天这种消息会丢失
• 私聊离线消息特做的不会丢失
• 群组聊天历史消息，不会丢失
• 组队聊天这种无历史消息的，会丢失最大 1 个心跳期间的消息

多个区公用聊天服

• 聊天服上的玩家，多一个容器组织：区-玩家列表
• 聊天服上的玩家，多一个容器组织：玩家-区ID