个人觉得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，然后就是更新相关的状态。
本文介绍了分片的基本机制，但分片的功能远比这个要复杂一点，我们后面会再进一步的分析和研读源码。