Akka源码分析-Cluster-Sharding

　　个人觉得akka提供的cluster工具中，sharding是最吸引人的。当我们需要把actor分布在不同的节点上时，Cluster sharding非常有用。我们可以使用actor的逻辑标识符与actor进行通信，而不用关心其物理位置。简单来说就是把actor的actorPath或actorRef进一步抽象，用一个字符串表示。

　　sharding可以表示为DDD领域中的聚合根，此时actor叫做“实体”。这些actor一般都具有持久化的状态。每个实体actor只运行在某个节点，我们可以在不知道actor位置的情况下，给对应的actor发送消息。当然了，这需要通过ShardRegion这个actor来发送，它知道如何路由消息。

　　介绍到这里，你是不是也有自己写一个sharding的冲动呢？不过我劝你不要这样做，虽然基于akka实现这个功能的核心功能很简单，但需要考虑很多场景，比如实体漂移。但还是要大胆想一想的，怎么屏蔽actor的位置呢？当然是创建一个proxy喽，这是akka的很多组件中经常出现的一种技术。proxy保存各个实体的具体位置（ActorRef或者ActorPath），然后通过proxy发送消息。其实sharding比较难的是实体要尽量分散，还要支持重新均衡，而且还要考虑实体actor漂移之后状态重建的功能。

　　在进一步分析源码之前，我有必要啰嗦几句akka中分片的相关概念。

　　首先我们要区分分片和分区的区别。其实我个人理解，分区是对一组数据的划分，即符合某类特征的数据进行聚合作为一个分区；而分片则是将数据分散到节点上的机制，即分片是尽可能的将数据“均匀”的分散到不同节点来达到均衡的目的，当然了还有其他好处。

　　akka分片是针对actor的，不是传统的对数据进行分片，可以理解成对计算的分片。每个actor都有一个实体ID，该ID在集群中唯一。akka需要提供从消息中提取实体ID的方法，和用于接收消息并计算actor所属分片ID的函数。

　　集群中分布的分片所在的区域成为分片区域，这些区域作为分片的proxy，参与分片的每个节点将每种类型的分片actor承载一个单独的分片区域。每个区域可以托管多个分片，分片区域内的所有实体由相同类型的actor表示。每个分片可以托管多个实体，实体根据ID的结果，分布在不同的分片上。分片协调器用于管理分片所在的位置，它是作为一个集群单例实现的。分片区域可以与分片协调器进行通信以定位分片，然后这个位置信息会被缓存。

　　akka的分片还引入了钝化的机制。很显然如果在系统内长时间保持所有的actor是不合理的，而持久性的存在则可以允许我们对actor进行加载和卸载。如果在指定的时间内，actor没有收到消息，则我们可以钝化actor。简单来说就是给实体actor发送特定的消息关闭自己。如果某个消息ID对应的actor不存在，我们还可以重新加载这个actor。

　　好了，下面开始分析源码，上官网demo。

class Counter extends PersistentActor {
  import ShardRegion.Passivate

  context.setReceiveTimeout(120.seconds)

  // self.path.name is the entity identifier (utf-8 URL-encoded)
  override def persistenceId: String = "Counter-" + self.path.name

  var count = 0

  def updateState(event: CounterChanged): Unit =
    count += event.delta

  override def receiveRecover: Receive = {
    case evt: CounterChanged ⇒ updateState(evt)
  }

  override def receiveCommand: Receive = {
    case Increment      ⇒ persist(CounterChanged(+1))(updateState)
    case Decrement      ⇒ persist(CounterChanged(-1))(updateState)
    case Get(_)         ⇒ sender() ! count
    case ReceiveTimeout ⇒ context.parent ! Passivate(stopMessage = Stop)
    case Stop           ⇒ context.stop(self)
  }
}

　　首先Counter是一个需要分散在各个节点的实体actor。很显然这是个PersistentActor。那如何创建一个对Counter的proxyActor呢？在akka中这叫做ShardRegion。

    val counterRegion: ActorRef = ClusterSharding(system).start(
      typeName = "Counter",
      entityProps = Props[Counter],
      settings = ClusterShardingSettings(system),
      extractEntityId = extractEntityId,
      extractShardId = extractShardId)

