1. 1.4 Actor 模型在实时应用中的价值

在前述模型与粒度讨论之外，本节说明：哪一类系统问题常使 Actor 式的设计成为合理选项。不引入新术语；与 zhenyi 能力的对应在 1.4.7 简要列出。

1.1. 1.4.1 实时应用的常见特征

「实时」无统一定义，下列特征常一起出现：

这些特征往往同时要求 有序处理、可控延迟抖动、保护进程内状态。

1.2. 1.4.2 Actor 模型为何常与之匹配

1.2.1. 长连接相关状态

连接级信息（认证、心跳、待发送队列等）需要并发下安全维护。若由单一入口 Actor顺序处理连接事件，可避免在多 goroutine 间分散加锁；若采用共享内存，则需要更细的锁粒度或并发结构，并在连接释放时谨慎清理。

1.2.2. 有状态业务逻辑

例如游戏内的角色属性、IM 的会话与未读等。单 Actor 内顺序处理时，同一实体的修改不会并发交错，减少显式锁；代价是单实例内计算需控制耗时，重活常配合异步 worker（需注意与共享数据的边界）。

1.2.3. 消息路由

报文需到达正确的处理实例（IM、匹配、房间等）。邮箱 + 路由表 的形态与「按类型或分片投递」的需求一致：入口解析后定向到目标 Actor 的邮箱即可。

1.2.4. 故障隔离与恢复

单个处理单元内的 panic 或错误，在监督策略下可限制影响范围并尝试重启；若逻辑分散在大量互不相识的 goroutine 与共享结构上，全局 recover 与状态一致性往往更难归纳。

以上均为概括；具体是否采用 Actor，仍取决于团队熟悉度与业务形态。

1.3. 1.4.3 典型场景（示意）

1.3.1. 游戏服务器

常见特征：大量长连接、高频小消息、低延迟期望、复杂进程内状态与逻辑。

Actor 相关收益（概括）：顺序处理减轻锁竞争带来的抖动；监督与重启有助于局部故障恢复；
  耗时逻辑可异步化，避免长时间占用消息线程（需注意共享数据边界）。

1.3.2. IM

常见特征：连接规模大、消息量大、对送达与延迟敏感。

Actor 相关收益（概括）：分片实例分散负载；粘性路由使同用户相关处理相对稳定；
  跨进程传输常配合消息总线，细节见后文网络与服务发现章节。

1.3.3. 物联网

常见特征：设备数多、单连接消息频率常不高、上下线频繁。

Actor 相关收益（概括）：服务级分片承载大量设备逻辑；限流、熔断等保护入口；
  小消息场景下对象池与拷贝策略对资源使用影响大（实现层话题）。

1.3.4. 低延迟交易类

常见特征：对延迟与一致性要求高。

Actor 相关收益（概括）：顺序处理有利于可预测的时序；网络与实现层可减少分配与排队；
  强一致与「不丢不重」仍需业务与中间件语义共同保证，并非 Actor 标签本身所提供。

1.4. 1.4.4 不适合优先考虑 Actor 的情况

1.4.1. 以计算为主的服务

主路径是 CPU 密集（转码、推理、离线批处理）时，单 Actor 串行易成瓶颈，更适合任务队列、worker 池等形态。

1.4.2. 跨大量单元聚合查询

需从许多隔离单元拉数再聚合时，消息往返成本可能高于集中存储查询；应优先评估数据库或专用分析路径。

1.4.3. 无状态 HTTP API

单纯请求-响应、状态在存储层时，常规 handler + 存储往往足够，引入 Actor 层级未必划算。

1.4.4. 简要自查

同时满足 进程内需维护与连接或会话强相关的状态、长连接或高消息率、对延迟抖动敏感 时，Actor 式架构更值得评估；若多条不满足，可再权衡。

1.5. 1.4.5 zhenyi 的定位

zhenyi 按通用实时后端框架设计，而非单一游戏协议绑定：

• 传输：TCP / WebSocket / KCP 等
• 入口：长连接网关与可选 HTTP
• 多进程：服务发现与消息总线（如 NATS）
• 安全：TLS / GM-TLS 等

是否用于政务、金融等场景，需结合合规与运维要求单独评估。

1.6. 1.4.6 本节要点

长连接、双工、高并发与进程内状态并存时，顺序处理、路由与监督 与 Actor 模型较契合。游戏、IM、物联网、低延迟交易等为常见引用场景，非唯一合法场景。算力型、大聚合查询、纯无状态 API 等则往往不必首选 Actor。zhenyi 提供其一类实现路径，落地深度仍依赖业务与运维。

1.7. 1.4.7 附录：场景与 zhenyi 的关联（索引）

细节以源码与各章为准。