深入探索Akka集群：从基础到实践

### 深入探索 Akka 集群：从基础到实践 #### 1. 系统架构与前期考量 在系统开发中，Akka 能将部署决策更多地作为配置项而非代码处理。拥有多个代码库可极大地便利大型团队在代码库上的协作，它通过消除通信渠道和将代码提交隔离到单独的仓库，避免了布鲁克斯法则（给已经延迟的项目增加更多资源会使项目更延迟）带来的问题。 在构建系统时，建议在系统复杂到难以作为单体应用管理之前，或者至少在有基于数据的充分理由（与性能或团队工作相关）时，再考虑构建分布式系统。无论一开始决定构建单体应用还是服务，都应从第一天起将不同的关注点封装到库中，这样在准备实际部署单独的应用程序之前，团队就能从处理不同代码库中受益，后续拆分应用时也能更轻松地管理代码共享。 #### 2. 集群的定义与关键职责 集群是一组相互通信的服务器，集群中的每个服务器被称为节点或成员。集群应能动态改变规模，并在发生故障时将影响降至最低，因此集群需要处理两项关键职责：故障检测和在整个集群中传播所有可用成员的一致视图。 #### 3. 故障检测机制 随着节点数量的增加，节点故障或网络临时分区的可能性也会增大。集群是一个动态实体，当服务器关闭或不可用时会缩小，当添加服务器（例如处理更多负载）时会扩大。节点通过向其他成员发送消息来确定这些成员是否可用，根据回复或无回复来判断成员的可用性。 为了降低监控其他节点健康状况的复杂性，Akka 中的故障检测仅监控节点旁边的一定数量的节点。例如，在一个由六个节点组成的集群环中，每个节点可能监控其后的两个节点是否发生故障。Akka 集群中每个节点监控的默认最大节点数为五个。 Akka 通过节点之间发送心跳并接收响应来实现故障检测。它会根据心跳历史和当前心跳计算节点可用的可能性，并根据这些数据和配置的容差阈值将节点标记为不可用或可用。 #### 4. 传播最终一致性视图的八卦协议 在处理故障检测时，集群中的每个节点会将已知状态传达给其邻居，邻居再将该状态传递给它们的邻居，以此类推，直到该节点的已知状态在整个集群中传播。节点会对集群成员进行审议并得出结论。如果一个节点对某个节点不可访问，则该节点在整个集群中都被视为不可用。 这种在集群中最终传播状态的机制被称为八卦协议或流行病协议（因为信息像病毒一样在集群中传播）。许多最终一致性的数据存储，如 Riak 和 Cassandra，都采用了非常相似的方式。亚马逊的 Dynamo 论文对许多此类数据存储产生了很大影响。 #### 5. CAP 定理概述 CAP 定理是分布式系统设计中的一个重要概念，它描述了分布式系统的三个特性：一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance），以及在这三个特性之间进行权衡的问题。 - **一致性（C）**：客户端对于给定记录将返回最新的值。例如，在银行账户中，存入 400 美元支票后立即尝试提取 400 美元，期望系统给出正确的余额并允许提取。 - **可用性（A）**：非故障节点能够给出合理的响应，例如准确告知写入操作是否成功。 - **分区容错性（P）**：当某个节点因临时网络故障从网络中移除时，系统仍能正常运行。如果数据在三个节点上复制，其中一个节点暂时不可用，若另外两个节点能就最新记录达成一致，则该系统具有分区容错性。 #### 6. CAP 定理中的权衡 CAP 定理常被简化为分布式系统可以选择一致性、可用性和分区容错性中的任意两个，但这是一种误导性的简化。在实际应用中，通常假设系统需要具备分区容错性，然后主要讨论可用性和一致性之间的权衡。 在有时间限制的请求中，如果某个节点不可用，系统需要在返回错误（优先考虑一致性）和继续处理（可能存在服务器之间的不一致，优先考虑可用性）之间做出选择。等待时间过长会导致请求被放弃，因此时间是一个重要因素，系统必须做出决策。 #### 7. 不同类型的系统选择 - **CP 系统（优先考虑一致性）**：可以通过多种方式实现一致的分布式存储。最简单的强一致性数据存储示例是有一个主节点和任意数量的从节点，数据在从节点上复制。始终向主节点写入数据，并从主节点读取数据以确保读取到最新数据。当主节点发生故障时，系统将不再可用，通常会进行故障转移，使一个从节点成为新的主节点。Redis Sentinel 或复制的关系型数据库管理系统（RDBMS）是强一致性分布式系统的典型示例。如果需要原子读写、事务等功能，应选择一致性系统。 - **AP 系统（优先考虑可用性）**：以牺牲一致性为代价来优先考虑可用性和分区容错性的系统被称为“最终一致性”系统。在高可用性的分布式数据存储中，如 Cassandra 和 Riak，这种模型非常常见。 假设数据在三个节点上有三个副本，写入数据时，数据先写入一个节点，然后再复制到其他两个节点。读取数据时，客户端可以随机选择一个节点进行读取。在这个示例中，系统是最终一致的，因为读取的数据可能有点过时，但由于可以从任何节点进行读写，系统既具有分区容错性又具有高可用性。如果某个节点不可用，可以尝试另一个节点。但这种系统很难实现正确，因为系统中事件的时间和顺序很难确定，时钟在不同机器上永远无法完美同步，因此需要采用其他排序方法，如向量时钟。 #### 8. 一致性的滑动尺度 实际上，在 CAP 定理的三个特性之间的选择不是简单的开关，而是可以调整的滑块。在最终一致性系统中，如果要查找的记录有三个副本，可以