作用消息队列Message QueueMQ在 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 StreamsRedis 5.0 引入支持消费者组、消息持久化RDB/AOF、ACK 机制非常适合游戏场景。性能高单机 10 万/s运维简单团队通常已有 Redis。RabbitMQ成熟可靠支持多种路由模式direct/topic/fanout适合复杂的业务路由。大规模多服/跨服DAU 100 万特点海量消息日志、跨服通信、活动需要高吞吐、持久化、分区顺序、多语言客户端。推荐方案Kafka 或 Pulsar。Kafka业界标准百万级 QPS消息持久化到磁盘支持分区内顺序适合日志收集、跨服事件总线。Pulsar腾讯云等大厂在用支持分层存储、多租户延迟更低但运维复杂。自研 MQ 与第三方 MQ 的取舍
作用消息队列Message QueueMQ在 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 StreamsRedis 5.0 引入支持消费者组、消息持久化RDB/AOF、ACK 机制非常适合游戏场景。性能高单机 10 万/s运维简单团队通常已有 Redis。RabbitMQ成熟可靠支持多种路由模式direct/topic/fanout适合复杂的业务路由。大规模多服/跨服DAU 100 万特点海量消息日志、跨服通信、活动需要高吞吐、持久化、分区顺序、多语言客户端。推荐方案Kafka 或 Pulsar。Kafka业界标准百万级 QPS消息持久化到磁盘支持分区内顺序适合日志收集、跨服事件总线。Pulsar腾讯云等大厂在用支持分层存储、多租户延迟更低但运维复杂。自研 MQ 与第三方 MQ 的取舍
