Actor Location Actor模型只需要知道對方的InstanceId就能發送消息，十分方便，但是有時候我們可能無法知道對方的InstanceId，或者是一個Actor的InstanceId會發生變化。這種場景很常見，比如：很多游戲是分線的，一個玩家可能從1線換到2線，還有的游戲是分場景的 ...

Actor Location

Actor模型只需要知道對方的InstanceId就能發送消息，十分方便，但是有時候我們可能無法知道對方的InstanceId，或者是一個Actor的InstanceId會發生變化。這種場景很常見，比如：很多游戲是分線的，一個玩家可能從1線換到2線，還有的游戲是分場景的，一個場景一個進程，玩家從場景1進入到場景2。因為做了進程遷移，玩家對象的InstanceId也就變化了。ET提供了給這類對象發送消息的機制，叫做Actor Location機制。其原理比較簡單：

因為InstanceId是變化的，對象的Entity.Id是不變的，所以我們首先可以想到使用Entity.Id來發送actor消息
提供一個位置進程(Location Server)，Actor對象可以將自己的Entity.Id跟InstanceId作為kv存到位置進程中。發送Actor消息前先去位置進程查詢到Actor對象的InstanceId再發送actor消息。
Actor對象在一個進程創建時或者遷移到一個新的進程時，都需要把自己的Id跟InstanceId註冊到Location Server上去
因為Actor對象是可以遷移的，消息發過去有可能Actor已經遷移到其它進程上去了，所以發送Actor Location消息需要提供一種可靠機制
ActorLocationSender提供兩種方法，Send跟Call，Send一個消息也需要接受者返回一個消息，只有收到返回消息才會發送下一個消息。
Actor對象如果遷移走了，這時會返回Actor不存在的錯誤，發送者收到這個錯誤會等待1秒，然後重新去獲取Actor的InstanceId，然後重新發送，目前會嘗試5次，5次過後，拋出異常，報告錯誤
ActorLocationSender發送消息不會每次都去查詢Location Server，因為對象遷移畢竟比較少見，只有第一次去查詢，之後緩存InstanceId，以後發送失敗再重新查詢。
Actor對象在遷移過程中，有可能其它進程發送過來消息，這時會發生錯誤，所以location server提供了一種Lock的機制。對象在傳送前，刪掉在本進程的信息，然後在location server上加上鎖，一旦鎖上後，其它的對該key的請求會進行隊列。
傳送前因為對方刪除了本進程的actor，所以其它進程會發送失敗，這時候他們會進行重試。重試的時候會重新請求location server，這時候會發現被鎖了，於是一直等待
傳送完成後，要unlock location server上的鎖，並且更新新的地址，然後響應其它的location請求。其它發給這個actor的請求繼續進行下去。

註意，Actor模型是純粹的服務端消息通信機制，跟客戶端是沒什麼關係的，很多用ET的新人看到ET客戶端消息也有Actor介面，以為這是客戶端跟服務端通信的機制，其實不是的。ET客戶端使用這個Actor完全是因為Gate需要對客戶端消息進行轉發，我們可以正好利用服務端actor模型來進行轉發，所以客戶端有些消息也是繼承了actor的介面。假如我們客戶端不使用actor介面會怎麼樣呢？比如，Frame_ClickMap這個消息

message Frame_ClickMap // IActorLocationMessage
{
    int64 ActorId = 93;
    int64 Id = 94;
    
    float X = 1;
    float Y = 2;
    float Z = 3;
}

我們可能就不需要ActorId這個欄位，消息發送到Gate，gate看到是Frame_ClickMap消息，它需要轉發給Map上的Unit，轉發還好辦，gate可以從session中獲取對應的map的unit的位置，然後轉發，問題來了，Frame_ClickMap消息到了map，map怎麼知道消息需要給哪個對象呢？這時候有幾種設計：

在轉發的底層協議中帶上unit的Id，需要比較複雜的底層協議支持。
用一個消息對Frame_ClickMap消息包裝一下，包裝的消息帶上Unit的Id，用消息包裝意味著更大的消耗，增加GC。個人感覺這兩種都很差，不好用，而且就算分發給unit對象處理了，怎麼解決消息重入的問題呢？unit對象仍然需要掛上一個消息處理隊列，然後收到消息扔到隊列裡面。這不跟actor模型重覆了嗎？目前ET在客戶端發給unit的消息做了個設計，消息做成actor消息，gate收到發現是actor消息，直接發到對應的actor上，解決的可以說很漂亮。其實客戶端仍然是使用session.send跟call發送消息，發送的時候也不知道消息是actor消息，只有到了gate，gate才進行了判斷，參考OuterMessageDispatcher.cs

Actor Location消息的處理

ActorLocation消息發送