　　上面代码启动了一个ShardRegion，请注意start方法的最后两个参数。它分别定义了实体ID提取器和分片ID提取器。

    val extractEntityId: ShardRegion.ExtractEntityId = {
      case EntityEnvelope(id, payload) ⇒ (id.toString, payload)
      case msg @ Get(id)               ⇒ (id.toString, msg)
    }

    val numberOfShards = 100

    val extractShardId: ShardRegion.ExtractShardId = {
      case EntityEnvelope(id, _) ⇒ (id % numberOfShards).toString
      case Get(id)               ⇒ (id % numberOfShards).toString
      case ShardRegion.StartEntity(id) ⇒
        // StartEntity is used by remembering entities feature
        (id.toLong % numberOfShards).toString
    }

　　ShardRegion.ExtractEntityId、ShardRegion.ExtractShardId又是什么呢？

  /**
   * Interface of the partial function used by the [[ShardRegion]] to
   * extract the entity id and the message to send to the entity from an
   * incoming message. The implementation is application specific.
   * If the partial function does not match the message will be
   * `unhandled`, i.e. posted as `Unhandled` messages on the event stream.
   * Note that the extracted  message does not have to be the same as the incoming
   * message to support wrapping in message envelope that is unwrapped before
   * sending to the entity actor.
   */
  type ExtractEntityId = PartialFunction[Msg, (EntityId, Msg)]

　　ExtractEntityId是一个片函数，它用来从消息中提取实体ID和消息。如果这个片函数无法处理消息，那么就会把这个未处理的消息发送给event stream。注意，输入的消息和输出的消息不一定是同类型的。

/**
   * Interface of the function used by the [[ShardRegion]] to
   * extract the shard id from an incoming message.
   * Only messages that passed the [[ExtractEntityId]] will be used
   * as input to this function.
   */
  type ExtractShardId = Msg ⇒ ShardId

　　ExtractShardId是用来从消息中提取分片ID的，只有通过ExtractEntityId的消息才会发送给这个函数。其实在发送消息时，首先从消息中获取实体ID，然后通过实体ID计算分片ID的。

　　但有一定需要注意，那就是对于相同的实体ID计算出来的分片ID一定要相同，其实就是要保持一致，否则就会同时在多个地方启动相同的实体actor了。

　　其实一个好的分片算法非常重要。一致性HASH就是同时对消息ID和节点ID进行HASH，把消息路由给最邻近的节点。

　　下面开始分析start。

 /**
   * Scala API: Register a named entity type by defining the [[akka.actor.Props]] of the entity actor
   * and functions to extract entity and shard identifier from messages. The [[ShardRegion]] actor
   * for this type can later be retrieved with the [[shardRegion]] method.
   *
   * This method will start a [[ShardRegion]] in proxy mode in case if there is no match between the roles of
   * the current cluster node and the role specified in [[ClusterShardingSettings]] passed to this method.
   *
   * Some settings can be configured as described in the `akka.cluster.sharding` section
   * of the `reference.conf`.
   *
   * @return the actor ref of the [[ShardRegion]] that is to be responsible for the shard
   */
  def start(
    typeName:           String,
    entityProps:        Props,
    settings:           ClusterShardingSettings,
    extractEntityId:    ShardRegion.ExtractEntityId,
    extractShardId:     ShardRegion.ExtractShardId,
    allocationStrategy: ShardAllocationStrategy,
    handOffStopMessage: Any): ActorRef = {

    internalStart(typeName, _ ⇒ entityProps, settings, extractEntityId, extractShardId, allocationStrategy, handOffStopMessage)
  }

　　start注册了一个命名的实体类型，也就是实体actor的Props，当然还包括从消息中提取实体ID、分片ID的函数。ShardRegion这个actor会被创建，单独负责这个类型（Props定义的类型），当然了还可以通过shardRegion方法查询获取。如果当前节点角色不属于我们定义的节点，则会创建一个ShardRegion的一个代理，即本地不会有分片actor创建，只是简单的把消息转发给其他节点上的ShardRegion。

