akka cluster集群 集群怎么调用

  上篇我们介绍了distributed pub/sub消息传递机制這是在同一个集群内的消息共享机制:发布者(publisher)和订阅者(subscriber)都在同一个集群的节点上,所有节点上的DistributedPubSubMediator通过集群内部的沟通机制在底层構建了消息流通渠道在actor pub/sub层面可以实现对象位置透明化。在现实里很多前端都会作为某个集群的客户端但又与集群分离又或者两个独立嘚集群之间可能会发生交互关系,这是也会出现客户端与服务端不在同一集群内的情况cluster集群Client就是为集群外部actor与集群内部actor进行沟通的解决方案。

实际上cluster集群Client模式就代表一种依赖于消息发布订阅机制的服务方式:客户端通过消息来请求服务服务端接收请求服务消息并提供相應运算服务。

cluster集群Client就是消息发布方它是在目标集群之外机器上的某个actor。这个机器上的actor如果需要向集群内部actor发送消息可以通过这个机器上嘚cluster集群Client

在《》一文中通过简单集群监听器的样例演示了如何使用Akka搭建一个简单的集群可是这个样例“或许”离我们的实际业务场景太远,你基本不太可能去做这种工作除非伱负责运维、监控相关的工作(但实际上一个合格的程序猿在实现功能的同一时候。也应当考虑监控的问题至少应当接入一些监控系统戓框架)。

本文将介绍一个相对看来更符合我们对于集群使用的业务需求的样例——将client请求的字符串转换为大写(假如client真的没有这个能力嘚话)

本文的Akka配置继续沿用《》一文中所展示的配置。但在正式编码之前我们须要在配置中增加一个新的配置项(("Start transformationBackend");

能够看到我们在client每2秒将發送一个新的消息这个消息以“hello-”开头,后边是一个不断自增的数字当收到处理结果后,client还会将结果打印出来

我们以3个服务端节点(host同样,port分别为2551、2552及随机)、1个client节点(port随机)组成的集群为例我们首先启动第一个种子节点,然后以随意顺序启动其他服务端或者client节点(启动顺序问题在《

》一文中已介绍此处不再赘述),集群成员变化的日志例如以下图:

从上面展示的日志中能够看到集群的3个服务端節点和1个client节点先后增加集群的信息

我们再来看看port为57222的角色为frontend的节点的日志信息。例如以下图:

从frontend的日志看出它已经打印了大写得HELLO-3到HELLO-10十條任务处理结果。那么这些任务各自是由集群中的哪些节点负责处理的我们首先来看看port为2551的backend节点,其处理任务的日志例如以下图:

我们洅来看看port为2552的backend节点其处理任务的日志例如以下图:


能够看到从hello-3到hello-10这8条处理任务被均衡的分配给了3个不同的后端节点处理。

奇怪的是hello-1这条消息竟然没有不论什么显示那是由于前端节点刚開始处理消息时。backends列表里还没有缓存好不论什么backend的ActorRef我们向上查找frontend节点的日志。在相隔非常远的日志中发现了以下的输出:

依据本文的样例大家应当看到使用Akka构建集群,开发者仅仅须要关注消息的发送与接收而无需过多涉及集群的细节。不管前端还是后端节点都能够增加同一个集群并且多个后端节点处理消息也能达到负载均衡的功效。

我要回帖

更多关于 akka cluster java 的文章

 

随机推荐