消息总线（共享内存 IPC）

游戏后台通信总线 · 共享内存零拷贝 IPC · 世界-集群-实例寻址 · 环形队列

说明

本文描述的是游戏后台的进程间/服务间通信总线组件。以下按公开可知的架构原理层面描述其设计思想与取舍，不涉及内部私有数字或未公开实现细节。

场景问题

打个比方：同一台机器上的进程互发消息，要是每次都走网络（哪怕是 localhost socket），就像同办公室两个人非要打电话——还得经接线员转接、话还得你念一遍、我抄一遍（数据在内核态用户态之间来回拷贝），又慢又费。共享内存则像两人共用一块白板：你写、我直接看，谁都不用抄（零拷贝）。而环形队列就是这块白板容量有限、写满了从头覆盖，读的人得及时跟上别被覆盖掉。至于层次化寻址（世界-集群-实例），好比"公司-部门-工位"的三级门牌号——你只管认门牌，系统自动判断对方在同一栋楼（走白板/共享内存）还是异地分部（发快递/跨机 relay），位置对你透明。类比失效边界：共用白板快归快，但也丢掉了网络那层天然隔离——某个进程一旦写脏了白板、或写越了界，同机所有读它的进程都可能读到垃圾数据甚至跟着崩。所以共享内存必须靠严格的读写约定 + 内存屏障来自律，不像 socket 那样有进程隔离替你兜底。

一台游戏物理机上跑着几十上百个进程：接入网关、逻辑服、场景服、AI、匹配、DB 代理……它们要高频互发消息。战斗帧里，一次玩家操作可能触发场景服 → AI → 逻辑服 → 接入回包的连锁调用，且要在一帧（几十毫秒）内跑完。

如果这些同机进程之间走 RPC over TCP（gRPC / 自研 TCP RPC）：

• 每条消息要经过内核协议栈：send() 拷贝到内核 socket buffer → 回环 → 另一进程 recv() 再拷贝回用户态，两次数据拷贝 + 两次系统调用 + 内核调度。
• loopback 虽不过网卡，但内核态往返 + 拷贝在每帧上万次调用下会吃掉可观的 CPU 与延迟抖动。
• 跨机时还要真正走网络，需要统一的寻址与路由，不能让每个业务进程各自维护"谁在哪台机的哪个端口"。

于是需要一条统一通信总线：同机走共享内存零拷贝极致低延迟，跨机走网络通道，并用一套层次化地址统一寻址，业务只管"发给某个逻辑地址"，不关心对端在本机还是远端。

实现方案

1. 层次化寻址（GCIM 思想：世界-集群-实例-模块）

消息总线用一套结构化地址标识每个通信端点，而非"IP:Port"。可理解为多段编码：

Address = World . Cluster . Instance . Module
          世界    集群      实例      模块
例：  区服1 . 战斗集群 . GameSvr-3 . 场景管理器

• 业务发消息只写逻辑地址（"发给区服1的匹配模块"），总线负责把它翻译成"本机某共享内存 channel"或"某远端 relay 通道"。
• 地址与物理位置解耦：进程迁移、扩缩容后，只需更新地址表映射，发送方代码不变。

2. 共享内存环形队列（本机零拷贝核心）

同机两进程通过一段 mmap 的共享内存，里面是一个 SPSC/MPSC 环形队列（ring buffer）。发送方写、接收方读，靠头尾指针推进，无需内核参与数据搬运：

// 共享内存单生产者单消费者环形队列（伪码，示意零拷贝 IPC）
typedef struct {
    volatile uint64_t head;   // 消费者读位置（放共享内存头部）
    volatile uint64_t tail;   // 生产者写位置
    uint64_t          cap;    // 容量（2 的幂，& 掩码取模）
    uint8_t           buf[];  // 柔性数组，位于同一 mmap 段
} ShmRing;

// 生产者：写一条消息（跨进程，无系统调用、无内核拷贝）
int ring_push(ShmRing *r, const void *msg, uint32_t len) {
    uint64_t t = r->tail;
    uint64_t h = __atomic_load_n(&r->head, __ATOMIC_ACQUIRE);
    if (t - h + len + 4 > r->cap) return -EAGAIN;   // 满 → 背压，交上层处理
    uint64_t off = t & (r->cap - 1);
    memcpy(&r->buf[off], &len, 4);                   // 长度前缀
    memcpy(&r->buf[off + 4], msg, len);              // 直接写进共享内存
    __atomic_store_n(&r->tail, t + 4 + len, __ATOMIC_RELEASE); // 发布：release 屏障
    return 0;
}

// 消费者：读一条消息（对端进程 mmap 同一段内存）
int ring_pop(ShmRing *r, void *out, uint32_t *len) {
    uint64_t h = r->head;
    uint64_t t = __atomic_load_n(&r->tail, __ATOMIC_ACQUIRE);
    if (h == t) return -EAGAIN;                       // 空
    uint64_t off = h & (r->cap - 1);
    memcpy(len, &r->buf[off], 4);
    memcpy(out, &r->buf[off + 4], *len);
    __atomic_store_n(&r->head, h + 4 + *len, __ATOMIC_RELEASE);
    return 0;
}

3. 消息可靠性与背压

• 背压：ring 满时 ring_push 返回 EAGAIN，上层选择丢弃（可容忍帧）、缓冲重试、或反压上游，而不是无限堆积 OOM。
• 可靠性：同机共享内存本身可靠；跨机 relay 通道上做序号 + 重传（或依赖 TCP）。业务层对关键消息加 seq/ack 幂等。

为什么这么做

为什么同机用共享内存总线而非 RPC over TCP？

游戏后台每帧上万次同机调用，延迟与抖动直接决定帧率是否稳定，共享内存把每次调用的固定开销压到极低。

为什么要统一寻址而非各进程自己记 IP:Port？

• 进程会迁移、扩缩容、重启换端口。业务写死物理地址就得跟着改。层次化逻辑地址 + 地址表，让位置透明：发送方永远只写逻辑地址。

为什么别的选择不行

沉淀结论

记忆口诀

通道：同机共享内存 ring / 跨机网络 relay / 混合模型
寻址：世界-集群-实例-模块（GCIM）/ 逻辑地址 / 位置透明
零拷贝：一份内存 / 无内核往返 / 无系统调用
背压：ring 满 EAGAIN / 丢·缓·反压 / 拒绝 OOM

相关专题：接入网关（长连接接入层） · 自研 Mesh 服务网格 × K8s · 中心化 vs 去中心化网格

内容来源

综合整理。参考方向：共享内存 IPC 与无锁环形队列（SPSC/MPSC ring buffer）通用原理、mmap 零拷贝进程间通信的行业通行做法、游戏后台共享内存总线的公开介绍（共享内存总线 + 层次化寻址思想）、Service Mesh / gRPC 与本机 IPC 的性能取舍讨论。内部实现细节未公开，本文仅从设计思想与取舍层面描述。

自测：合上资料能说清楚吗？

同机高频进程通信，为什么共享内存 ring 比 TCP loopback 快？各省掉了什么？

层次化地址（世界-集群-实例-模块）解决了什么问题？没有它会怎样？

ring buffer 写满时怎么办？为什么不能无限扩容？

同机既然共享内存这么快，为什么不所有服务都用它，还要保留网络 relay？（对比两方案）

消息总线与 Service Mesh sidecar 在游戏帧内通信场景的取舍差异是什么？