3 个环节打通 ET 框架 Actor 模型跨进程通信分布式消息完整指南【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET凌晨 3 点玩家从 1 线跨线进 2 线。传送刚完成Map 进程里一条Frame_ClickMap还按旧地址投给了 1 线——那个 Unit 已经不存在了消息石沉大海玩家原地卡住不动。这不是网络抖动而是分布式服务端的典型地址失效问题也是 ET 框架Unity3D 客户端 C# 服务器单线程多进程用 Actor 模型要正面解决的事让给对象发消息这件事不依赖你记住它在哪个进程。选型篇ET 站在 Erlang 和 Skynet 中间什么位置ET 选了单线程多进程每个进程内只跑一个逻辑线程多核靠多进程吃满。这和 Erlang、Skynet 的单进程多线程正好相反也决定了三者 Actor 的最小粒度完全不同。维度ETErlangSkynet运行形态单线程多进程单进程多线程单进程多线程并发单元Entity 对象Erlang 进程Lua 服务节点单元寻址Entity.InstanceId高 16 位编码进程号Pid 进程号服务地址单元内调度Fiber 协程调度器线程池服务内单线程多机部署天然同构单机集群雏形需分布式 Erlang需额外方案关键差异在第二行Erlang 和 Skynet 的消息只能发到进程/服务这一级发给谁得消息里再带个 id 二次分发ET 把 Actor 下沉到 Entity 对象级一个 Unit、一个 GateSession 本身就是收件人。换句话说把 ET 的整个进程Game.Scene当成一个 Actor就退化成了 Erlang 的进程级模型——Erlang 是 ET 的特例而不是反过来。依据见 Actor Model 官方说明。落地篇用一条 Unit 点击消息走通全链路下面用一个贯穿例子Map 进程里的 Unit 要给自己挂的 GateSession 发一条消息让客户端表现移动全程只用InstanceId寻址。发送从 InstanceId 拿到收件通道// 按 InstanceId 拿到目标 Actor 的 sender var sender Game.Scene.GetComponentActorSenderComponent() .Get(unitGateComponent.GateSessionActorId); sender.Send(message); // 单向投递 var response sender.Call(message); // RPC拿到回包发送方不需要知道 GateSession 在哪个进程。InstanceId的高 16 位直接编码了进程号框架据此决定本地入队还是走跨进程网络这一步对业务代码完全透明。路由这个 InstanceId 是怎么传到 Map 手里的它不是凭空产生的是登录链路上带过来的// Gate 建立会话时挂邮箱标记该 Entity 是 Actor session.AddComponentMailBoxComponent, string(MailboxType.GateSession); // 玩家进地图时把 GateSession 的 InstanceId 传给 Map M2G_CreateUnit createUnit (M2G_CreateUnit)await mapSession.Call( new G2M_CreateUnit() { PlayerId player.Id, GateSessionId session.InstanceId });MailBoxComponent是该 Entity 是 Actor的标记也是它的收件箱。邮箱分两种类型GateSession型收到消息立刻转发给客户端MessageDispatcher型默认把消息按类型分发给对应的 Handler。同一份基础设施两条投递路径。处理两种 Handler 的写法MessageDispatcher邮箱分发时Send 消息和 RPC 消息分别对应两个抽象基类// Send继承 AMActorHandlerActor类型, 消息类型 [ActorMessageHandler(AppType.Map)] public class Actor_TestHandler : AMActorHandlerUnit, Actor_Test { protected override ETTask Run(Unit unit, Actor_Test message) { Log.Debug(message.Info); return ETTask.CompletedTask; } }RPC 多一个响应泛型并通过reply回调回包// RPC继承 AMActorRpcHandlerActor类型, 请求, 响应 [ActorMessageHandler(AppType.Map)] public class Actor_TransferHandler : AMActorRpcHandlerUnit, Actor_TransferRequest, Actor_TransferResponse { protected override async ETTask Run(Unit unit, Actor_TransferRequest message, ActionActor_TransferResponse reply) { try { reply(new Actor_TransferResponse()); } catch (Exception e) { ReplyError(e, reply); } await ETTask.CompletedTask; } }到这里知道 InstanceId → 投递 → 排队 → Handler的完整链路就跑通了。排坑篇三个线上高频坑⚠️ 坑一Handler 里互相 Call整条消息队列冻住现象ACallBBCallCC 又CallA之后三个 Entity 的所有消息再无人处理。根因MailBoxComponent本质是串行队列一条 Handler 没返回ETTask后续消息全部排队等待Call要阻塞等回包环上任何一环等待就全环死锁。解法让 Handler 快速返回把等待挪到独立协程protected override ETTask Run(Unit unit, Actor_Test message) { HandleAsync(unit, message).Coroutine(); // 开新协程不占队列 return ETTask.CompletedTask; }⚠️ 坑二跨服传送窗口期RPC 报Actor 不存在现象玩家传送期间发给他的 RPC 持续失败客户端表现为点了没反应。根因传送时旧进程先删 Entity新进程还没建好这段时间按缓存的InstanceId投递必然落空。解法改用带 Location 的 sender代码见进阶篇它内置失败 → 重查地址 → 重投窗口期消息被锁等待自动吸收业务代码不用改。⚠️ 坑三每条消息都查一次位置服务现象高频给同一对象发消息时Location Server 查询量暴增序列化开销吃掉收益。根因对象迁移是低频事件但查询如果每次都发就按消息频率放大了跨进程 RPC。解法本地缓存InstanceId。ActorLocationSender首条消息才查 Location Server之后直接复用缓存投递失败再回查并重试默认 5 次。配套手段高频小消息合并成一条再发非实时数据攒批处理降低队列与序列化压力。进阶篇Actor Location——换工位不丢消息InstanceId 会随进程迁移而变但Entity.Id终身不变。Actor Location 机制就是让不变的 Id可以寻址会变的 InstanceId。用企业比喻最直观Entity.Id是工号入职终身不变InstanceId是工位号换办公室进程就得换号。Location Server 是前台总机存着工号 → 当前工位号的登记表。Actor 在任何进程创建或迁移完成时都要去总机刷新登记。只报工位号直接投只报工号先查总机再投。投递途中对方刚搬走会收到工位已空发件方等 1 秒、重查总机、重投最多重试 5 次仍失败则抛异常。搬家期间该工号在总机上加锁查这个工号的请求全部排队等搬家完成防止消息投在半路状态里。发送与处理代码与基础 Actor 几乎一致只是基类多了 Location 字样// 按 Entity.Id 拿 Location sender var locationSender Game.Scene .GetComponentActorLocationSenderComponent().Get(unitId); locationSender.Send(message); var response await locationSender.Call(request);[ActorMessageHandler(AppType.Map)] public class Frame_ClickMapHandler : AMActorLocationHandlerUnit, Frame_ClickMap { protected override ETTask Run(Unit unit, Frame_ClickMap message) { Vector3 target new Vector3(message.X, message.Y, message.Z); unit.GetComponentUnitPathComponent().MoveTo(target).Coroutine(); return ETTask.CompletedTask; } }另有一句新人最容易误解的话要讲清Actor 是纯服务端通信机制。客户端消息看起来像 Actor 消息只是 Gate 复用了服务端 Actor 通道做转发并非客户端也跑了一套 Actor。详见 Actor Location 说明。收尾篇上线前检查清单✅ 跨进程传递的位置信息一律用Entity.IdInstanceId只做进程生命周期内的短途缓存✅ 所有可能等待回包的 Handler确认已用RunAsync(...).Coroutine()脱离消息队列✅ 需要跨线/跨场景寻址的对象统一走ActorLocationSender不裸发 InstanceId✅ 高频小消息已合并非实时数据已攒批Location 重试 5 次失败后的异常有日志与兜底学习资源Actor Model 官方说明Actor Location 中文说明项目 README【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
3 个环节打通 ET 框架 Actor 模型跨进程通信分布式消息完整指南【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET凌晨 3 点玩家从 1 线跨线进 2 线。传送刚完成Map 进程里一条Frame_ClickMap还按旧地址投给了 1 线——那个 Unit 已经不存在了消息石沉大海玩家原地卡住不动。这不是网络抖动而是分布式服务端的典型地址失效问题也是 ET 框架Unity3D 客户端 C# 服务器单线程多进程用 Actor 模型要正面解决的事让给对象发消息这件事不依赖你记住它在哪个进程。选型篇ET 站在 Erlang 和 Skynet 中间什么位置ET 选了单线程多进程每个进程内只跑一个逻辑线程多核靠多进程吃满。这和 Erlang、Skynet 的单进程多线程正好相反也决定了三者 Actor 的最小粒度完全不同。维度ETErlangSkynet运行形态单线程多进程单进程多线程单进程多线程并发单元Entity 对象Erlang 进程Lua 服务节点单元寻址Entity.InstanceId高 16 位编码进程号Pid 进程号服务地址单元内调度Fiber 协程调度器线程池服务内单线程多机部署天然同构单机集群雏形需分布式 Erlang需额外方案关键差异在第二行Erlang 和 Skynet 的消息只能发到进程/服务这一级发给谁得消息里再带个 id 二次分发ET 把 Actor 下沉到 Entity 对象级一个 Unit、一个 GateSession 本身就是收件人。换句话说把 ET 的整个进程Game.Scene当成一个 Actor就退化成了 Erlang 的进程级模型——Erlang 是 ET 的特例而不是反过来。依据见 Actor Model 官方说明。落地篇用一条 Unit 点击消息走通全链路下面用一个贯穿例子Map 进程里的 Unit 要给自己挂的 GateSession 发一条消息让客户端表现移动全程只用InstanceId寻址。发送从 InstanceId 拿到收件通道// 按 InstanceId 拿到目标 Actor 的 sender var sender Game.Scene.GetComponentActorSenderComponent() .Get(unitGateComponent.GateSessionActorId); sender.Send(message); // 单向投递 var response sender.Call(message); // RPC拿到回包发送方不需要知道 GateSession 在哪个进程。InstanceId的高 16 位直接编码了进程号框架据此决定本地入队还是走跨进程网络这一步对业务代码完全透明。路由这个 InstanceId 是怎么传到 Map 手里的它不是凭空产生的是登录链路上带过来的// Gate 建立会话时挂邮箱标记该 Entity 是 Actor session.AddComponentMailBoxComponent, string(MailboxType.GateSession); // 玩家进地图时把 GateSession 的 InstanceId 传给 Map M2G_CreateUnit createUnit (M2G_CreateUnit)await mapSession.Call( new G2M_CreateUnit() { PlayerId player.Id, GateSessionId session.InstanceId });MailBoxComponent是该 Entity 是 Actor的标记也是它的收件箱。邮箱分两种类型GateSession型收到消息立刻转发给客户端MessageDispatcher型默认把消息按类型分发给对应的 Handler。同一份基础设施两条投递路径。处理两种 Handler 的写法MessageDispatcher邮箱分发时Send 消息和 RPC 消息分别对应两个抽象基类// Send继承 AMActorHandlerActor类型, 消息类型 [ActorMessageHandler(AppType.Map)] public class Actor_TestHandler : AMActorHandlerUnit, Actor_Test { protected override ETTask Run(Unit unit, Actor_Test message) { Log.Debug(message.Info); return ETTask.CompletedTask; } }RPC 多一个响应泛型并通过reply回调回包// RPC继承 AMActorRpcHandlerActor类型, 请求, 响应 [ActorMessageHandler(AppType.Map)] public class Actor_TransferHandler : AMActorRpcHandlerUnit, Actor_TransferRequest, Actor_TransferResponse { protected override async ETTask Run(Unit unit, Actor_TransferRequest message, ActionActor_TransferResponse reply) { try { reply(new Actor_TransferResponse()); } catch (Exception e) { ReplyError(e, reply); } await ETTask.CompletedTask; } }到这里知道 InstanceId → 投递 → 排队 → Handler的完整链路就跑通了。排坑篇三个线上高频坑⚠️ 坑一Handler 里互相 Call整条消息队列冻住现象ACallBBCallCC 又CallA之后三个 Entity 的所有消息再无人处理。根因MailBoxComponent本质是串行队列一条 Handler 没返回ETTask后续消息全部排队等待Call要阻塞等回包环上任何一环等待就全环死锁。解法让 Handler 快速返回把等待挪到独立协程protected override ETTask Run(Unit unit, Actor_Test message) { HandleAsync(unit, message).Coroutine(); // 开新协程不占队列 return ETTask.CompletedTask; }⚠️ 坑二跨服传送窗口期RPC 报Actor 不存在现象玩家传送期间发给他的 RPC 持续失败客户端表现为点了没反应。根因传送时旧进程先删 Entity新进程还没建好这段时间按缓存的InstanceId投递必然落空。解法改用带 Location 的 sender代码见进阶篇它内置失败 → 重查地址 → 重投窗口期消息被锁等待自动吸收业务代码不用改。⚠️ 坑三每条消息都查一次位置服务现象高频给同一对象发消息时Location Server 查询量暴增序列化开销吃掉收益。根因对象迁移是低频事件但查询如果每次都发就按消息频率放大了跨进程 RPC。解法本地缓存InstanceId。ActorLocationSender首条消息才查 Location Server之后直接复用缓存投递失败再回查并重试默认 5 次。配套手段高频小消息合并成一条再发非实时数据攒批处理降低队列与序列化压力。进阶篇Actor Location——换工位不丢消息InstanceId 会随进程迁移而变但Entity.Id终身不变。Actor Location 机制就是让不变的 Id可以寻址会变的 InstanceId。用企业比喻最直观Entity.Id是工号入职终身不变InstanceId是工位号换办公室进程就得换号。Location Server 是前台总机存着工号 → 当前工位号的登记表。Actor 在任何进程创建或迁移完成时都要去总机刷新登记。只报工位号直接投只报工号先查总机再投。投递途中对方刚搬走会收到工位已空发件方等 1 秒、重查总机、重投最多重试 5 次仍失败则抛异常。搬家期间该工号在总机上加锁查这个工号的请求全部排队等搬家完成防止消息投在半路状态里。发送与处理代码与基础 Actor 几乎一致只是基类多了 Location 字样// 按 Entity.Id 拿 Location sender var locationSender Game.Scene .GetComponentActorLocationSenderComponent().Get(unitId); locationSender.Send(message); var response await locationSender.Call(request);[ActorMessageHandler(AppType.Map)] public class Frame_ClickMapHandler : AMActorLocationHandlerUnit, Frame_ClickMap { protected override ETTask Run(Unit unit, Frame_ClickMap message) { Vector3 target new Vector3(message.X, message.Y, message.Z); unit.GetComponentUnitPathComponent().MoveTo(target).Coroutine(); return ETTask.CompletedTask; } }另有一句新人最容易误解的话要讲清Actor 是纯服务端通信机制。客户端消息看起来像 Actor 消息只是 Gate 复用了服务端 Actor 通道做转发并非客户端也跑了一套 Actor。详见 Actor Location 说明。收尾篇上线前检查清单✅ 跨进程传递的位置信息一律用Entity.IdInstanceId只做进程生命周期内的短途缓存✅ 所有可能等待回包的 Handler确认已用RunAsync(...).Coroutine()脱离消息队列✅ 需要跨线/跨场景寻址的对象统一走ActorLocationSender不裸发 InstanceId✅ 高频小消息已合并非实时数据已攒批Location 重试 5 次失败后的异常有日志与兜底学习资源Actor Model 官方说明Actor Location 中文说明项目 README【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
