节间通讯、故障检测和恢复讲解

节间通讯（gossip）

gossip是一种对等通信协议，在这种协议中，节点周期性地交换关于他们自己和他们所知道的其他节点的状态信息。gossip进程每秒运行一次，并与群集中最多三个其他节点交换状态消息。节点交换关于自己和其他节点的信息，所有节点都快速了解集群中所有其他节点。gossip消息具有与其关联的版本，以便在gossip交换期间，旧信息被特定节点的最新状态覆盖。

为了防止gossip通信中的问题，请使用群集中所有节点的相同种子节点列表。节点首次启动时，这是最关键的。默认情况下，节点会记住在后续重启之间gossip的其他节点。种子节点名称除了为加入群集的新节点引导gossip流程之外，没有其他目的。种子节点不是单一故障点，除了引导节点之外，它们在群集操作中也没有任何其他特殊用途。

注意：在多个数据中心群集中，从种子列表中的每个数据中心（复制组）至少包含一个节点。为了容错，建议为每个数据中心指定多个种子节点。否则，在引导节点时，gossip不得不与另一个数据中心进行通信。

不建议将每个节点设为种子节点，因为增加了维护成本减少了gossip性能。gossip优化并不重要，但建议使用小的种子列表（每个数据中心大约三个节点）。

故障检测和恢复

如果系统中的另一个节点已关闭或已经恢复，则故障检测是一种从gossip状态和历史记录本地确定的方法。Cassandra使用此信息来避免将客户端请求尽可能路由到无法访问的节点。（Cassandra也可以避免将请求路由到活着的节点，但是通过动态节奏表现不佳。）

gossip过程直接跟踪来自其他节点的状态（节点直接向其闲聊），间接地（关于二手，三手等等传达的节点）跟踪状态。Cassandra使用权责发现机制来计算考虑网络性能，工作负载和历史条件的每个节点的阈值，而不是具有用于标记失败节点的固定阈值。在八卦交换期间，每个节点维护一个来自集群中其它节点的闲聊消息到达时间的滑动窗口。配置phi_convict_threshold属性调整故障检测器的灵敏度。较低的值会增加无响应节点被标记为关闭的可能性。在大多数情况下使用默认值，但对于Amazon EC2，将其增加到10或12（由于经常遇到网络拥塞）。在不稳定的网络环境（如EC2有时）中，将值提高到10或12有助于防止错误的失败。不建议高于12和低于5的值。

节点故障可能由各种原因造成，如硬件故障和网络中断。节点中断通常是短暂的，但可以持续很长时间。由于节点中断很少意味着永久离开集群，因此不会自动导致节点从环中永久移除。其他节点将定期尝试重新建立与失败节点的联系，以查看它们是否备份。要永久更改节点在集群中的成员资格，管理员必须使用nodetool实用程序明确添加或从Cassandra集群中删除节点。

当一个节点在中断后重新联机时，它可能错过了它所维护的副本数据的写入。存在修复机制来恢复丢失的数据，如提示节点修复和手动修复。停电的长度将决定使用哪种修复机制来保证数据的一致性。