假设典型的Web服务存在典型的关注点：
Cassandra的高可用性功能有哪些以确保Client-API的正常运行时间（自定义代码）？
典型的解决方案包括：
然而，我似乎无法提及这一点，包括提及“最佳实践”或“这就是我所做的”。
具体到目前我正在学习Cassandra，我有兴趣将它介绍给Zend Framework（PHP）项目，并希望了解从多个Client-API机器到Cassandra的高可用性连接的最佳实践。
可以管理一次性故障，但由于各个故障节点导致的服务停机时间显然不理想..
另外，如上所述，解释如何在高可用性环境中在Cassandra中管理Split-Brain的奖励积分。
答案 0 :(得分：1)
Cassandra通过设计支持容错/ HA。要理解这一点，请阅读Cassandra中的暗示切换和消息路由。
对于裂脑处理，您可以考虑使用 Cages java lib来实现分布式同步功能/锁等。
来自 Cassandra - A Decentralized Structured Storage System ：
Cassandra使用复制来实现高可用性和持久性。每个数据项都在N个主机上复制，其中N是配置为每个实例的复制因子。每个密钥k被分配给一个协调器节点。协调器负责复制其内部的数据项。除了在其范围内本地存储每个密钥之外，协调器还在环中的N-1个节点复制这些密钥.Cassandra为客户端提供了各种数据复制需求的选项.Cassandra在现场提供持久性保证。通过放宽法定人数要求来节点故障和网络分区。
如果客户端连接到群集中的随机节点，例如node1，则可能存在以下情况：
<强> READ
[SUCCESS] node1为UP并且还具有请求的数据
[SUCCESS] node1是UP并且没有所请求的数据，因此充当协调节点并将请求路由到具有数据的副本，例如node2。假设node2已启动并可以提供请求
[NODE DOWN] node1为DOWN并具有所请求的数据。客户端收到UnAvailableException并可以连接到群集中的其他节点。如果需要为查询服务的最小副本可以响应，那将是成功的。
[REPLICA NODE DOWN] node1已启动并且没有所请求的数据，因此充当协调器节点并将请求路由到具有数据即node2的副本。假设node2为DOWN且无法提供请求。如果其他副本没有死亡并可以满足请求，那将是成功的。如果在发送请求时副本已启动，但在抛出TimedOutException之后立即停止。客户端可以连接到群集中的其他节点。
<强> WRITE
[SUCCESS] node1为UP，并且还假设存储所请求的数据
[SUCCESS] node1是UP并且没有所请求的数据令牌范围（不负责存储这条数据）因此充当协调节点并将请求路由到副本，例如node2，假设存储数据。假设node2已启动并可以为请求提供服务。
[NODE DOWN] node1为DOWN，并且还假设存储所请求的数据。客户端收到UnAvailableException并可以连接到群集中的其他节点。由于主节点已关闭，因此提示的切换请求存储在副本中。
[REPLICA NODE DOWN] node1是UP并且没有所请求的数据令牌范围（不负责存储这条数据）因此充当协调节点并将请求路由到副本，例如node2，假设存储数据。假设node2为DOWN且无法提供请求。如果其他副本没有死亡并可以满足请求，那将是成功的。提示的动手将写在副本/协调节点上。