作用
消息队列（Message Queue，MQ）在 MMO 中主要用于异步解耦、削峰填谷、跨服通信、事件驱动。
使用场景
- 跨服通信
场景：玩家 A 在 1 服给 2 服的玩家 B 发送邮件、赠送礼物、跨服组队邀请。
为什么需要 MQ：跨服不能直接 RPC 调用（网络延迟、服务不可用、耦合），MQ 作为中间层，发送方只管发，接收方异步处理。
自研 MQ 做法：每个服启动一个 MQ 服务进程，跨服消息通过 TCP 连接转发到目标服的 MQ，目标服消费者处理。
- 充值回调
场景：支付平台回调通知“玩家 X 充值 648 元成功”。
为什么需要 MQ：回调是外部 HTTP 请求，处理时间不确定（可能涉及发货、邮件、日志、推送），直接在主线程处理会阻塞；MQ 可以将回调消息暂存，后端慢慢消费。
关键点：充值消息必须可靠投递（至少一次），且需要去重（防止重复发货）。
- 日志收集
场景：玩家行为日志（登录、升级、购买、PVP 胜负）需要汇总到分析平台。
为什么需要 MQ：日志量极大（每秒数万条），直接写文件或 DB 会拖慢游戏服；MQ 作为缓冲，消费者批量写入 ClickHouse/Elasticsearch。
- 异步任务
场景：玩家离线后，系统需要处理工会战结算、邮件过期清理、排行榜重算。
为什么需要 MQ：这些任务不需要玩家在线等待，通过 MQ 触发后台 Worker 处理，解耦主逻辑。
- 削峰填谷
场景：开服活动瞬间涌入大量玩家，同时请求“领取奖励”“购买礼包”。
为什么需要 MQ：直接处理会导致数据库/Redis 被打爆，MQ 将请求排队，后端按节奏处理。
- 模块解耦
场景：玩家升级后，需要触发成就系统、任务系统、邮件系统、公会系统等多个模块。
为什么需要 MQ：如果用同步调用，升级逻辑会越来越重；改为发布“PlayerLevelUp”事件到 MQ，各系统订阅处理，主流程只关注核心逻辑。
不同并发规模的技术方案
- 小规模（单服 < 1 万人，DAU < 10 万）
特点：并发低，逻辑简单，团队小，运维能力弱。
推荐方案：自研内存队列（如 Skynet 内部 service 间的消息传递）或 Redis List。
自研 MQ（基于内存）：Skynet 本身的 actor 模型就是天然的消息队列，service 之间通过 skynet.send 发送消息，由 Skynet 调度。如果需要跨进程，可以用 Unix Socket 或共享内存。
Redis List：用 LPUSH 生产，BRPOP 消费，支持阻塞读取，简单可靠。
- 中等规模（单服 1-5 万人，DAU 10-50 万）
特点：跨服通信增多，日志量上升，需要一定的持久化和可靠性。
推荐方案：Redis Streams 或 RabbitMQ（轻量级）。
Redis Streams：Redis 5.0 引入，支持消费者组、消息持久化（RDB/AOF）、ACK 机制，非常适合游戏场景。性能高（单机 10 万+/s），运维简单（团队通常已有 Redis）。
RabbitMQ：成熟可靠，支持多种路由模式（direct/topic/fanout），适合复杂的业务路由。
- 大规模（多服/跨服，DAU 100 万+）
特点：海量消息（日志、跨服通信、活动），需要高吞吐、持久化、分区顺序、多语言客户端。
推荐方案：Kafka 或 Pulsar。
Kafka：业界标准，百万级 QPS，消息持久化到磁盘，支持分区内顺序，适合日志收集、跨服事件总线。
Pulsar：腾讯云等大厂在用，支持分层存储、多租户，延迟更低，但运维复杂。