@InternalApi private[akka] def internalStart(
    typeName:           String,
    entityProps:        String ⇒ Props,
    settings:           ClusterShardingSettings,
    extractEntityId:    ShardRegion.ExtractEntityId,
    extractShardId:     ShardRegion.ExtractShardId,
    allocationStrategy: ShardAllocationStrategy,
    handOffStopMessage: Any): ActorRef = {

    if (settings.shouldHostShard(cluster)) {

      implicit val timeout = system.settings.CreationTimeout
      val startMsg = Start(typeName, entityProps, settings,
        extractEntityId, extractShardId, allocationStrategy, handOffStopMessage)
      val Started(shardRegion) = Await.result(guardian ? startMsg, timeout.duration)
      regions.put(typeName, shardRegion)
      shardRegion
    } else {
      log.debug("Starting Shard Region Proxy [{}] (no actors will be hosted on this node)...", typeName)

      startProxy(
        typeName,
        settings.role,
        dataCenter = None, // startProxy method must be used directly to start a proxy for another DC
        extractEntityId,
        extractShardId)
    }
  }

　　通过源码跟踪，我们找到了internalStart，这个函数只有一个if-else代码块，很显然我们刚开始需要创建ShardRegion，应该会走if代码块，也就是用ask模式给guardian发送Start消息，返回一个ActorRef，其实应该就是ShardRegion的actor的实例。并把这个ActorRef添加到了regions变量中。

 private lazy val guardian: ActorRef = {
    val guardianName: String =
      system.settings.config.getString("akka.cluster.sharding.guardian-name")
    val dispatcher = system.settings.config
      .getString("akka.cluster.sharding.use-dispatcher") match {
        case "" ⇒ Dispatchers.DefaultDispatcherId
        case id ⇒ id
      }
    system.systemActorOf(Props[ClusterShardingGuardian].withDispatcher(dispatcher), guardianName)
  }

　　guardian是一个ClusterShardingGuardian实例，它如何处理Start消息呢？

　　这个actor只处理两个类型的消息：Start和StartProxy。其实吧，这个就是对ShardRegion的一个监督者，这种用法之前分析过，也特意提出来了，读者自行理解吧。不过这里又叫Guardian，而不叫supervisor了，命名不统一啊，估计是多个开发者导致的。

val rep = replicator(settings)
        val encName = URLEncoder.encode(typeName, ByteString.UTF_8)
        val cName = coordinatorSingletonManagerName(encName)
        val cPath = coordinatorPath(encName)
        val shardRegion = context.child(encName).getOrElse {
          if (context.child(cName).isEmpty) {
            val coordinatorProps =
              if (settings.stateStoreMode == ClusterShardingSettings.StateStoreModePersistence)
                ShardCoordinator.props(typeName, settings, allocationStrategy)
              else
                ShardCoordinator.props(typeName, settings, allocationStrategy, rep, majorityMinCap)
            val singletonProps = BackoffSupervisor.props(
              childProps = coordinatorProps,
              childName = "coordinator",
              minBackoff = coordinatorFailureBackoff,
              maxBackoff = coordinatorFailureBackoff * 5,
              randomFactor = 0.2)
              .withDeploy(Deploy.local)
            val singletonSettings = settings.coordinatorSingletonSettings
              .withSingletonName("singleton")
              .withRole(role)
            context.actorOf(
              ClusterSingletonManager.props(singletonProps, terminationMessage = PoisonPill, singletonSettings)
                .withDispatcher(context.props.dispatcher),
              name = cName)
          }

          context.actorOf(
            ShardRegion.props(
              typeName = typeName,
              entityProps = entityProps,
              settings = settings,
              coordinatorPath = cPath,
              extractEntityId = extractEntityId,
              extractShardId = extractShardId,
              handOffStopMessage = handOffStopMessage,
              replicator = rep,
              majorityMinCap
            )
              .withDispatcher(context.props.dispatcher),
            name = encName
          )
        }
        sender() ! Started(shardRegion)

　　对Start消息的处理非常关键，所以这里把整个源码都贴出来了。很显然这里创建了三种actor：replicator、coordinator、shardRegion。replicator先略过，coordinator只需要记住它是通过ClusterSingletonManager创建的集群单例actor就行了。

　　StartProxy消息的处理不再分析，跟Start不同的是，它不会创建replicator、coordinator这些实例，只是简单的创建ShardRegion的代理actor。

/**
 * INTERNAL API
 *
 * This actor creates children entity actors on demand for the shards that it is told to be
 * responsible for. It delegates messages targeted to other shards to the responsible
 * `ShardRegion` actor on other nodes.
 *
 * @see [[ClusterSharding$ ClusterSharding extension]]
 */
