Cassandra Gossip 协议

（一）Gossip的作用
Cassandra集群没有中心节点，各个节点的地位完全相同，它们通过一种叫做gossip的协议维护集群的状态。
通过gossip，每个节点都能知道集群中包含哪些节点，以及这些节点的状态，这使得Cassandra集群中的任何一个节点都可以完成任意key的路由，任意一个节点不可用都不会造成灾难性的后果。
（二）Gossip协议介绍
gossip的学名叫做Anti-entropy（逆熵？），比较适合在没有很高一致性要求的场景中用作同步信息。信息达到同步的时间大概是log(N)，这里N表示节点的数量。
gossip有两种形式：anti-entropy和rumor-mongering。
gossip中的每个节点维护一组状态，状态可以用一个key/value对表示，还附带一个版本号，版本号大的为更新的状态。
消息的处理有3种方式，Cassandra采用第三种方式——Push-pull-gossip
（三）Gossip消息如何如何发送
当一个节点启动时，获取配置文件（cassandra.yaml）中的seeds配置，从而知道集群中所有的seed节点。
Cassandra内部有一个Gossiper，每隔一秒运行一次（在Gossiper.Java的start方法中），按照以下规则向其他节点发送同步消息：
1、随机取一个当前活着的节点，并向它发送同步请求
2、向随机一台不可达的机器发送同步请求
3、如果第一步中所选择的节点不是seed，或者当前活着的节点数少于seed数，则向随意一台seed发送同步请求
如果没有这个判断，考虑这样一种场景，有4台机器，{A, B, C, D}，并且配置了它们都是seed，如果它们同时启动，可能会出现这样的情形：
1、A节点起来，发现没有活着的节点，走到第三步，和任意一个种子同步，假设选择了B
2、B节点和A完成同步，则认为A活着，它将和A同步，由于A是种子，B将不再和其他种子同步
3、C节点起来，发现没有活着的节点，同样走到第三步，和任意一个种子同步，假设这次选择了D
4、C节点和D完成同步，认为D活着，则它将和D同步，由于D也是种子，所以C也不再和其他种子同步
这时就形成了两个孤岛，A和B互相同步，C和D之间互相同步，但是{A,B}和{C,D}之间将不再互相同步，它们也就不知道对方的存在了。
加入第二个判断后，A和B同步完，发现只有一个节点活着，但是seed有4个，这时会再和任意一个seed通信，从而打破这个孤岛。
（四）Cassandra中Gossip数据结构
gossip通信的状态信息主要有3种：
1、EndPointState
2、HeartBeatState
3、ApplicationState
HeartBeatState 由generation和version组成，generation每次启动都会变化，用于区分机器重启前后的状态；Version是只能增长的，每次心跳之前进行递增
ApplicationState用于表示系统的状态，由state和version组成，state表示节点的状态，version是递增的，每个对象表示节点一种状态，比如表示当前load的状态大概是这样：(1.2, 20)，含义为版本号为20时该节点的load是1.2
EndPointState 封装了一个节点的ApplicationState构成的映射（Map<String, ApplicationState> applicationState_）和HeartBeatState
一个节点自身的状态只能由自己修改，其他节点的状态只能通过同步更新。
（六）Gossip状态信息有哪些
负载信息（LOAD-INFORMATION）
迁移信息（MIGRATION）
节点状态信息（MOVE）
BOOT（启动阶段）节点正在启动
NORMAL（正常）节点加入了Token的ring，可以提供读
LEAVING，节点准备离开Ring
LEFT，节点被踢出集群或者是Token信息被手工变更
（七）Gossip消息同步过程