关于Cassandra的节点通讯机制——Gossip

Cassandra的集群内部用一种叫做gossip的协议来做位置发现和状态信息共享。gossip在国内听别人翻译为“流言协议”，是一种p2p通信协议，通过这个协议，Cassandra节点之间定期地交换自己和自己已知节点的状态信息。这样，节点信息就能像现实中的流言一样迅速扩散出去。

本文翻译自：http://www.datastax.com/docs/1.2/cluster_architecture/gossip

1.关于集群节点和种子节点（Seed）

当一个节点启动的时候，它会从配置文件中读取配置信息，这样它就知道它属于哪个集群，它需要跟哪个节点通信以获取其他节点信息（这个通信节点称为种子节点）。这些信息是必须在每个节点的cassandra.yaml里配置的。

2.配置Gossip

属性描述cluster_name节点加入的集群名，集群内所有节点均应该相同。listen_address别的节点与该节点通信的IP地址，即应该配置为当前节点的IP。默认为localhost，应该改为普通IP地址。seed_providergossip用来获取整个环（集群）拓扑信息的种子节点IP列表。集群内所有节点的种子节点都应该相同，并且在多数据中心的集群中，每个数据中心至少要有一个种子节点在列表中。storage_port集群内部节点的通信端口（默认为7000），整个集群内部必须全部相同。initial_token在1.1之前用来决定节点负责的数据范围。num_tokens

在1.2之后用来决定节点负责的数据范围。

3.清除节点Gossip

gossip是局部持久化信息，并且是节点一重启就立即生效使用。为了清除gossip历史记录重启（例如更换节点IP等情况），需要在/usr/share/cassandra或者 <install_location>/conf下的cassandra-env.sh中添加如下信息：

-Dcassandra.load_ring_state=false

为了阻止gossip分区通信，所有节点配置文件中的种子列表必须相同。

注意：gossip除了在新节点加入集群的时候自举使用外，并无别的目的。因此种子节点不存在单点故障问题。

4.关于故障检查和恢复

故障检查是根据gossip历史记录局部决策的，Cassandra根据gossip历史记录信息来防止访问宕机的节点。 (Cassandra亦能通过dynamic snitch减少访问性能较差的节点.)。

gossip进程可以通过直接（gossip直接通话）或者间接（gossip从直接通话的节点中获取）获取其他节点状态信息。Cassandra不是通过一个固定阈值来判定节点存活的，Cassandra使用权责发生制的检测机制来计算每个节点的阈值，这个机制会考虑到网络性能、工作量等条件。在gossip中，每个节点维护一个滑动窗口来标记其他节点的gossip到达时间。在Cassandra，可以配置phi_convict_threshold属性来调整的故障检测器的灵敏度。在大多数情况下，使用默认值，但对亚马逊EC2（由于频繁地遇到网络拥塞），需要将该值提高到12。

节点故障可能由各种原因引起，如硬件故障和网络中断。这种往往是暂时的，但可以持续延长的时间间隔。集群中一个节点出现故障并不是意味着该节点永久离开，因此Cassandra不会从环中自动永久删除该节点。其他节点的gossip会周期性地尝试通信，看看他们是否恢复。管理员可以使用nodetool工具从集群中永久删除一个节点。

当一个节点重新联机中断后，可能已经错过了它维护的副本数据，一旦故障检测器标记节点宕机，错过的数据均以hinted handoff的方式由邻居节点以hinted handoff的方式保存。如果一个节点宕机时间超过max_hint_window_in_ms（默认为3小时），hinted handoff将不再保留。由于节点宕机的时候可能已经存储有未交付的hinted handoff，你应该运行修复工具来恢复宕机时间较长的节点。此外，你应该定期运行nodetool维护所有节点，以确保它们具有一致的数据。

非特别说明，均为原创文章，转载请注明： 转载自邓的博客

本文链接地址: 关于Cassandra的节点通讯机制——gossip