private[akka] class ShardRegion(
  typeName:           String,
  entityProps:        Option[String ⇒ Props],
  dataCenter:         Option[DataCenter],
  settings:           ClusterShardingSettings,
  coordinatorPath:    String,
  extractEntityId:    ShardRegion.ExtractEntityId,
  extractShardId:     ShardRegion.ExtractShardId,
  handOffStopMessage: Any,
  replicator:         ActorRef,
  majorityMinCap:     Int) extends Actor with ActorLogging

　　ShardRegion根据需要为分片创建对应的实体actor，并可以把消息路由给其他分片内的实体。既然消息都是发送给ShardRegion这个actor的，那么这个actor的receive定义就比较重要了。

 def receive: Receive = {
    case Terminated(ref)                         ⇒ receiveTerminated(ref)
    case ShardInitialized(shardId)               ⇒ initializeShard(shardId, sender())
    case evt: ClusterDomainEvent                 ⇒ receiveClusterEvent(evt)
    case state: CurrentClusterState              ⇒ receiveClusterState(state)
    case msg: CoordinatorMessage                 ⇒ receiveCoordinatorMessage(msg)
    case cmd: ShardRegionCommand                 ⇒ receiveCommand(cmd)
    case query: ShardRegionQuery                 ⇒ receiveQuery(query)
    case msg: RestartShard                       ⇒ deliverMessage(msg, sender())
    case msg: StartEntity                        ⇒ deliverStartEntity(msg, sender())
    case msg if extractEntityId.isDefinedAt(msg) ⇒ deliverMessage(msg, sender())
    case unknownMsg                              ⇒ log.warning("Message does not have an extractor defined in shard [{}] so it was ignored: {}", typeName, unknownMsg)
  }

　　很显然，收到本分片能够处理的消息时，会去调用deliverMessage这个方法。

def deliverMessage(msg: Any, snd: ActorRef): Unit =
    msg match {
      case RestartShard(shardId) ⇒
        regionByShard.get(shardId) match {
          case Some(ref) ⇒
            if (ref == self)
              getShard(shardId)
          case None ⇒
            if (!shardBuffers.contains(shardId)) {
              log.debug("Request shard [{}] home. Coordinator [{}]", shardId, coordinator)
              coordinator.foreach(_ ! GetShardHome(shardId))
            }
            val buf = shardBuffers.getOrEmpty(shardId)
            log.debug("Buffer message for shard [{}]. Total [{}] buffered messages.", shardId, buf.size + 1)
            shardBuffers.append(shardId, msg, snd)
        }

      case _ ⇒
        val shardId = extractShardId(msg)
        regionByShard.get(shardId) match {
          case Some(ref) if ref == self ⇒
            getShard(shardId) match {
              case Some(shard) ⇒
                if (shardBuffers.contains(shardId)) {
                  // Since now messages to a shard is buffered then those messages must be in right order
                  bufferMessage(shardId, msg, snd)
                  deliverBufferedMessages(shardId, shard)
                } else shard.tell(msg, snd)
              case None ⇒ bufferMessage(shardId, msg, snd)
            }
          case Some(ref) ⇒
            log.debug("Forwarding request for shard [{}] to [{}]", shardId, ref)
            ref.tell(msg, snd)
          case None if shardId == null || shardId == "" ⇒
            log.warning("Shard must not be empty, dropping message [{}]", msg.getClass.getName)
            context.system.deadLetters ! msg
          case None ⇒
            if (!shardBuffers.contains(shardId)) {
              log.debug("Request shard [{}] home. Coordinator [{}]", shardId, coordinator)
              coordinator.foreach(_ ! GetShardHome(shardId))
            }
            bufferMessage(shardId, msg, snd)
        }
    }

　　很显然，普通消息会走最后一个case代码块。它首先根据extractShardId解析出消息所属分片的ID。然后根据shardId从本地的regionByShard中查找对应的实体，如果找到且属于本地，就把消息转发给它。如果是远程的或不属于当前ShardRegion则会把消息转发给对应的Shard。如果当前ShardRegion没有找到对应的Shard，则会给coordinator发送GetShardHome消息来获取对应的Shard的ActorRef信息，不过这种情况我们先不分析。

　　regionByShard是用来做什么的呢？其实这是一个索引，它保存分片ID到分区区域的映射，因为分片区域负责管理分片。分片区域（ShardRegion）可以在本地也可以在远程或其他JVM。我们假设法消息给本地的分片区域，很显然刚开始时regionByShard是空的，而且shardBuffers也是空的，所以会给协调器发送GetShardHome消息，并调用bufferMessage消息。bufferMessage简单来说就是把shardId保存到shardBuffers并把消息做一个临时缓存。在Region创建之后再把消息发送过去。

