Cassandra使用叫做Gossip的协议发现集群中其他节点的位置和状态信息。Gossip是一个点对点的通信协议，节点之间会周期进行状态信息交换——这些信息包括当前节点本身信息，以及当前节点存储的其他节点的状态信息。 在Cassandra中，gossip进程每秒钟都会和集群中的其他三个节点交换状态消息。状态信息包括节点自身的信息、以及所存储的其他节点的信息，这样集群中的节点，很快就能够互相了解。gossip消息都有一个版本信息，随着交换的进行，旧的信息会逐渐被旧的信息覆盖。 集群成员和种子节点 当节点第一次启动，它会从配置文件中确定所属Cassandra集群的名字，以及确定seeds node（我翻译为种子节点），通过这些seeds node，可以获取集群中其他节点的信息。这些配置信息，都在cassandra.yaml配置文件中。 为了避免gossip通信分区，集群中所有节点必须配置相同的seeds node列表。这对节点第一次启动来说至关重要。默认的，节点会在后续的重启过程中，记住这些与它交换gossip信息的节点。 Note：seed node的设计，并没有特殊的目的，仅仅是为了能够处理新加入节点到集群中的情况。 为了知道节点存储的是哪个范围内的数据，节点必须知道它自己的token，以及集群中其他节点的token。当初始化一个新的集群，开发人员需要为集群生成tokens，并且将这些tokens分配给每一个节点。切记，这个操作要在第一次启动之前完成。当集群启动之后，节点会通过gossip将自己的token告诉其他节点，同时也知道其他节点的token。更多可以看Cassandra数据划分。 关于失败检测和恢复 失败检测是根据gossip状态信息，判断集群中的另一个节点是否正常。失败检测可以用来避免客户端发送请求到不可达的节点。 gossip会追踪其他直接或者间接节点的心跳信息。Cassanda没有采用一个固定的阈值，作为宕机的标志，而是通过一个稍微复杂的监测机制进行的：具体会包括网络条件，服务器负载或者其他的可能影响到心跳频率的条件。在gossip消息交换过程中，每一个节点维护这一个其他节点的的gossip消息到达时间的窗口。phi值就是基于集群中所有节点的内部到达时间的分布。在Cassandra中，配置phi_convict_threshold属性可以调整失败检测的敏感度。在绝大多数的情况下，使用默认值即可。但是，DataStax推荐将其设置为12，当Cassandra部署在EC2之上的时候，主要原因是因为EC2上网络竞争比较激烈。 造成节点失效的原因可能有很多中：硬件故障，网络中断等等。节点中断经常是短暂的，但也可能会延长。一个节点的中断，不会造成节点永久的从集群中移除。其他的节点，仍旧会周期性的发送gossip消息，以判断中断节点是否恢复。如果想永久的改变节点的成员关系，管理员必须显示的通过nodetool进行删除和添加节点。 当一个节点从中断恢复之后，可能会缺少一些本来应该写入这个节点的数据。一旦检测到某一个节点宕机，原先要写入宕机节点的操作，会写入其他节点进行代替，这个需要打开hinted handoff。然后，也有可能，一些数据会真的丢失，因为检测失败是有延迟的。或者，一个节点，宕机时间超过max_hint_window_in_ms（默认是1小时），hints的数据，将不会写入到其他节点。因为这个原因，定期例行的在每一个节点上执行nodetool repair是非常有必要的。这样可以帮助保证数据的一致性。在宕机节点恢复之后，也要执行repair，可以帮助恢复数据。 【原文地址】 http://www.datastax.com/docs/1.1/cluster_architecture/gossip 这篇理解得不好，主要是gossip不够熟悉，需要加强。后面的几段，对于运维来说，还是非常重要的。 【完】