cassandra （2）Understanding the Architecture【About internode communications (gossip)】，internodegossip
关于节点间的通信 (gossip)
Cassandra通过gossip协议获集群中其它节点的位置和状态信息。gossip是一个节点间定期与其它节点交换它们本身和它所了解的其它节点的信息的点对点协议。集群中每时每刻都在用运行gossip协议用于交换节点间交换节点和节点所拥有的其它节点的信息。这样，节点就可以很快知道集群中其它所有节点的信息。gossip消息有一个版本信息，这样在gossip消息在交换过程中，就的信息就会被重写，被替换为最近的消息。为防止通信中的分区，在集群中每个节点应使用相同的种子列表。这对节点的第一次启动来说是很关键的。默认情况下，在随后的重启中，节点记住与它进行gossip通信的节点。
注意：种子节点除了引导新加入的节点启动时进入集群并没有什么特别的用途。种子列表没有单点失败。
配置gossip
cluster_name：命名加入简单的集群名字，所有节点必须一致。
listen_address：ip地址或者是主机名用于其它cassandra节点连接本节点。值应该从localhost改为公共地址或者是host
seed_provider：一个以逗号分隔的ip或者是host列表，此项用于gossip了解集群环的拓扑。每个节点的种子列表应该一样。在多数据中心的集群中，种子列表应覆盖各个数据中心
storage_port：内部节点通信端口，默认7000，集群中所有节点必须一致。
initial_token：决定节点所负责的数据范围，在1.1版本或更早的版本中。
num_tokens：决定节点所负责的范围数量，在1.2版本以及以后版本中。
清除某一个节点的gossip状态
gossip信息存储在本地，因此，节点重启时可以直接使用而无需等待gossip通信。
你或许想清除gossip历史，当某一节点的ip地址改变或因其他状况重启时。
1、编辑cassandra-env.sh
添加 -Dcassandra.load_ring_state= false 到文件中
关于故障检查与恢复
如果另一个节点上线或下线，故障检查是依据gossip的状态和历史用本地方法检测决定的。只要允许，cassandra会用此信息来避免将请求路由到不可达的节点上。（cassandra同样可以避免路由请求到活着的节点上，但在动态消息通信下，这种情况很少见。
gossip过程直接（节点直接发gossip消息给他）或者间接（通过其它节点间接获得)地跟踪其他节点的状态。相较于使用固定的阀值来标记失败的节点，cassandra采用权责检测机制，依据网络性能、工作负载或者其他条件来计算每个节点的阀值。在gossip消息交换时，cassandra保持一个接受其他节点gossip消息的滑动窗口期。在cassandra中，通过配置 phi_convict_threshold 属性来调节故障检查器的灵敏度。在多数情况下用默认的值，在Amazon EC2应增加到12（因为经常会发生网络阻塞）。
多种因素会造成节点失败，如硬件故障，网络中断等。节点中断往往是短暂的，但可持续间隔期。一个节点的中断很少意味着永久离开集群，因此，并不会从集群环上删除节点。其他节点会定期尝试去跟失败的节点建立gossip连接，以检测他们是否有备份。要永久性的改变集群中的节点，管理员必须显示的使用nodetool工具添加或删除节点。
当一个节点从中断中恢复后，它或许丢失了它所拥有的副本数据。一旦检测器标记一个节点down，节点 hinted handoff 激活，在一段时间内，丢失的写操作将被其它副本存储。如果一个节点down的时间超过max_hint_window_in_ms（默认3小时），hints将不会再存在。因为节点可能存储了不能被传递的hints，你在恢复一个down掉的节点后，应该运行repair一段时间，以确保他们一致性的数据。
等多的恢复解释见Modern hinted handoff。