　　ShardCoordinator分为PersistentShardCoordinator、DDataShardCoordinator，来看看他们是如何处理GetShardHome消息的。

case GetShardHome(shard) ⇒
      if (!handleGetShardHome(shard)) {
        // location not know, yet
        val activeRegions = state.regions -- gracefulShutdownInProgress
        if (activeRegions.nonEmpty) {
          val getShardHomeSender = sender()
          val regionFuture = allocationStrategy.allocateShard(getShardHomeSender, shard, activeRegions)
          regionFuture.value match {
            case Some(Success(region)) ⇒
              continueGetShardHome(shard, region, getShardHomeSender)
            case _ ⇒
              // continue when future is completed
              regionFuture.map { region ⇒
                AllocateShardResult(shard, Some(region), getShardHomeSender)
              }.recover {
                case _ ⇒ AllocateShardResult(shard, None, getShardHomeSender)
              }.pipeTo(self)
          }
        }
      }

　　上面的代码表明，在ShardRegion给ShardCoordinator发送GetShardHome之前，ShardCoordinator就已经知道了Region的信息，那么什么时候知道的呢？我们似乎漏掉了什么。我们发现ShardRegion在收到集群的消息时（ClusterDomainEvent、CurrentClusterState）最终都会触发changeMembers方法，我们知道集群消息是在actor启动的时候就会收到的。

def changeMembers(newMembers: immutable.SortedSet[Member]): Unit = {
    val before = membersByAge.headOption
    val after = newMembers.headOption
    membersByAge = newMembers
    if (before != after) {
      if (log.isDebugEnabled)
        log.debug("Coordinator moved from [{}] to [{}]", before.map(_.address).getOrElse(""), after.map(_.address).getOrElse(""))
      coordinator = None
      register()
    }
  }　　

　　changeMembers中会调用register方法。

def register(): Unit = {
    coordinatorSelection.foreach(_ ! registrationMessage)
    if (shardBuffers.nonEmpty && retryCount >= 5) coordinatorSelection match {
      case Some(actorSelection) ⇒
        val coordinatorMessage =
          if (cluster.state.unreachable(membersByAge.head)) s"Coordinator [${membersByAge.head}] is unreachable."
          else s"Coordinator [${membersByAge.head}] is reachable."
        log.warning(
          "Trying to register to coordinator at [{}], but no acknowledgement. Total [{}] buffered messages. [{}]",
          actorSelection, shardBuffers.totalSize, coordinatorMessage
        )
      case None ⇒ log.warning(
        "No coordinator found to register. Probably, no seed-nodes configured and manual cluster join not performed? Total [{}] buffered messages.",
        shardBuffers.totalSize)
    }
  }

　　register其实就是给coordinatorSelection发送registrationMessage消息。

  def registrationMessage: Any =
    if (entityProps.isDefined) Register(self) else RegisterProxy(self)

　　registrationMessage只是区分了Register还是RegisterProxy，其实就是区分是注册Region还是RegionProxy。

case Register(region) ⇒
      if (isMember(region)) {
        log.debug("ShardRegion registered: [{}]", region)
        aliveRegions += region
        if (state.regions.contains(region)) {
          region ! RegisterAck(self)
          allocateShardHomesForRememberEntities()
        } else {
          gracefulShutdownInProgress -= region
          update(ShardRegionRegistered(region)) { evt ⇒
            state = state.updated(evt)
            context.watch(region)
            region ! RegisterAck(self)
            allocateShardHomesForRememberEntities()
          }
        }
      } else {
        log.debug("ShardRegion {} was not registered since the coordinator currently does not know about a node of that region", region)
      }

　　上面是ShardCoordinator收到Register时的处理逻辑，其实就是保存了region的相关信息，并发送了RegisterAck消息。但请注意allocateShardHomesForRememberEntities，这个机制后面会再深入分析，因为它影响了分片的性能。

 case RegisterAck(coord) ⇒
      context.watch(coord)
      coordinator = Some(coord)
      requestShardBufferHomes()

　　ShardRegion收到RegisterAck消息如何处理的呢，其实就是保存了coord的ActorRef，并把缓存的消息发出去了。

