Cassandra的节点之间交互(gossip) 推荐

在讲gossip之前，首先定义什么是Cassandra实例。

Cassandra实例：

是一组在集群中的独立节点，所有的节点是对等的。

Cassandra节点之间的交互：

Cassandra节点之间通过gossip协议（最终一致性原理）来发现其他集群中节点的位置和状态信息。这个gossip协议是peer-to-peer的，不同节点定期（每秒最多和3个其他节点）交换状态信息，这些信息带版本号，所以旧信息会被新的覆盖掉。节点信息配置在cassandra.yaml文件中。

种子节点（节点的代表）：

当节点第一次启动时，它会去查配置文件cassandra.yaml从而得到它属于的集群名称，但是它如何获得集群中其他节点的信息呢？就是通过种子节点（seed node).记住，同一集群中所有的节点的cassandra.yaml中必须有相同的种子节点列表。





选派谁做种子节点没什么特别的意义，仅仅在于新节点加入到集群中时走gossip流程时有用，所以它们没什么特权。

Cassandra故障探测：

Gossip 进程（Gossiper)通过每个节点的心跳（heartbeat)来感知每个节点是否还存活。它会考虑到网络状况，负载等因素综合考虑来计算节点心跳时间的临界值。gossip过程中，每个节点都维护着其他节点gossip消息的内部到达次数。在Cassandra中，如果配置phi_convict_threshold，可以调节失败探测的敏感度，从而适应相对不可靠的网络环境,超过这个时间（秒）则被cassandra认为这个节点down了。





节点down了只表示节点暂时与Cassandra集群脱离了，而不是永久脱离。所以，集群中的节点依然会向这个down了的节点定时发送gossip信息来探测是否这个节点恢复了。如果要永久的把这个节点从集群中移除，必须用

Cassandra节点故障恢复：

短时间down的恢复：

当一个节点恢复之后，也许它少了一些已经写入其他节点的数据，那么它将从它故障点开始，从其他备份获得数据）.

长时间down的恢复：

如果一个节点down的时间超过max_hint_window_in_ms设置的值，则超过这个时间的写操作部分是没办法恢复的。这时候我们可以在所有节点上运行nodetool维护，以确保他们有一致的数据。