ET框架Actor模型一次讲透Entity级通信到分布式定位的避坑指南【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET游戏服务端里让一个玩家对象跨多个进程稳定收发消息是分布式通信的核心问题。ET框架Unity C# 游戏服务器框架的Actor模型把Actor从进程下沉到Entity对象消息可以直接投递到具体玩家对象无需二次分发。下面按链路顺序拆解邮箱、路由、位置查询三块机制并讲透嵌套RPC死锁、迁移丢消息这类实战坑。适合做Unity C# 服务器多进程架构、维护分线分场景游戏的开发者。玩家从1线迁到2线消息去哪儿了先看真实场景。分线游戏里玩家在线1进程A客户端发出移动消息经Gate到达进程A的Unit对象一切正常。玩家换线到线2进程B后Unit对象在B上重建A上的内存地址全部失效。此时若有消息还按旧地址投递就会打到一间不存在的柜子——这是分布式通信里最典型的丢消息场景。用快递驿站系统对照理解Entity 包裹每个玩家是一件物品进程 驿站每间驿站的柜号独立编号InstanceId 驿站柜号进程分配给Entity的地址换驿站即失效Entity.Id 运单号全局唯一终身不变MailboxComponent 柜子Entity挂了柜子才能收件Location Server 快递总部客服存运单号→驿站柜号的映射Actor模型就是知道柜号直接投递只知道运单号时先去总部客服查当前驿站柜号。整条投递链路接下来在代码层面拆。Entity级Actor对比Erlang/Skynet粒度与调试的差异传统Actor模型为单进程多线程架构设计Actor是进程或虚拟机消息只能投到门进屋后还要按消息里的id二次分发给具体玩家多绕一圈。ET把Actor下沉到Entity对象级消息直接落到具体玩家对象省掉这圈分发。维度ETErlangSkynet并发模型单线程多进程单进程多线程VM轻量进程单进程多线程Lua虚拟机Actor粒度Entity对象对象级Erlang进程进程级Lua虚拟机服务级地址标识Entity.InstanceId进程IDPid服务地址扩展方式加进程或加机器代码不动同进程内开轻量进程同进程内开服务调试体验直接用系统级profiler如top需另配Erlang工具集需另配Skynet工具集上表是跨框架对照原表见 5.4 Actor Model。对新手最有辨识度的其实是后两行ET的进程是普通操作系统进程内存、CPU、死锁排查全部复用现成工具粒度到对象级意味着一个玩家的邮箱队列不会被其他玩家的消息堵住。挂上MailboxComponent任意Entity就是ActorET里Actor不是独立体系而是挂了MailboxComponent的Entity。这里的关键是InstanceId由创建进程在对象出生时分配迁移后作废——后面所有设计都由这条推出来。邮箱内置两种类型GateSession收到消息立即透传给客户端不进handler分发MessageDispatcher默认消息进邮箱队列逐条取出按类型分发给Handler队列串行处理同一Entity的消息顺序天然得到保证。坑也埋在这一条消息若去等其他Actor的响应整个队列都会跟着卡住死锁一节再展开。想读源码从 Packages/cn.etetet.core/Scripts/Model/Share/Actor/ 的邮箱与消息路由实现入手入口很集中。3步拿到ActorMessageSender完成Send/Call发送侧只有三步Scene上取ActorSenderComponent → 按InstanceId调Get → Send或Call。目标在哪个进程不用关心路由由sender负责。// 这段在干嘛Map进程取sender向GateSession发消息 ActorSenderComponent actorSenderComponent Game.Scene.GetComponentActorSenderComponent(); // 为什么sender是Scene组件统一取入口省去记目标进程 ActorMessageSender sender actorSenderComponent.Get(gateSessionActorId); // 传入InstanceId即可跨进程路由在内部完成 sender.Send(message); // 为什么发完不等的消息不用回执开销更低 var response sender.Call(request); // 为什么需要结果的走Call拿到回复才返回执行后消息由sender路由到Gate进程GateSession邮箱直接透传给客户端全程不关心Gate部署在哪台机器。注册AMActorHandler处理器RPC只差两行消息到达邮箱后按类型分发收侧注册handler// 这段在干嘛给Map进程上的Unit注册Send消息处理器 [ActorMessageHandler(AppType.Map)] // 为什么只声明需要处理的进程其它进程不产生注册开销 public class Actor_TestHandler : AMActorHandlerUnit, Actor_Test { protected override ETTask Run(Unit unit, Actor_Test message) { Log.Debug(message.Info); // 第一个泛型Actor类型第二个消息类型 } }执行后发给该Unit的Send消息全部进入此handler。RPC与它只差两处改继承AMActorRpcHandlerUnit, Request, Response方法签名多一个ActionResponse reply处理完主动调用reply(response)回包发送侧的Call才拿得到值。Actor迁走进程后消息丢Location Server兜底只知道运单号Entity.Id时用location sender机制分三步位置注册Actor创建或迁移到新进程时把Entity.Id→InstanceId映射报到Location Server消息路由发送前先查Location Server拿目标InstanceId再走普通Actor通道失败重试投递失败目标已迁走则等1秒重查重发默认最多5次仍失败抛异常// 这段在干嘛按Entity.Id发送location消息 ActorLocationSender locationSender Game.Scene.GetComponentActorLocationSenderComponent().Get(unitId); // 为什么按Id查Location Server之后内部缓存InstanceId不必每次查询 locationSender.Send(actorLocationMessage); // 发送失败会自动重查重发最多5次锁是关键细节迁移中Location Server先对该key加锁其他请求排队等待迁移完成更新地址并解锁搬家途中的消息不会丢等新地址生效继续投递。location消息本身长得和actor消息一样以移动消息为例message Frame_ClickMap // IActorLocationMessageGate按ActorId直接转发 { int64 ActorId 93; // 运单号Entity.Id用来定位目标 int64 Id 94; float X 1; float Y 2; }收侧处理只差一个继承AMActorLocationHandlerUnit, Frame_ClickMap方法体和普通handler一致。完整机制见 5.5 Actor Location。嵌套RPC死锁的最小修复方案先让出再协程邮箱队列一条条处理。handler A里CallBBCallCC又CallA——三个邮箱互相等对方下一条消息谁都没法推进死锁成立。最小修复handler里立即返回把需要等待的逻辑挪进新协程// 这段在干嘛handler需要等其它Actor响应时先让出再执行 protected override ETTask Run(Unit unit, Actor_Test message) { RunAsync(unit, message).Coroutine(); // 为什么立即返回保住邮箱队列打断A→B→C→A的等待环 } public ETVoid RunAsync(Unit unit, Actor_Test message) { Log.Debug(message.Info); }执行后该消息不再占住邮箱队列内部等待响应时也不影响同Entity的其它消息。原则只有一条handler主体只做能立即返回的事跨Actor等待必须走协程。避坑清单与上线前两个动作实战里踩过的四类坑⚠️高频小消息合并逐帧发状态同步会放大序列化开销攒一个tick合批发一次⚠️InstanceId缓存是内置的ActorLocationSender首次查Location Server后走缓存发送失败才重查别再自建缓存层⚠️RPC handler里别回Call发送方最典型死锁姿势改走协程重试5次不是万能目标进程真挂了5次后照样抛异常上层业务要捕获并决定补偿策略上线前两个可执行动作通读 5.4 Actor Model 与 5.5 Actor Location再跑一遍仓库内Actor与ActorLocation相关单元测试确认当前版本的邮箱分发与重试路径可用全项目搜一遍handler的Run方法体体内出现Call的逐一改成协程让出——这是投入产出比最高的一处修改【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ET框架Actor模型一次讲透Entity级通信到分布式定位的避坑指南【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET游戏服务端里让一个玩家对象跨多个进程稳定收发消息是分布式通信的核心问题。ET框架Unity C# 游戏服务器框架的Actor模型把Actor从进程下沉到Entity对象消息可以直接投递到具体玩家对象无需二次分发。下面按链路顺序拆解邮箱、路由、位置查询三块机制并讲透嵌套RPC死锁、迁移丢消息这类实战坑。适合做Unity C# 服务器多进程架构、维护分线分场景游戏的开发者。玩家从1线迁到2线消息去哪儿了先看真实场景。分线游戏里玩家在线1进程A客户端发出移动消息经Gate到达进程A的Unit对象一切正常。玩家换线到线2进程B后Unit对象在B上重建A上的内存地址全部失效。此时若有消息还按旧地址投递就会打到一间不存在的柜子——这是分布式通信里最典型的丢消息场景。用快递驿站系统对照理解Entity 包裹每个玩家是一件物品进程 驿站每间驿站的柜号独立编号InstanceId 驿站柜号进程分配给Entity的地址换驿站即失效Entity.Id 运单号全局唯一终身不变MailboxComponent 柜子Entity挂了柜子才能收件Location Server 快递总部客服存运单号→驿站柜号的映射Actor模型就是知道柜号直接投递只知道运单号时先去总部客服查当前驿站柜号。整条投递链路接下来在代码层面拆。Entity级Actor对比Erlang/Skynet粒度与调试的差异传统Actor模型为单进程多线程架构设计Actor是进程或虚拟机消息只能投到门进屋后还要按消息里的id二次分发给具体玩家多绕一圈。ET把Actor下沉到Entity对象级消息直接落到具体玩家对象省掉这圈分发。维度ETErlangSkynet并发模型单线程多进程单进程多线程VM轻量进程单进程多线程Lua虚拟机Actor粒度Entity对象对象级Erlang进程进程级Lua虚拟机服务级地址标识Entity.InstanceId进程IDPid服务地址扩展方式加进程或加机器代码不动同进程内开轻量进程同进程内开服务调试体验直接用系统级profiler如top需另配Erlang工具集需另配Skynet工具集上表是跨框架对照原表见 5.4 Actor Model。对新手最有辨识度的其实是后两行ET的进程是普通操作系统进程内存、CPU、死锁排查全部复用现成工具粒度到对象级意味着一个玩家的邮箱队列不会被其他玩家的消息堵住。挂上MailboxComponent任意Entity就是ActorET里Actor不是独立体系而是挂了MailboxComponent的Entity。这里的关键是InstanceId由创建进程在对象出生时分配迁移后作废——后面所有设计都由这条推出来。邮箱内置两种类型GateSession收到消息立即透传给客户端不进handler分发MessageDispatcher默认消息进邮箱队列逐条取出按类型分发给Handler队列串行处理同一Entity的消息顺序天然得到保证。坑也埋在这一条消息若去等其他Actor的响应整个队列都会跟着卡住死锁一节再展开。想读源码从 Packages/cn.etetet.core/Scripts/Model/Share/Actor/ 的邮箱与消息路由实现入手入口很集中。3步拿到ActorMessageSender完成Send/Call发送侧只有三步Scene上取ActorSenderComponent → 按InstanceId调Get → Send或Call。目标在哪个进程不用关心路由由sender负责。// 这段在干嘛Map进程取sender向GateSession发消息 ActorSenderComponent actorSenderComponent Game.Scene.GetComponentActorSenderComponent(); // 为什么sender是Scene组件统一取入口省去记目标进程 ActorMessageSender sender actorSenderComponent.Get(gateSessionActorId); // 传入InstanceId即可跨进程路由在内部完成 sender.Send(message); // 为什么发完不等的消息不用回执开销更低 var response sender.Call(request); // 为什么需要结果的走Call拿到回复才返回执行后消息由sender路由到Gate进程GateSession邮箱直接透传给客户端全程不关心Gate部署在哪台机器。注册AMActorHandler处理器RPC只差两行消息到达邮箱后按类型分发收侧注册handler// 这段在干嘛给Map进程上的Unit注册Send消息处理器 [ActorMessageHandler(AppType.Map)] // 为什么只声明需要处理的进程其它进程不产生注册开销 public class Actor_TestHandler : AMActorHandlerUnit, Actor_Test { protected override ETTask Run(Unit unit, Actor_Test message) { Log.Debug(message.Info); // 第一个泛型Actor类型第二个消息类型 } }执行后发给该Unit的Send消息全部进入此handler。RPC与它只差两处改继承AMActorRpcHandlerUnit, Request, Response方法签名多一个ActionResponse reply处理完主动调用reply(response)回包发送侧的Call才拿得到值。Actor迁走进程后消息丢Location Server兜底只知道运单号Entity.Id时用location sender机制分三步位置注册Actor创建或迁移到新进程时把Entity.Id→InstanceId映射报到Location Server消息路由发送前先查Location Server拿目标InstanceId再走普通Actor通道失败重试投递失败目标已迁走则等1秒重查重发默认最多5次仍失败抛异常// 这段在干嘛按Entity.Id发送location消息 ActorLocationSender locationSender Game.Scene.GetComponentActorLocationSenderComponent().Get(unitId); // 为什么按Id查Location Server之后内部缓存InstanceId不必每次查询 locationSender.Send(actorLocationMessage); // 发送失败会自动重查重发最多5次锁是关键细节迁移中Location Server先对该key加锁其他请求排队等待迁移完成更新地址并解锁搬家途中的消息不会丢等新地址生效继续投递。location消息本身长得和actor消息一样以移动消息为例message Frame_ClickMap // IActorLocationMessageGate按ActorId直接转发 { int64 ActorId 93; // 运单号Entity.Id用来定位目标 int64 Id 94; float X 1; float Y 2; }收侧处理只差一个继承AMActorLocationHandlerUnit, Frame_ClickMap方法体和普通handler一致。完整机制见 5.5 Actor Location。嵌套RPC死锁的最小修复方案先让出再协程邮箱队列一条条处理。handler A里CallBBCallCC又CallA——三个邮箱互相等对方下一条消息谁都没法推进死锁成立。最小修复handler里立即返回把需要等待的逻辑挪进新协程// 这段在干嘛handler需要等其它Actor响应时先让出再执行 protected override ETTask Run(Unit unit, Actor_Test message) { RunAsync(unit, message).Coroutine(); // 为什么立即返回保住邮箱队列打断A→B→C→A的等待环 } public ETVoid RunAsync(Unit unit, Actor_Test message) { Log.Debug(message.Info); }执行后该消息不再占住邮箱队列内部等待响应时也不影响同Entity的其它消息。原则只有一条handler主体只做能立即返回的事跨Actor等待必须走协程。避坑清单与上线前两个动作实战里踩过的四类坑⚠️高频小消息合并逐帧发状态同步会放大序列化开销攒一个tick合批发一次⚠️InstanceId缓存是内置的ActorLocationSender首次查Location Server后走缓存发送失败才重查别再自建缓存层⚠️RPC handler里别回Call发送方最典型死锁姿势改走协程重试5次不是万能目标进程真挂了5次后照样抛异常上层业务要捕获并决定补偿策略上线前两个可执行动作通读 5.4 Actor Model 与 5.5 Actor Location再跑一遍仓库内Actor与ActorLocation相关单元测试确认当前版本的邮箱分发与重试路径可用全项目搜一遍handler的Run方法体体内出现Call的逐一改成协程让出——这是投入产出比最高的一处修改【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