　　我们回到GetShardHome处理的代码块，其实它最终调用了allocationStrategy.allocateShard(getShardHomeSender, shard, activeRegions)创建了Shard。

/**
     * Invoked when the location of a new shard is to be decided.
     * @param requester actor reference to the [[ShardRegion]] that requested the location of the
     *                  shard, can be returned if preference should be given to the node where the shard was first accessed
     * @param shardId the id of the shard to allocate
     * @param currentShardAllocations all actor refs to `ShardRegion` and their current allocated shards,
     *                                in the order they were allocated
     * @return a `Future` of the actor ref of the [[ShardRegion]] that is to be responsible for the shard, must be one of
     *         the references included in the `currentShardAllocations` parameter
     */
    def allocateShard(requester: ActorRef, shardId: ShardId,
                      currentShardAllocations: Map[ActorRef, immutable.IndexedSeq[ShardId]]): Future[ActorRef]

　　allocateShard是ShardAllocationStrategy这个trait的一个方法。通过上下文，我们知道ShardAllocationStrategy是LeastShardAllocationStrategy的一个实例。

 /**
   * The default implementation of [[ShardCoordinator.LeastShardAllocationStrategy]]
   * allocates new shards to the `ShardRegion` with least number of previously allocated shards.
   * It picks shards for rebalancing handoff from the `ShardRegion` with most number of previously allocated shards.
   * They will then be allocated to the `ShardRegion` with least number of previously allocated shards,
   * i.e. new members in the cluster. There is a configurable threshold of how large the difference
   * must be to begin the rebalancing. The number of ongoing rebalancing processes can be limited.
   */
  @SerialVersionUID(1L)
  class LeastShardAllocationStrategy(rebalanceThreshold: Int, maxSimultaneousRebalance: Int)
    extends ShardAllocationStrategy with Serializable

override def allocateShard(requester: ActorRef, shardId: ShardId,
                               currentShardAllocations: Map[ActorRef, immutable.IndexedSeq[ShardId]]): Future[ActorRef] = {
      val (regionWithLeastShards, _) = currentShardAllocations.minBy { case (_, v) ⇒ v.size }
      Future.successful(regionWithLeastShards)
    }

　　LeastShardAllocationStrategy是如何实现allocateShard的呢？其实就是从currentShardAllocations选择保持shard最少的actorRef，那么currentShardAllocations传入的时候值是什么呢？其实就是当前活跃的ShardRegion。很显然我们目前只有一个ShardRegion，根据源码来分析，GetShardHome消息的代码块中会调用continueGetShardHome

def continueGetShardHome(shard: ShardId, region: ActorRef, getShardHomeSender: ActorRef): Unit =
    if (rebalanceInProgress.contains(shard)) {
      deferGetShardHomeRequest(shard, getShardHomeSender)
    } else {
      state.shards.get(shard) match {
        case Some(ref) ⇒ getShardHomeSender ! ShardHome(shard, ref)
        case None ⇒
          if (state.regions.contains(region) && !gracefulShutdownInProgress.contains(region)) {
            update(ShardHomeAllocated(shard, region)) { evt ⇒
              state = state.updated(evt)
              log.debug("Shard [{}] allocated at [{}]", evt.shard, evt.region)

              sendHostShardMsg(evt.shard, evt.region)
              getShardHomeSender ! ShardHome(evt.shard, evt.region)
            }
          } else
            log.debug(
              "Allocated region {} for shard [{}] is not (any longer) one of the registered regions: {}",
              region, shard, state)
      }
    }

　　continueGetShardHome其实就是从state.shards中获取region的实例，如果找到则返回，如果没有找到则创建ShardHomeAllocated消息，然后调用sendHostShardMsg

def sendHostShardMsg(shard: ShardId, region: ActorRef): Unit = {
    region ! HostShard(shard)
    val cancel = context.system.scheduler.scheduleOnce(shardStartTimeout, self, ResendShardHost(shard, region))
    unAckedHostShards = unAckedHostShards.updated(shard, cancel)
  }

　　sendHostShardMsg就是给ShardRegion发送HostShard消息。后续功能不再分析。