// 從Game.Scene上獲取ActorLocationSenderComponent，然後通過Entity.Id獲取ActorLocationSender
ActorLocationSender actorLocationSender = Game.Scene.GetComponent<ActorLocationSenderComponent>().Get(unitId);
// 通過ActorLocationSender來發送消息
actorLocationSender.Send(actorLocationMessage);
// 發送Rpc消息
IResponse response = await actorLocationSender.Call(actorLocationRequest);

ActorLocation消息的處理跟Actor消息幾乎一樣，不同的是繼承的兩個抽象類不同，註意actorlocation的抽象類多了個Location

    // 處理send過來的消息， 需要繼承AMActorLocationHandler抽象類，抽象類第一個泛型參數是Actor的類型，第二個參數是消息的類型
    [ActorMessageHandler(AppType.Map)]
    public class Frame_ClickMapHandler : AMActorLocationHandler<Unit, Frame_ClickMap>
    {
        protected override ETTask Run(Unit unit, Frame_ClickMap message)
        {
            Vector3 target = new Vector3(message.X, message.Y, message.Z);
            unit.GetComponent<UnitPathComponent>().MoveTo(target).Coroutine();
            
        }
    }

    // 處理Rpc消息, 需要繼承AMActorRpcHandler抽象類，抽象類第一個泛型參數是Actor的類型，第二個參數是消息的類型，第三個參數是返回消息的類型
    [ActorMessageHandler(AppType.Map)]
    public class C2M_TestActorRequestHandler : AMActorLocationRpcHandler<Unit, C2M_TestActorRequest, M2C_TestActorResponse>
    {
        protected override async ETTask Run(Unit unit, C2M_TestActorRequest message, Action<M2C_TestActorResponse> reply)
        {
            reply(new M2C_TestActorResponse(){Info = "actor rpc response"});
            await ETTask.CompletedTask;
        }
    }

ET的actor跟actor location的比喻

中國有很多城市（進程），城市中有很多人（entity對象）居住，每個人都有身份證號碼（Entity.Id）。一個人每到一個市都需要辦理居住證，分配到唯一的居住證號碼（InstanceId），居住證號碼的格式是2個位元組市編號+4個位元組時間+2個位元組遞增。身份證號碼是永遠不會變化的，但是居住證號碼每到一個城市都變化的。現在有個中國郵政（actor）。假設小明要發信給女朋友小紅

小紅為了收信，自己必須掛載一個郵箱（MailboxComponent），小紅收到消息就會處理。註意這裡處理是一個個進行處理的。有可能小紅會同時收到很多人的信。但是她必須一封一封的信看，比方說小明跟小寶都發了信給小紅，小紅先收到小明的信，再收到了小寶的信。小紅先讀小明的信，小明信中讓小紅給外婆打個電話（產生協程）再給自己回信，註意這期間小紅也不能讀下一封信，必須打完電話後才能讀小寶的信。當然小紅自己可以選擇不處理完成就開始讀小寶的信，做法是小紅開一個新的協程來處理小明的信。
假設小明知道小紅的居住證號碼，那麼郵政（actor）可以根據居住證號碼頭兩位找到小紅居住的城市（進程），然後再根據小紅的居住證編號，找到小紅，把消息投遞到小紅的郵箱（MailboxComponent）中。這種是最簡單的原生的actor模型
ET還支持了一套actor location機制。假設小明不知道小紅的居住證號碼，但是他知道小紅的身份證號碼，怎麼辦呢？郵政開發了一套高級郵政（actor location）想了一個辦法，如果一個人經常搬家，它還想收到信，那他到一個新的城市都必須把自己的居住證跟身份證上報到中央政府（location server），這樣高級郵政能夠通過身份證號碼來發送郵件。方法就是去中央政府拿到小紅的居住證號碼，再利用actor機制發送。
假設小紅之前在廣州市，小明用小紅的身份證給小紅髮信件了。高級郵政獲取了小紅的居住證號碼，給小紅髮信。發信的這個過程中，小紅搬家了，從廣州搬到了深圳，這時小紅在中央政府上報了自己新的居住證。高級郵政的信送到到廣州的時候發現，小紅不在廣州。那麼高級郵政會再次去中央政府獲取小紅的居住證，重新發送，有可能成功有可能再次失敗，這個過程會重覆幾次，如果一直不成功則告訴小明，信件發送失敗了。
高級郵政發信比較貴，而且人搬家的次數並不多，一般小明用高級郵政發信後會記住小紅的居住證，下次再發的時候直接用居住證發信，發送失敗了再使用高級郵政發信。
高級郵政的信都是有回執的，有兩種回執，一種回執沒有內容，只表示小紅收到了信，一種回執帶了小紅的回信。小明在發信的時候可以選擇使用哪種回執形式。小明給小紅不能同時發送兩封信，必須等小紅的回執到了，小明才能繼續發信。

ET開源地址地址：egametang/ET: Unity3D Client And C# Server Framework (github.com) qq群：474643097

ET介紹——Actor Location

Actor Location

Actor Location消息的處理

ET的actor跟actor location的比喻