Book增加Actor跟Actor Location两篇文章

Book/5.4Actor模型.md

@@ -0,0 +1,95 @@
+# Actor模型
+### Actor介绍
+在讨论Actor模型之前先要讨论下ET的架构，游戏服务器为了利用多核一般有两种架构，单线程多进程跟单进程多线程架构。两种架构本质上其实区别不大，因为游戏逻辑开发都需要用单线程，即使是单进程多线程架构，也要用一定的方法保证单线程开发逻辑。ET采用的是单线程多进程的架构，而传统Actor模型一般是单进程多线程的架构，这点是比较大的区别，不能说谁更好，只能说各有优势。优劣如下：  
+1. 逻辑需要单线程这点都是一样的，erlang进程逻辑是单线程的，skynet lua虚拟机也是单线程的。ET中一个进程其实相当于一个erlang进程，一个skynet lua虚拟机。  
+2. 采用单线程多进程不需要自己再写一套profiler工具，可以利用很多现成的profiler工具，例如查看内存，cpu占用直接用top命令，这点erlang跟skynet都需要自己另外搞一套工具。  
+3. 多进程单线程架构还有个好处，单台物理机跟多台物理机是没有区别的，单进程多线程还需要考虑多台物理机的处理。  
+4. 多进程单线程架构一点缺陷是消息跨进程需要进行序列化反序列化，占用一点资源。另外发送网络消息会有几毫秒延时。一般这些影响可以忽略。  
+
+最开始Actor模型是给单进程多线程架构使用的，这是有原因的，因为多线程架构开发者很容易随意的访问共享变量，比方说一个变量a, 线程1能访问，线程2也能访问，这样两个线程在访问变量a的时候都需要加锁，共享变量多了之后锁到处都是，会变得无法维护，框架肯定不能出现到处是线程共享变量的情况。为了保证多线程架构不出问题，必须提供一种开发模型保证多线程开发简单又安全。erlang语言的并发机制就是actor模型。erlang虚拟机使用多线程来利用多核。erlang设计了一种机制，它在虚拟机之上设计了自己的进程。最简单的，每个erlang进程都管理自己的变量，每个erlang进程的逻辑都跑在一个线程上，erlang进程跟进程之间逻辑完全隔离，这样就不存在两个线程访问同一变量的情况了也就不存在多线程竞争的问题。接下来问题又出现了，既然每个erlang进程都有自己的数据，逻辑完全是隔离的，两个erlang进程之间应该怎么进行通信呢？这时Actor模型就登场了。erlang设计了一种消息机制：一个进程可以向其它进程发送消息，erlang进程之间通过消息来进行通信，看到这会不会感觉很熟悉？这不就是操作系统进程间通信用的消息队列吗？没错，其实是类似的。erlang里面拿到进程的id就能给这个进程发送消息。   
+
+如果消息只发给进程其实还是有点不方便。比如拿一个erlang进程做moba战队进程，战斗进程中有10个玩家，如果使用erlang的actor消息，消息只能发送给战斗进程，但是很多时候消息是需要发送给一个玩家的，这时erlang需要根据消息中的玩家Id，把消息再次分发给具体的玩家，这样其实多绕了一圈。
+
+### ET的Actor
+ET根据自己架构得特点，没有完全照搬erlang的Actor模型，而是提供了Entity对象级别的Actor模型。这点跟erlang甚至传统的Actor机制不一样。ET中，Actor是Entity对象，Entity挂上一个MailboxComponent组件就是一个Actor了。只需要知道Entity的InstanceId就可以发消息给这个Entity了。其实erlang的Actor模型不过是ET中的一种特例，比如给ET服务端Game.Scene当做一个Actor，这样就可以变成进程级别的Actor。Actor本质就是一种消息机制，这种消息机制不用关心位置，只需要知道对方的InstanceId（ET）或者进程的Pid（erlang）就能发给对方。
+
+| 语言 | ET | Erlang | Skynet |
+| -- | :--: | :--: | :--: |
+| 架构 |  单线程多进程 | 单进程多线程 | 单进程多线程 |
+| Actor |  Entity | erlang进程 | lua虚拟机 |
+| ActorId |  Entity.InstanceId | erlang进程Id | 服务地址 |
+
+### ET的Actor的使用
+普通的Actor，我们可以参照Gate Session。map中一个Unit，Unit身上保存了这个玩家对应的gate session。这样，map中的消息如果需要发给客户端，只需要把消息发送给gate session，gate session在收到消息的时候转发给客户端即可。map进程发送消息给gate session就是典型的actor模型。它不需要知道gate session的位置，只需要知道它的InstanceId即可。MessageHelper.cs中，通过GateSessionActorId获取一个ActorMessageSender，然后发送。
+```csharp
+// 从Game.Scene上获取ActorSenderComponent，然后通过InstanceId获取ActorMessageSender
+ActorSenderComponent actorSenderComponent = Game.Scene.GetComponent<ActorSenderComponent>();
+ActorMessageSender actorMessageSender = actorSenderComponent.Get(unitGateComponent.GateSessionActorId);
+// send
+actorMessageSender.Send(message);
+
+// rpc
+var response = actorMessageSender.Call(message);
+```
+
+问题是map中怎么才能知道gate session的InstanceId呢？这就是你需要想方设法传过去了，比如ET中，玩家在登录gate的时候，gate session挂上一个信箱MailBoxComponent，C2G_LoginGateHandler.cs中
+```csharp
+session.AddComponent<MailBoxComponent, string>(MailboxType.GateSession);
+```
+玩家登录map进程的时候会把这个gate session的InstanceId带进map中去，C2G_EnterMapHandler.cs中
+```csharp
+M2G_CreateUnit createUnit = (M2G_CreateUnit)await mapSession.Call(new G2M_CreateUnit() { PlayerId = player.Id, GateSessionId = session.InstanceId });
+```
+
+### Actor消息的处理
+首先，消息到达MailboxComponent，MailboxComponent是有类型的，不同的类型邮箱可以做不同的处理。目前有两种邮箱类型GateSession跟MessageDispatcher。GateSession邮箱在收到消息的时候会立即转发给客户端，MessageDispatcher类型会再次对Actor消息进行分发到具体的Handler处理，默认的MailboxComponent类型是MessageDispatcher。自定义一个邮箱类型也很简单，继承IMailboxHandler接口，加上MailboxHandler标签即可。那么为什么需要加这么个功能呢，在其它的actor模型中是不存在这个特点的，一般是收到消息就进行分发处理了。原因是GateSession的设计，并不需要进行分发处理，因此我在这里加上了邮箱类型这种设计。MessageDispatcher的处理方式有两种一种是处理对方Send过来的消息，一种是rpc消息  
+```csharp
+    // 处理Send的消息, 需要继承AMActorHandler抽象类，抽象类第一个泛型参数是Actor的类型，第二个参数是消息的类型
+	[ActorMessageHandler(AppType.Map)]
+	public class Actor_TestHandler : AMActorHandler<Unit, Actor_Test>
+	{
+		protected override ETTask Run(Unit unit, Actor_Test message)
+		{
+			Log.Debug(message.Info);
+		}
+	}
+
+    // 处理Rpc消息, 需要继承AMActorRpcHandler抽象类，抽象类第一个泛型参数是Actor的类型，第二个参数是消息的类型，第三个参数是返回消息的类型
+    [ActorMessageHandler(AppType.Map)]
+	public class Actor_TransferHandler : AMActorRpcHandler<Unit, Actor_TransferRequest, Actor_TransferResponse>
+	{
+		protected override async ETTask Run(Unit unit, Actor_TransferRequest message, Action<Actor_TransferResponse> reply)
+		{
+			Actor_TransferResponse response = new Actor_TransferResponse();
+
+			try
+			{
+				reply(response);
+			}
+			catch (Exception e)
+			{
+				ReplyError(response, e, reply);
+			}
+		}
+	}
+```
+
+我们需要注意一下，Actor消息有死锁的可能，比如A call消息给B，B call给C，C call给A。因为MailboxComponent本质上是一个消息队列，它开启了一个协程会一个一个消息处理，返回ETTask表示这个消息处理类会阻塞MailboxComponent队列的其它消息。所以如果出现死锁，我们就不希望某个消息处理阻塞掉MailboxComponent其它消息的处理，我们可以在消息处理类里面新开一个协程来处理就行了。例如:
+```csharp
+	[ActorMessageHandler(AppType.Map)]
+	public class Actor_TestHandler : AMActorHandler<Unit, Actor_Test>
+	{
+		protected override ETTask Run(Unit unit, Actor_Test message)
+		{
+			RunAsync(unit, message).Coroutine();
+		}
+
+        public ETVoid RunAsync(Unit unit, Actor_Test message)
+        {
+            Log.Debug(message.Info);
+        }
+	}
+```
+相关资料可以谷歌一下Actor死锁的问题。
+
+

