Cassandra1.2文档学习（2）——节点间通信协议之gossip协议
参考文档：http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html#cassandra/architecture/architectureGossipAbout_c.html#concept_ds_elb_tgd_fk
一、什么是gossip
Cassandra使用一个名为gossip的协议去获得集群中其他节点的位置和状态信息。Gossip是一个点对点的通信协议，在这个协议中，节点之间定期交换状态信息。Gossip协议每隔一秒运行一次，节点和不超过的三个节点交换信息，因此所有的节点能够很快知道集群中其他节点的信息。每一个gossip信息有一个版本，因此在信息的交换中，旧的信息会被新的状态信息覆盖。
为防止gossip通信的发生隔离，保障数据的一致性和完整性，在一个节点中的所有节点应当使用相同的Seed列表（Seed节点负责和集群中的其他节点通讯并获取信息，Cassandra读取和写入数据都是向Seed节点发出操作指令，这些节点应该相对稳定）。当节点第一次启动时Seed列表信息非常重要。
二、配置gossip
当一个节点启动的时候，它会去读取配置文件cassandra.yaml从而决定它属于那个集群，从那个节点获得集群中其他节点的信息以及一些其他的参数。
具体的配置参数如下
这个节点属于的Cassandra集群的名字，集群中的每一个节点的集群名字都应该是一样的。
当前节点的ip地址或者主机名，使得其他节点能够联系到这个节点。这个地址应该是公共地址，而不是localhost。
通过逗号分隔的seed节点的主机名或ip地址。每个节点的此选项应该是一致的。在包含多个数据中心的集群中，每个数据中心都应该有一个seed节点。
节点间通信端口（默认为7000）。集群中每个节点的配置应该是一样的。
这个参数使用在被一个节点只有一个token的架构下，在一致性哈希环中每个节点都有一段连续的范围，有token表示。当Cassandra第一次启动的时候，会从该配置项中读取，如果唯恐，将随机生成一个token。如果Cassandra不是第一次启动，将从系统表中读取该Token值。
在虚拟节点的时候使用。定义随机分配到该节点的token的数量。原来情况下，一个节点只有一个token，很容易造成数据都在一个节点上的情况，采用虚拟节点，每个节点有多个token，可以进行平均。
三、删除节点的gossip历史信息
gossip信息一直保留在本地，这样当节点重启的时候可以无需等待gossip的交互。
在某些情况下（例如节点IP地址发生改变），你可能希望清除gossip历史信息。
方式：
编辑cassandra-env.sh文件:
加入以下一行
-Dcassandra.load_ring_state= false
四、故障检测和恢复
故障检测是通过分析gossip状态信息和历史信息，判断系统中其他节点是否宕机的一种方法。Cassandra通过这种方式来避免将客户端请求转发到已经挂掉的节点。通过动态告密者（dynamic snitch），Cassandra还可以避免将请求转发到那些那些虽然存活但是性能特别差的节点。
gossip从直接或者间接节点中跟踪信息，Cassandra通过一个权责监测机制来计算每一个节点的阀值，综合考虑网络情况、工作负载和其他情况，而不是采用一个固定的阀值来判断是否是一个失败的节点。在gossip交互中，每个节点维护一个滑动的窗口关于集群中其他节点gossip到达的时间。在Cassandra中，可以通过配置 phi_convict_threshold属性值来调整故障检测的敏感度。大多数情况下可以使用默认值，但在Amazon EC2平台中请将数值增加到12。
导致节点失败的原因有很多种，比如硬件出错和网络中断。节点中断通常短暂但可以持续更长的时间间隔。一个节点的中断很少意味着从集群永久离开，因此不会自动的被从环中移除。其他节点会周期性的给它发gossip信息已查看这个节点是否恢复正常。要想永久的改变集群中节点的成员信息，管理员必须采用nodetool工具显示地增加或移除节点。
当一个节点从中断中回来的时候，它可能会错失一些本来应该写入这个节点的数据。当故障检测机制标明一个节点是挂掉的，错失的写入会被存储在其他节点，前提是 hinted handoff机制被打开。如果节点的宕机时间超过max_hint_window_in_ms (默认3个小时)，hint信息也不会被存储。因为节点的挂掉可能会导致存储为发送的hint信息，你应当在节点被发现挂掉一段时间后运行恢复。此外，你应当在所有节点上周期性的运行nodetool repair 以确保数据的一致性。
