走进 Akka.NET

官方文档:https://getakka.net/index.html

官网:https://petabridge.com/

 

一、Akka.NET 是什么?

Akka 是一个构建高并发、分布式和弹性消息驱动的工具包。Akka.NET 是 Akka 的一个 .NET 的移植库。

Akka.NET 内部都是 Actor 构成的,Actor 是一个状态、行为、邮箱、子节点和监视者策略构成的容器。

 

二、Akka.NET 的一些基础模块

Akka - 核心 Actor 库
Akka.Remote - 跨节点 Actor 部署/通信
Akka.Cluster - 弹性 Actor 网络(HA)
Akka.Persistence - 事件源, 持久化 Actor 状态 & 恢复
Akka.Streams - 流式工作流
Akka.Cluster.Tools - 集群单例, 分布式发布/订阅
Akka.Cluster.Sharding - 持久化状态分区
Akka.DData - 最终一直的数据复制

 

三、Akka.NET 的架构

 

如图所示,一个 akka 系统有一个跟节点 root,然后 root 有2个子节点,user 和 system ,你定义的 actor 都在 user 下,system 下都是系统定义的

 

四、Akka.NET 发送消息的规则

  • 最多一次交付

  • 每个配对的发送者、接收者对消息保持排序。

 

五、基础 Actor 类型

  • ReceiverActor:如果使用这个类型的 Actor 为基类,使用 Receive<T>(msg=>{}); 来接收消息
  • UntypedActor:如果使用这个类型的 Actor 为基类,需要重写 OnReceive(object message) 方法,然后区分 message 类型

 

六、使用 Akka.NET

  • 普通模式

因为 Helloworld 的例子太多了,官网也有,这里直接略过。

代码在这里  

代码里有些特殊情况的处理没写,这里简单说一下

比如 sender 发送给了 receiver 一个消息,但是 receiver 还有些事情没有准备好,比如发送来一个消息,但是可能需要先登录,那就先缓存下来,等办完事再处理

流程是:先 Stash 消息,开启 Scheduler ,发送 GetToken 消息,token 获取成功返回 GetTokenSuccess 消息,取消 Scheduler ,变成 Redy 状态,正常处理消息

