Akka源码分析-Cluster-Distributed Publish Subscribe in Cluster

　　在ClusterClient源码分析中，我们知道，他是依托于“Distributed Publish Subscribe in Cluster”来实现消息的转发的，那本文就来分析一下Pub/Sub是如何实现的。

　　还记得之前分析Cluster源码的文章吗？其实Cluster只是把集群内各个节点的信息通过gossip协议公布出来，并把节点的信息分发出来。但各个actor的地址还是需要开发者自行获取或设计的，比如我要跟worker通信，那就需要知道这个actor在哪个节点，通过actorPath或actorRef通信。

　　“Distributed Publish Subscribe”就是用来屏蔽Actor位置的一个组件，通过它你可以给actor发消息而不需要知道actor的网咯位置。其实就是提供了一个类似kafka的消息发布、订阅的机制，其实吧，如果这个功能让你实现，你准备怎么做？肯定是在集群层面提供一个proxy，来屏蔽目标actor的网络位置啊。简单来说，就是提供一个通用的actor，来对消息进行转发，发送者只需要提供目标actor的路径就好了（比如/user/serviceA）。不过还是那句话，akka的都是对的，akka的都是好的。akka帮你实现这个事儿，就不用你自己考虑通用、稳定的问题啦。

　　消息订阅发布模式提供了一个中继actor：akka.cluster.pubsub.DistributedPubSubMediator。它管理actor的注册引用、分发实例引用给端actor，而且必须在所有的节点或一组节点内启动。它可以通过DistributedPubSub扩展启动，也可以像普通actor那样启动。

　　服务actor的注册是最终一致的，也就是说服务信息在变化时并不能立即通知给其他节点，过一段时间参会分发给所有节点。当然了每次都是以增量的信息分发这些信息。

　　消息的发送有两种模式：Send和Publish。简单来说就是点对点、广播。

　　Publish模式下，只有注册到命名的topic的actor才会收到消息，topic是啥？。其实这才是真正的订阅、发布模式。

    class Subscriber extends Actor with ActorLogging {
      import DistributedPubSubMediator.{ Subscribe, SubscribeAck }
      val mediator = DistributedPubSub(context.system).mediator
      // subscribe to the topic named "content"
      mediator ! Subscribe("content", self)

      def receive = {
        case s: String ⇒
          log.info("Got {}", s)
        case SubscribeAck(Subscribe("content", None, `self`)) ⇒
          log.info("subscribing")
      }
    }

    class Publisher extends Actor {
      import DistributedPubSubMediator.Publish
      // activate the extension
      val mediator = DistributedPubSub(context.system).mediator

      def receive = {
        case in: String ⇒
          val out = in.toUpperCase
          mediator ! Publish("content", out)
      }
    }

　　上面是官方的demo，可以看出，订阅者actor订阅了名为“content”的topic，在发布者actor发送指定topic的消息时，会自动收到对应的消息。怎么样，是不是很简单。其实吧，mediator只需要维护一个topic到订阅者的映射列表就好了，当收到对应topic的消息时，取出对应的订阅者（也就是ActorRef或actorSelection）把消息转发给他就好了。

　　Send模式就是一个点对点模式，每个消息被发送给一个目标，而不用知道这个目标actors的位置。既然之前我们说了，这是通过ActorPath发送的，那如果集群中同时有多个节点命中了这个ActorPath怎么办呢？那就路由呗，提供一个RoutingLogic 路由策略。默认策略是随机发送，当然了我们是可以修改这个策略的。与Publish模式不同，这里注册服务actor是通过Put消息实现的。不过实现原理都差不多，反正都要维护列表。

    class Destination extends Actor with ActorLogging {
      import DistributedPubSubMediator.Put
      val mediator = DistributedPubSub(context.system).mediator
      // register to the path
      mediator ! Put(self)

      def receive = {
        case s: String ⇒
          log.info("Got {}", s)
      }
    }

    class Sender extends Actor {
      import DistributedPubSubMediator.Send
      // activate the extension
      val mediator = DistributedPubSub(context.system).mediator

      def receive = {
        case in: String ⇒
          val out = in.toUpperCase
          mediator ! Send(path = "/user/destination", msg = out, localAffinity = true)
      }
    }

　　当然了，我们还是可以通过SendToAll把消息发送给所有命中指定path的actor的。

　　这里需要注意的是，官方的订阅发布组件只能保证至少一次投递，想想都是这样的，哈哈。废话不多说了，上代码。

object DistributedPubSub extends ExtensionId[DistributedPubSub] with ExtensionIdProvider {
  override def get(system: ActorSystem): DistributedPubSub = super.get(system)

  override def lookup = DistributedPubSub

  override def createExtension(system: ExtendedActorSystem): DistributedPubSub =
    new DistributedPubSub(system)
}

　　很显然DistributedPubSub这个扩展也是可以通过配置直接实例化的，不需要我们自行写代码实例化。由于其源码非常简单就是定义并创建了mediator这个actor（DistributedPubSubMediator），下面直接转到DistributedPubSubMediator源码的分析。

