Cassandra，
今天看了一下Cassandra，安装运行起来还是很简单的。Cassandra中的4个结构如下：
在cassandra.thrift文件中定义了各种程序和Cassandra交互的数据结构。一点题外话：Thrift是一种可伸缩的跨语言服务的发展软件框架。它结合强大的软件堆栈的代码生成引擎，以建设服务，工作效率和无缝地与C++、C#、Java、Python、PHP和Ruby组合。允许定义一个简单的定义文件中数据类型和服务接口。以作为输入文件，编译器生成代码用来方便地生成RPC客户端和服务器通信的无缝跨编程语言。一个简单的流程吧。
Cassandra对一致性哈希的实现：
个人理解：普通的哈希是根据key对集群数量取模，然后根据这个值来判断在哪个服务器上。这是如果其中的一个服务器挂掉了，那么就调整这个的均衡负载方法很麻烦。但是如果是根据key在一个圆圈上取值的话，那就沿着找一个或者的节点（除非所有的节点都挂掉，不然总能找到）。
Gossip：
消息在网络中的传播类似于流行病在易感人群中传播的方式。节点N将消息m随机地发送给B个邻居。Gossip在初始化的时候构造四个集合：存活的节点、失效的节点、种子节点、各个节点信息。
GossipDigestSynMessage中包括所有节点的地址、心跳版本号和节点状态版本号。接收到消息的节点将进行以下操作：
然后就开始处理GossipDigestAckMessage消息：
最后是GossipDigestAck2Message消息的处理：在本地更新GossipDigestAck2Message消息中包含需要本节点更新的节点信息并调用FailureDetector的report方法更新集群中节点的状态。
怎么感觉这个过程有点像TCP中的三次握手。。。
数据备份
在数据备份的时候需要考虑节点位置上的关系，EndpointSnitch根据需要由近到远排列地址。有四种实现方法：
通过ReplicationStrategy可以知道任意一份数据备份的节点信息，同时在节点失效的时候，能够计算出应该接收HINT消息的节点。Cassantra中的三种实现ReplicationStrategy的机制：
集群状态的变化机制
在Cassandra中，如果节点之间通过Gossiper协议发现集群中的状态发生了变化，将以事件的形式通知这些事件的订阅者。
StorageLoadBalancer能够计算集群中每一个节点的负载，并提供Cassandra集群的负载均衡。每当集群状态发生变化的时候StorageLoadBalancer就将节点负载变化传播下去。StorageService抽象整个Cassandra集群的关系，可以通过它来管理整个集群。MigrationManager用于动态改变Schema。