public ReceiveActor()
{
        private ICancelable _cancel;

        public ReceiveActor()
        {
            Receive<TestMsg>(msg =>
            {
                Stash.Stash();
            });

            Receive<GetToken>(msg =>
            {
                GetTokenProcess();
            }

            Receive<GetTokenSuccess>(msg =>
            {
                _cancel?.Cancel();
                _cancel = null;

                Become(Ready);
            });

            if (_cancel == null)
            {
                _cancel = Context.System.Scheduler.ScheduleTellRepeatedlyCancelable(TimeSpan.Zero, TimeSpan.FromSeconds(10), Self, new GetToken(), Self);
            }
        }

        private void Ready()
        {
            Receive<TestMsg>(msg =>
            {
                //Todo
            });

            Stash.UnstashAll();
        }

        private void GetTokenProcess()
        {
            var tokenActor = Context.ActorOf(Props.Create(() => new TokenActor("url")));
            tokenActor.Ask<GetTokenSuccess>(new GetToken
            {
                Token = "",
            }).ContinueWith(tr =>
            {
                if (tr.IsCanceled || tr.IsFaulted)
                {
                    return new GetTokenSuccess();
                }

                return tr.Result;
            }).PipeTo(Self);
        }

        public class GetToken
        {
            public string Token { get; set; }
        }
}

 

 

  • Router

Actor 内部其实是单线程的处理消息的,但是用了 Router 可以把消息分出去给多个节点处理,这里分为2种模式,group 和 pool

先来看 group 配置

akka {
   actor{
      provider = cluster
      deployment {
        /api/myClusterGroupRouter {
          router = broadcast-group # routing strategy
          routees.paths = ["/user/api"] # path of routee on each node
          nr-of-instances = 3 # max number of total routees
          cluster {
             enabled = on
             allow-local-routees = on
             use-role = crawler
          }
        }
      }
   }
}

 

 如图看到在 89节点上注册了 90 和 91 节点的 Routees

 

pool 模式

akka {
   actor{
      provider = cluster
      deployment {
        /api/myClusterPoolRouter {
          router = round-robin-pool # routing strategy
          nr-of-instances = 10 # max number of total routees
          cluster {
             enabled = on
             allow-local-routees = on
             use-role = crawler
             max-nr-of-instances-per-node = 1
          }
        }
      }
   }
}

这种模式其实是在 90 和 91 的节点上分别注册了 89 的 routee,89上是akka.tcp://Sys@localhost:90/remote/akka/tcp/localhost:89/$a 和 akka.tcp://Sys@localhost:91/remote/akka/tcp/localhost:89/$a

 具体代码在这里 

  • Shard

用逻辑 id 联系,不关心集群中的物理位置或管理他们的创建,可以 rebalance (消耗资源比较大,只有差异比较大的时候才会,默认 rebalance-threshold = 10,shard 数量设置为集群节点最大数量的10倍,shard 数量太大消耗大)

整个 ActorSystem 中只能有一个Codinator,在最老的节点上,因为最老的节点被认为是安全的。

如图所示整个系统分为了 Coordinator ,Shard region(typeName), Shard,Entity 部分,节点的路径是  /user/sharding/<typeName>/<shardId>/<entityId> 和普通的路径 /user/<actorName> 不一样

这里使用了 Persistent ,每种数据库的配置完全不同,我是 Redis 的配置,建议使用即时更新的数据库,不更新的很可能是弃用的,比如 mysql。

具体代码在这里

这里需要注意的是:

  1. 只能有一个 Lighthourse —— 否在爆 ID 13 error
  2. 创建 ActorSystem 的时候后边加上 _config.WithFallback(ClusterClientReceptionist.DefaultConfig()).WithFallback(DistributedPubSub.DefaultConfig()); —— 否在爆 ID 9 error
  • 区别

Shard 看着好像也能处理 Router 的问题,但这里又有些区别,此处摘自官方文档,用的自动翻译,请自行理解下:

在一致的散列场景中,整个密钥空间被拼接在我们在路由器配置中定义的参与者数量之间。这究竟意味着什么?单个参与者实例负责处理整个范围的密钥。例如:假设在一个一致的哈希路由器后面,我们有一个数字1-100的密钥空间,在5个参与者之间平均共享。这意味着,第一个参与者将负责处理ID为1-20、第二个参与者21-40、第三个参与者41-60等的所有消息。如果您的目标是每个标识符有一个唯一的参与者,那么对于您的情况来说,这不是一个有效的场景。在集群分片场景的另一边,每个实体(这就是我们如何引用分片参与者)由对(ShardId,EntityId)标识。它是1-1关系,因此用同一对标识的消息保证总是路由到相同的单个实体。 另一个区别是灵活性。一致的哈希路由器几乎是静态的,在您想要调整集群大小的情况下,它们不能很好地工作。你记得以前提到过的拼接键空间的概念吗?想象一下,一旦我们改变分配给它的参与者/节点的实际数量,它将如何工作。当然,这些关键范围也必须改变。因此,在集群大小调整之后,以前处理ID为1-20的消息的演员现在可以处理不同的范围(即,1-15)。这称为“分区切换”。当使用集群切分时,我们的参与者将能够随着集群大小的改变迁移到其他节点,即使在集群大小改变时,也能够保持消息id和分割实体之间的关系。

 

七、总结

除了 stream 没研究,其他的多少都看了一点,因为我没有使用 stream 的场景,其他发现 Helloworld 的入门真的没什么用,只是让你理解 Actor 的开发的思想和模式,实际使用需要多看文档,一点点研究,还有就是官网的博文,再就是一些大神写的例子,

这里放几个网址供大家学习

GitHub:

https://github.com/cgstevens/FileProcessor

https://github.com/Horusiath/AkkaDemos

https://github.com/petabridge/akkadotnet-code-samples

https://github.com/Lutando/Akkatecture

 

文档:

Streams:https://petabridge.com/blog/akkadotnet-11-cluster-streams/

Distributed Pub-Sub:https://petabridge.com/blog/distributed-pub-sub-intro-akkadotnet/

Shard:https://petabridge.com/blog/introduction-to-cluster-sharding-akkadotnet/

Shard:https://petabridge.com/blog/cluster-sharding-technical-overview-akkadotnet/

Petabridge.Cmd:https://petabridge.com/blog/petabridgecmd-release/

Moonitoring:https://github.com/petabridge/akka-monitoring

你是不是感觉很奇怪,没有 Dashboard 呢,其实是有,但是收费,在这里:https://phobos.petabridge.com/

 

posted @ 2018-12-20 16:21  Blue-G  阅读(...)  评论(...编辑  收藏