/**
 * This actor manages a registry of actor references and replicates
 * the entries to peer actors among all cluster nodes or a group of nodes
 * tagged with a specific role.
 *
 * The `DistributedPubSubMediator` actor is supposed to be started on all nodes,
 * or all nodes with specified role, in the cluster. The mediator can be
 * started with the [[DistributedPubSub]] extension or as an ordinary actor.
 *
 * Changes are only performed in the own part of the registry and those changes
 * are versioned. Deltas are disseminated in a scalable way to other nodes with
 * a gossip protocol. The registry is eventually consistent, i.e. changes are not
 * immediately visible at other nodes, but typically they will be fully replicated
 * to all other nodes after a few seconds.
 *
 * You can send messages via the mediator on any node to registered actors on
 * any other node. There is three modes of message delivery.
 *
 * You register actors to the local mediator with [[DistributedPubSubMediator.Put]] or
 * [[DistributedPubSubMediator.Subscribe]]. `Put` is used together with `Send` and
 * `SendToAll` message delivery modes. The `ActorRef` in `Put` must belong to the same
 * local actor system as the mediator. `Subscribe` is used together with `Publish`.
 * Actors are automatically removed from the registry when they are terminated, or you
 * can explicitly remove entries with [[DistributedPubSubMediator.Remove]] or
 * [[DistributedPubSubMediator.Unsubscribe]].
 *
 * Successful `Subscribe` and `Unsubscribe` is acknowledged with
 * [[DistributedPubSubMediator.SubscribeAck]] and [[DistributedPubSubMediator.UnsubscribeAck]]
 * replies.
 *
 * Not intended for subclassing by user code.
 */
@DoNotInherit
class DistributedPubSubMediator(settings: DistributedPubSubSettings) extends Actor with ActorLogging with PerGroupingBuffer

　　PerGroupingBuffer这个trait不再分析源码，从代码和命名来看，就是给每个group提供一个消息缓存的列表。其实这个actor最重要的功能是要能够感知集群节点的变化和对应服务actor的变化，并及时的把这些信息分发给其他DistributedPubSubMediator，还有就是能够把消息路由给指定的订阅者。为了简化分析，我们忽略第一个功能点，只分析是如何路由消息的。分析这点需要关注几个消息的处理逻辑：Put、Subscribe、Publish、Send、SendToAll。

　　先来看Subscribe 。

    case msg @ Subscribe(topic, _, _) ⇒
      // each topic is managed by a child actor with the same name as the topic

      val encTopic = encName(topic)

      bufferOr(mkKey(self.path / encTopic), msg, sender()) {
        context.child(encTopic) match {
          case Some(t) ⇒ t forward msg
          case None    ⇒ newTopicActor(encTopic) forward msg
        }
      }

　　Subscribe消息表明某个actor需要订阅某个topic的消息，简单来说就是先判断是否需要缓存，不需要的话就执行{}代码块。很显然，刚开始的时候是不需要缓存的。上面的逻辑就是从当前的children中查找encTopic的一个actor，然后把消息转发给它；不存在则创建之后再转发给它。那猜一下这个子actor的功能？其实吧，它应该是一个actor负责维护某个topic与所有订阅者的关系，所有发给这个topic的消息都会转发给所有的订阅者。

def newTopicActor(encTopic: String): ActorRef = {
    val t = context.actorOf(Props(classOf[Topic], removedTimeToLive, routingLogic), name = encTopic)
    registerTopic(t)
    t
  }

　　很显然newTopicActor创建了Topic这个actor，名字就是topic的值，并传入了两个参数：removedTimeToLive、routingLogic。第二个是路由策略。

def registerTopic(ref: ActorRef): Unit = {
    put(mkKey(ref), Some(ref))
    context.watch(ref)
  }

　　put这个函数的功能我们先略过，其功能大概是把这个actor注册到系统内，把它与当前地址、版本号做关联并保存，在适当的时机分发出去。

　　Topic这个actor只有两个方法，所以还需要去看下TopicLike的代码。

　　可以看到TopicLike中有一个subscribers列表，这也是预期之中的。这个actor的消息会被business和defaultReceive处理，business在Topic中重新实现了，且会优先处理。

case msg @ Subscribe(_, Some(group), _) ⇒
          val encGroup = encName(group)
          bufferOr(mkKey(self.path / encGroup), msg, sender()) {
            context.child(encGroup) match {
              case Some(g) ⇒ g forward msg
              case None    ⇒ newGroupActor(encGroup) forward msg
            }
          }
          pruneDeadline = None

　　收到Subscribe消息后，做了跟DistributedPubSubMediator类似的逻辑，又创建了一个子actor（Group），并把消息转发给了它。其实这一点在官方也有说过，也就是说，topic也是可以分组的，一个消息并不一定会发给所有订阅者，可以发给一组订阅者，其实吧，这一点我不太喜欢，感觉功能有点过了，如果要对topic划分子topic，用户自定义实现好了啊，搞得现在源码这么复杂。

