消息系统与进程间通信
Category
networking / IPC 子树总览。覆盖：边界（01）、模式（02）、主/外围判别（03）、延迟吞吐（04）、幂等顺序（05）、选型（06）。
Definition
系统一旦从单进程走向多进程、多线程、多服务，通信问题就不会再是“怎么把数据发过去”这么简单。真正的难点是：哪些链路必须同步拿结果，哪些链路可以异步放手，哪些消息允许重复，哪些消息必须保序，哪些链路一旦积压就会把主系统拖死。
消息系统在游戏工程里经常被两种方式误用。一种是把它当成万能总线，什么请求都想丢进队列；另一种是把它只当成外围工具，低估了事件驱动在削峰、解耦和跨系统协作上的价值。前一种会把主链路做得不可解释，后一种会让系统长期背着大量同步耦合。
这一章讨论的不是某个 MQ 产品，而是消息与 IPC 在工程上的边界问题：什么时候该直接调用，什么时候该走异步事件，为什么主链路和外围链路的通信语义不能混用，延迟、吞吐、顺序和幂等为什么永远在互相拉扯，以及团队到底应该按什么问题去选通信方案。
Related
关系链：IPC 边界（01）→ 通信模式（02）→ 主/外围判别（03）→ 延迟/吞吐取舍（04）→ 幂等与顺序（05）→ 方案选型（06）。上游：server 树的服务拆分；下游：server 树的开源服务器地图（组件落地）。
Reference
节点清单见下节；教程侧同题对照见第 07 讲主题（服务拆分、分布式与控制平面）。
本章文章
- IPC 基础与场景边界：先把“为什么需要 IPC”和“哪些链路适合消息化”说清楚，避免一上来就陷入中间件选型。
- 通信模式：梳理同步调用、异步投递、发布订阅、请求-响应等常见模式分别适合什么问题。
- 主链路与外围链路差异：解释为什么局内主链路通常不能被 MQ 思维直接接管，而外围链路却经常适合事件化。
- 低延迟与高吞吐取舍：把实时性、批处理、削峰、积压和背压放在同一张工程账本里讨论。
- 消息语义、幂等与顺序：讨论至少一次、至多一次、顺序约束、重复投递和业务幂等为什么总是一起出现。
- 如何选通信方案：给出更接近工程现实的选型方法，不按产品名词选，而按链路语义和失败代价选。