第三部分：使用Akka集群和分片建立集群

Akka对于企业用户来说最重要的特性之一就是创建集群。对那些很有经验的java开发者来说，Akka打开了一个新世界：开发不再限定于单个虚拟机上，在多个虚拟机的分布式环境中，基于Akka的应用程序的行为和单个虚机上的行为一样。它的工作方式如下：

figure13.png

在图13中，数个虚机共同运行组成了一个Akka集群。它们彼此感知，通过gossip协议互相监控心跳。在图14中展示更详细的细节

figure14.png

在这里，集群内所有节点是由Akka自身来管理的。Akka知道什么时候节点加入或离开集群，并且有一种明确定义的方式使得集群在拓扑结构变化的时候保持系统运行。在这种方式中，开发者和架构师也参与进来，但在实际场景中，更关注于actor如何响应拓扑结构的变化，而不用担心其他的细节。

集群分片 Cluster Sharding

另一个Akka actor有意思的模式就是集群分片，也是Akka自带的开箱即用特性。
集群分片用于集群中跨多个节点的分布式Actor，能够使用逻辑标识和它们进行交互，而不用管它们在集群中的实际物理位置。(因为实际位置可能会随着时间改变）

figure15.png

在图15-左中，假设一个物联网的场景，每个actor展现一个设备的状态。组成一个巨大的集合，以及多个子集。每个设备的状态最好存储在内存中，但在一台物理机上是存储不下的。
在图15-右中，一个矩形框代表一个分片(shard)，对于总体来说，一个shard足够的小

另一方面将所有actor放到一个单机上不是一个好选择，对于系统的弹性和扩展性来说，跨机器运行会更好。这种方式下，如果一个节点丢失了，系统运行期间其他节点就能接续它的工作，当对失去节点做应对时可能会带来短暂的暂停无响应，而不是整个系统崩溃。

此时系统整体还在运行，那个丢失节点上的actor会恢复，而不是整个系统完全的崩溃，变成一个可怕的事故。

figure16.png

如在图16中看到的一样，集群分片能将大的actor集合分成逻辑片区，在物联网的使用例子中，假设设备都是由某个哈希值标识的，这样就可以将每个设备对应到某个分片ID。集群分片使用定义好的分片策略来生成逻辑集合并将这些分片分布到集群中。

figure17.png

当分片分布在整个集群，而一个节点宕机时，事情变得有趣了。当节点宕机时，集群知道哪些分片运行在那个节点上，它可以在其他节点上重建这个宕机节点上的actor

因为集群分片管理着所有的分片和它们的分布，开发者不需要操心。而只需关注actor状态的恢复--这需要根据不同的场景来自定义。例如：如果actor代表着银行账户，actor需要在集群的其他节点上再创建，它的状态(账户金额)需要被恢复。这部分会由Akka Persistence来处理，关于Akka Persistence会在本文后面介绍。

figure18.png

在图18中，我们能看到集群分片是如何通过一个分片协作的actor工作的，分片协作的actor在图的左下角。整个集群有一个分片协作actor，每个节点有一个分片区域actor，分片协作actor和分片区域actor一起工作。
当有消息发送给actor的时候，这让我们可以不必关心actor在哪里。 当请求进来时，前端有一个负载均衡，会在集群内轮询分发消息。 假设有个消息发送给actor 123， 而消息落到了节点2，节点2的分片区域actor会回应说：“我不知道这个actor在哪里，它在哪？”

figure19.png

分片协助actor会回消息给节点2的分片区域actor：”在节点3“，然后节点2的分片区域actor转发消息给节点3的分片区域actor：”这里有一个消息给分片区域3“

现在，节点3的分片区域actor会再走一遍类似的流程，因为它也不知道目的actor在哪。所以它问分片协作actor，"actor 123在哪？"。分片协作actor回应:"在节点3"，然后 分片区域actor才更新这个情况“哦，actor123在自己这个节点”。这样的机制使得开发者只需要写明消息发送给哪个分片区域。

figure20.png

图20中，集群分片处理剩下的工作，每个分片区域存储分区的位置信息，因此就不需要总是问分片协作者某个分片在哪里。一旦告诉过一次某个分片在哪，所有的分片区域都会记住。

所有的复杂的交互都是由以下四个元素处理：分片协作，分片区域，分片和actor。对应集群单例actor， 节点单例actor，和分片后的actor

总结：

Akka集群提供一系列的功能，可以安全，可监管地扩展你的系统。

集群分片适用于不同的场景，在消息跨越各种异步边界的时候，作为一种保证状态维护的方式。

开发者不必操心底层实现和交互，Akka会处理这些。