class Group(val emptyTimeToLive: FiniteDuration, routingLogic: RoutingLogic) extends TopicLike {
      def business = {
        case SendToOneSubscriber(msg) ⇒
          if (subscribers.nonEmpty)
            Router(routingLogic, (subscribers map ActorRefRoutee).toVector).route(wrapIfNeeded(msg), sender())
      }
    }

　　Group的代码还这么简单，它又把Subscribe发给了TopicLike的defaultReceive

def defaultReceive: Receive = {
        case msg @ Subscribe(_, _, ref) ⇒
          context watch ref
          subscribers += ref
          pruneDeadline = None
          context.parent ! Subscribed(SubscribeAck(msg), sender())

　　上面是defaultReceive对Subscribe消息的处理，就是watch，然后把订阅者添加到subscribers列表中，再告诉父actor（就是Topic这个actor）订阅成功了。

　　聪明的读者可能会问了，为啥topic还需要弄个消息缓存呢？其实吧，如果是我实现，肯定不搞这么麻烦啊。消息丢了就丢了啊，没有订阅者的时候，消息缓存起来等有订阅者的时候再发送出去？哈哈，有点浪费内存啊。不过为了稳定性、功能性、完善性，akka还是做了很多额外努力的。不过吧，建议还是把这个队列的大小调小一点，要不然太浪费内存了。不过很不幸的告诉你，目前没有这个开关。

　　既然订阅topic的逻辑跟我们的猜测差不多，那么发布消息的逻辑就应该也符合我们的猜测喽。其实就是获取某个topic对应的订阅者，然后foreach把消息发出去。

case Publish(topic, msg, sendOneMessageToEachGroup) ⇒
      if (sendOneMessageToEachGroup)
        publishToEachGroup(mkKey(self.path / encName(topic)), msg)
      else
        publish(mkKey(self.path / encName(topic)), msg)

　　简单起见，我们只分析消息不分组的情况

def publish(path: String, msg: Any, allButSelf: Boolean = false): Unit = {
    val refs = for {
      (address, bucket) ← registry
      if !(allButSelf && address == selfAddress) // if we should skip sender() node and current address == self address => skip
      valueHolder ← bucket.content.get(path)
      ref ← valueHolder.ref
    } yield ref
    if (refs.isEmpty) ignoreOrSendToDeadLetters(msg)
    else refs.foreach(_.forward(msg))
  }

　　还记得registry什么时候赋值的嘛？如果忘了，可以翻翻registerTopic的代码，因为我没有分析，哈哈。不过不重要了，其实就是获取当前的Topic的Group的ActorRef，然后把消息转发给它。

        case msg ⇒
          subscribers foreach { _ forward msg }

　　Group继承的TopicLike中的defaultReceive方法处理了消息，其实就是把消息转发给所有的subscribers。

　　pub/sub的逻辑就分析到这里了，其实这里面的逻辑还是有点复杂的，当然了有一部分是因为topic分组带来的，其他的都是gossip协议分发订阅者、发布者的相关信息带来的。

　　下面分析Send模式。从Put消息的处理入手。

case Put(ref: ActorRef) ⇒
      if (ref.path.address.hasGlobalScope)
        log.warning("Registered actor must be local: [{}]", ref)
      else {
        put(mkKey(ref), Some(ref))
        context.watch(ref)
      }

　　这就有点简单了，就是把ref注册一下，然后watch。这个ref的key是ActorRef值，其实就是ActorPath.toString

    case Send(path, msg, localAffinity) ⇒
      val routees = registry(selfAddress).content.get(path) match {
        case Some(valueHolder) if localAffinity ⇒
          (for {
            routee ← valueHolder.routee
          } yield routee).toVector
        case _ ⇒
          (for {
            (_, bucket) ← registry
            valueHolder ← bucket.content.get(path)
            routee ← valueHolder.routee
          } yield routee).toVector
      }

      if (routees.isEmpty) ignoreOrSendToDeadLetters(msg)
      else Router(routingLogic, routees).route(wrapIfNeeded(msg), sender())

　　其实就是从registry中优先找当前节点的订阅者，然后通过Router和指定的策略把消息发送出去，这个比pub/sub模式稍微简单点。wrapIfNeeded的功能不再分析，其实就是为了防止与用户本身的路由消息发生冲突。

　　关于节点信息同步，感兴趣的读者可以自行阅读源码，不过我看下来还是有几个问题的。比如当前注册信息的版本是通过时间戳来标志的，如果节点间时间不同步，会发生意外的结果啊；另外所谓的gossip协议，其实就是随机把注册信息发送给其他节点，也就是说集群内的节点都会把消息按照心跳时间，把注册信息随机发送给本身节点以外的节点，达到最终注册信息的同步。如果是我来实现，直接就是粗暴的广播注册信息，哈哈，不过这在集群规模比较大的时候比较耗时，啊哈哈。

Distributed Publish Subscribe in Cluster