　　那么读者会问了，为啥ShardRegion还需要通过shardId去问协调器ShardRegion的位置呢？你猜啊。哈哈，因为发给本地ShardRegion的消息，并不一定属于它啊，有可能是其他节点的ShardRegion呢？为啥对于同一个shardId可能存在多个节点上呢？你再猜，哈哈。想想本来就该这样啊，我们之定义了实体ID、分片ID，并没有定义分片区域ID啊，也就是说，分片可以属于任意一个分片区域，而分片区域可以跨节点分布。所以这也就是默认的LeastShardAllocationStrategy中allocateShard的意义：从所有节点上找出管理分片最少的分片区域。也就是说，一个消息发送给哪个分片、再有该分片发送给哪个实体是确定的，但是这个分片在哪个节点就不固定了。这也就是所谓的分片漂移，某个分片到达指定阈值，可能会迁移到其他的分片区域内，当迁移时，本地分片内的实体actor都会被stop掉，等分片迁移成功后，收到某个实体第一个消息时重新创建实体actor。

　　至此，akka的分片机制分析完毕，当然还有很多细节没有分析。但简单来说就是，一个消息先发送给本地的ShardRegion实例，本地实例会计算消息的sharId，通过这个ID找出对应的Shard（因为Shard可能不在本节点或漂移到了其他节点），当然这是通过协调器找到的。找到shardId对应的Shard之后，就会把消息发送给Shard。

　　不过我们好像忘了分析Shard了，好尴尬，哈哈。那么就看看。

def receiveCommand: Receive = {
    case Terminated(ref)                         ⇒ receiveTerminated(ref)
    case msg: CoordinatorMessage                 ⇒ receiveCoordinatorMessage(msg)
    case msg: ShardCommand                       ⇒ receiveShardCommand(msg)
    case msg: ShardRegion.StartEntity            ⇒ receiveStartEntity(msg)
    case msg: ShardRegion.StartEntityAck         ⇒ receiveStartEntityAck(msg)
    case msg: ShardRegionCommand                 ⇒ receiveShardRegionCommand(msg)
    case msg: ShardQuery                         ⇒ receiveShardQuery(msg)
    case msg if extractEntityId.isDefinedAt(msg) ⇒ deliverMessage(msg, sender())
  }

　　很显然，它收到消息之后，还是调用deliverMessage。

def deliverMessage(msg: Any, snd: ActorRef): Unit = {
    val (id, payload) = extractEntityId(msg)
    if (id == null || id == "") {
      log.warning("Id must not be empty, dropping message [{}]", msg.getClass.getName)
      context.system.deadLetters ! msg
    } else if (payload.isInstanceOf[ShardRegion.StartEntity]) {
      // in case it was wrapped, used in Typed
      receiveStartEntity(payload.asInstanceOf[ShardRegion.StartEntity])
    } else {
      messageBuffers.contains(id) match {
        case false ⇒ deliverTo(id, msg, payload, snd)

        case true if messageBuffers.totalSize >= bufferSize ⇒
          log.debug("Buffer is full, dropping message for entity [{}]", id)
          context.system.deadLetters ! msg

        case true ⇒
          log.debug("Message for entity [{}] buffered", id)
          messageBuffers.append(id, msg, snd)
      }
    }
  }

　　deliverMessage源码看似很多，但重点就在最后一个else代码块。messageBuffers刚开始是没有这个实体ID的，所以会调用deliverTo。

def deliverTo(id: EntityId, msg: Any, payload: Msg, snd: ActorRef): Unit = {
    val name = URLEncoder.encode(id, "utf-8")
    context.child(name) match {
      case Some(actor) ⇒ actor.tell(payload, snd)
      case None        ⇒ getEntity(id).tell(payload, snd)
    }
  }

　　deliverTo会在当前的分片中查找对应的实体actor，如果找到就把消息发送给它，如果没找到就通过getEntity创建之后在发送给他。

def getEntity(id: EntityId): ActorRef = {
    val name = URLEncoder.encode(id, "utf-8")
    context.child(name).getOrElse {
      log.debug("Starting entity [{}] in shard [{}]", id, shardId)

      val a = context.watch(context.actorOf(entityProps(id), name))
      idByRef = idByRef.updated(a, id)
      refById = refById.updated(id, a)
      state = state.copy(state.entities + id)
      a
    }
  }

　　getEntity比较简单，就是通过name查找子actor，如果没找到就用entityProps创建对应的actor，然后就是更新相关的状态。

　　本文介绍了分片的基本机制，但分片的功能远比这个要复杂一点，我们后面会再进一步的分析和研读源码。

Cluster Sharding