Cassandra 2.x中文教程(6):理解架构之内部节点通讯——Gossip


在前面《Cassandra 2.x中文教程(5):理解架构之配置Cassandra的关键组件》我们已经了解到Cassandra使用Gossip进行节点间的信息交换,今天我们就来仔细了解一下Gossip在Cassandra中的作用。

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

 

故障检测和恢复

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

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

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

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

关于更多的hint存储,我们将后面介绍。

 

参考:Cassandra2.0官方文档

版权声明:本文《Cassandra 2.x中文教程(6):理解架构之内部节点通讯——Gossip》为【屁民部落】原创/翻译文章,转载时请注明出处!
本文地址:http://pimin.net/archives/180