Book/5.5Actor Location.md

@@ -0,0 +1,77 @@
+# Actor Location
+### Actor Location
+Actor模型只需要知道对方的InstanceId就能发送消息，十分方便，但是有时候我们可能无法知道对方的InstanceId，或者是一个Actor的InstanceId会发生变化。这种场景很常见，比如：很多游戏是分线的，一个玩家可能从1线换到2线，还有的游戏是分场景的，一个场景一个进程，玩家从场景1进入到场景2。因为做了进程迁移，玩家对象的InstanceId也就变化了。ET提供了给这类对象发送消息的机制，叫做Actor Location机制。其原理比较简单：
+1. 因为InstanceId是变化的，对象的Entity.Id是不变的，所以我们首先可以想到使用Entity.Id来发送actor消息
+2. 提供一个位置进程(Location Server)，Actor对象可以将自己的Entity.Id跟InstanceId作为kv存到位置进程中。发送Actor消息前先去位置进程查询到Actor对象的InstanceId再发送actor消息。
+3. Actor对象在一个进程创建时或者迁移到一个新的进程时，都需要把自己的Id跟InstanceId注册到Location Server上去
+4. 因为Actor对象是可以迁移的，消息发过去有可能Actor已经迁移到其它进程上去了，所以发送Actor Location消息需要提供一种可靠机制
+5. ActorLocationSender提供两种方法，Send跟Call，Send一个消息也需要接受者返回一个消息，只有收到返回消息才会发送下一个消息。
+6. Actor对象如果迁移走了，这时会返回Actor不存在的错误，发送者收到这个错误会等待1秒，然后重新去获取Actor的InstanceId，然后重新发送，目前会尝试5次，5次过后，抛出异常，报告错误
+7. ActorLocationSender发送消息不会每次都去查询Location Server，因为对象迁移毕竟比较少见，只有第一次去查询，之后缓存InstanceId，以后发送失败再重新查询。
+8. Actor对象在迁移过程中，有可能其它进程发送过来消息，这时会发生错误，所以location server提供了一种Lock的机制。对象在传送前，删掉在本进程的信息，然后在location server上加上锁，一旦锁上后，其它的对该key的请求会进行队列。
+9. 传送前因为对方删除了本进程的actor，所以其它进程会发送失败，这时候他们会进行重试。重试的时候会重新请求location server，这时候会发现被锁了，于是一直等待
+10. 传送完成后，要unlock location server上的锁，并且更新新的地址，然后响应其它的location请求。其它发给这个actor的请求继续进行下去。
+
+注意，Actor模型是纯粹的服务端消息通信机制，跟客户端是没什么关系的，很多用ET的新人看到ET客户端消息也有Actor接口，以为这是客户端跟服务端通信的机制，其实不是的。ET客户端使用这个Actor完全是因为Gate需要对客户端消息进行转发，我们可以正好利用服务端actor模型来进行转发，所以客户端有些消息也是继承了actor的接口。假如我们客户端不使用actor接口会怎么样呢？比如，Frame_ClickMap这个消息
+```protobuf
+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怎么知道消息需要给哪个对象呢？这时候有几种设计：
+1. 在转发的底层协议中带上unit的Id，需要比较复杂的底层协议支持。
+2. 用一个消息对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消息发送
+```csharp
+// 从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
+```csharp
+	// 处理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）。假设小明要发信给女朋友小红
+1. 小红为了收信，自己必须挂载一个邮箱（MailboxComponent），小红收到消息就会处理。注意这里处理是一个个进行处理的。有可能小红会同时收到很多人的信。但是她必须一封一封的信看，比方说小明跟小宝都发了信给小红，小红先收到小明的信，再收到了小宝的信。小红先读小明的信，小明信中让小红给外婆打个电话（产生协程）再给自己回信，注意这期间小红也不能读下一封信，必须打完电话后才能读小宝的信。当然小红自己可以选择不处理完成就开始读小宝的信，做法是小红开一个新的协程来处理小明的信。
+2. 假设小明知道小红的居住证号码，那么邮政（actor）可以根据居住证号码头两位找到小红居住的城市（进程），然后再根据小红的居住证编号，找到小红，把消息投递到小红的邮箱（MailboxComponent）中。这种是最简单的原生的actor模型
+3. ET还支持了一套actor location机制。假设小明不知道小红的居住证号码，但是他知道小红的身份证号码，怎么办呢？邮政开发了一套高级邮政（actor location）想了一个办法，如果一个人经常搬家，它还想收到信，那他到一个新的城市都必须把自己的居住证跟身份证上报到中央政府（location server），这样高级邮政能够通过身份证号码来发送邮件。方法就是去中央政府拿到小红的居住证号码，再利用actor机制发送。
+4. 假设小红之前在广州市，小明用小红的身份证给小红发信件了。 高级邮政获取了小红的居住证号码，给小红发信。发信的这个过程中，小红搬家了，从广州搬到了深圳，这时小红在中央政府上报了自己新的居住证。 高级邮政的信送到到广州的时候发现，小红不在广州。那么高级邮政会再次去中央政府获取小红的居住证，重新发送，有可能成功有可能再次失败，这个过程会重复几次，如果一直不成功则告诉小明，信件发送失败了。
+5. 高级邮政发信比较贵，而且人搬家的次数并不多，一般小明用高级邮政发信后会记住小红的居住证，下次再发的时候直接用居住证发信，发送失败了再使用高级邮政发信。
+6. 高级邮政的信都是有回执的，有两种回执，一种回执没有内容，只表示小红收到了信，一种回执带了小红的回信。小明在发信的时候可以选择使用哪种回执形式。小明给小红不能同时发送两封信，必须等小红的回执到了，小明才能继续发信。