Cassandra教程---- 节点间交互(gossip)

Posted 2020-07-03

Gossip是一个P2P的协议，在Cassandra集群中的节点利用它交换相互间的信息。名叫gossip的进程在集群中每秒交换数据的节点多达3个以上，由于节点交换了自己和相关节点间的信息，所以节点很快就可以知道集群中的其他节点（就是一个一传十、十传百的概念）。gossip消息是有版本的，当进行一次信息交换后，旧的信息就被覆盖掉。为了防止在gossip通讯的时候出现分歧，需要在集群中的所有节点使用相同的”种子节点“——这在节点第一次启动的时候的关键点。

注意：在多个data center集群中，seed list应该至少有一个在每个datacenter中。建议在每个data center中配置多于1个seed node，以便容错。否则gossip必须与其他data center交互当启动一个节点时。不建议将每个节点都标记为seed节点，因为这会增加维护和减少gossip性能。建议使用较少的seed列表(每个data center三个节点)

  故障检测与恢复

故障检测是通过gossip状态和历史信息进行本地检测其他节点是否挂掉的一种方法。Cassandra通过这些信息防止把客户端的请求路由到一个不可用的节点。（Cassandra也可以通过dynamic snitch把客户端请求路由到负载较低的节点）。

gossip进程通过直接（节点通过gossip直接交互）或间接（节点通过二次或三次或更多的通讯）的方式跟踪其他节点的状态。不同于使用固定阀值标注失效节点，Cassandra通过统计网络性能、负载和历史信息的自然检测机制来计算每个节点的阀值。当gossip进行交换时，每个节点维护了一个集群中其他节点的gossip消息到达的时间间隔的滑动窗口。配置phi_convict_threshold的值可以调整故障检测的灵敏度。较低的 phi_convict_threshold值增加了未响应节点被标记为挂掉的可能性，较高的phi_convict_threshold值减少了将导致节点失效的瞬时故障。大多数情况下可以使用默认值

节点失效可能是由于硬件故障或网络中断引起的。节点中断通常是短暂的，当然也有长时间的。那是因为节点的中断很少标记自己永久性的离开这个集群——节点并不会自动说我要永远离开集群。其他节点将周期性的尝试重新连接失效的节点，以便了解它是否上线了。为了永久性的改变节点在集群中的资格，管理员应该明确的使用nodetool工具添加或删除节点。

当挂掉的节点上线后，一般情况下会丢失本来应该由它管理的副本数据。当失效检测器标记了一个节点挂掉后，错过的写操作将通过hinted handoff在一段时间内存储到其他的副本。如果一个节点挂掉的时间超过max_hint_window_in_ms标志的时间（默认3小时），hints就不再保存数据。挂掉的节点有可能存储了未释放的hints。恢复一个长时间挂掉的节点时，运行一下恢复工作。另外，管理员应该例行在每个节点运行nodetool repair保障数据的一致性。

本文出自 “java架构师之路” 博客，请务必保留此出处http://eric100.blog.51cto.com/2535573/1759950