cassandra 3.x官方文档(3)---gossip通信协议及故障检测与恢复

写在前面

cassandra3.x官方文档的非官方翻译。翻译内容水平全依赖本人英文水平和对cassandra的理解。所以强烈建议阅读英文版cassandra 3.x 官方文档。此文档一半是翻译，一半是个人对cassandra的认知。尽量将我的理解通过引用的方式标注，以示区别。另外文档翻译是项长期并有挑战的工作，如果你愿意加入cassandra git book,可以发信给我。当然你也可以加入我们的QQ群,104822562。一起学习探讨cassandra.

Gossip

Gossip 是一个对等网络通信协议，节点间断性的交换他们自身的状态信息以及其他它们知道的节点信息。gossip 每秒中和集群中最多三个节点交换信息。不仅交换他们自身信息，而且还交换通过之前的gossip通信了解的其他节点信息，所以所有的节点能够很快的了解集群中的其他节点状况。一条gossip 信息会有一个相关联的版本号，因此当进行gossip交换的时候，对于一个特定的节点，它的老信息就会被最近的状态所覆盖。

为了阻止gossip通信可能出现的问题，集群中所有的节点都有相同的seed nodes列表。这一点在一个节点第一次启动的时候尤其重要。默认情况下，一个节点在随后的重启过程中会记住已经gossip的其他节点。seed node就是为了新节点加入到集群中，bootstrap过程中使用的。不是为了单点失败，也没有其他特别的目的。

注意:

在多数据中心集群环境，确保每个数据中心至少有一个节点在seed list中。为了容错建议每个数据中心指派多个seed node,否则当一个节点bootstrap时，需要同其他数据中心gossip。

不建议把每个节点都设置为seed node,因为会增加维护的成本以及降低了gossip的性能。gossip优化并不是特别重要，但是建议使用一个小的seed 列表(每个数据中心3个节点最佳)

失败检测和恢复

失败检测是一种为本地决策提供信息的方法，从gossip的状态和历史获取信息，判断系统中的一个节点是否down了或者已经恢复了。Cassandra 利用这个信息避免将客户端的请求路由到任何时候有可能不可到达的节点。(cassandra 同样能够通过Dynamic Snitch)避免将客户端请求路由到那些存活的但是性能比较差的节点上。

gossip过程能够跟踪其他节点的状态，通过直接(直接与某个节点gossip)或非直接(通过二手，三手等)方式。相比于一个固定的阈值来标记一个节点为fail，Cassandra 采用一个自然增长的检测机制来计算每个节点的阈值，考虑到了网络、负载、历史状况等因素。当进行gossip交换时，每个节点维护了一个其他节点gossip信息到达的滑动窗口时间。可以通过配置phi_convict_threshold属性来调节失败检测的敏感性。值越低，一个没有应答的节点更有可能被标记为down,值越高，短暂的失败更低可能的被标记为失败。大部分情况下，默认值就可以了。但是在Amazon EC2上需要增加到10或者12.(因为常常会遇到网络拥堵)，在不稳定的网络环境中(比如EC2)，提高值到10或者12可以帮助避免错误的失败检测。不建议使用高于12，或者低于5的值。

节点失败可能有各种各样的原因造成的，比如硬件失败，网络电力供应中断。节点中断经常是短暂的但是有可能持续很长时间的。因为一个节点中断很少意味着永久离开集群，不会自动从集群ring中移除。其他的节点会周期性的尝试和失败的节点重新建立联系，看它们是否已经回归。想要永久的改变集群节点的成员关系，需要管理员通过notetool明确的将节点添加进来或者移除出集群。

当一个节点经过down到重新回归的，可能会丢失掉它需要维护的副本数据。repair可以帮助恢复这些数据，比如hinted handoffs以及手动repair.节点down掉的时间决定了通过哪种机制来保持数据的一致性。

注：

hintedhandoff有时间限制，默认三小时，超过此时间前面的数据会不断的被覆盖掉。必须要手动repair