Cassandra探究（一）

如下图，一个拥有3个Node的Cassandra集群。Cassandra是不分主从节点的，也就是说，集群中每一个节点的地位都是相同的。

复制因子 Replication factor

如果复制因子设置为2，则保存数据时，每一份数据会被存两份到其中两个节点上。官方推荐：复制因子大小最好与集群节点数一样，这样，每个节点都有一份副本数据。

读一致性与写一致性

由复制因子引发的读一致性与写一致性。

读一致性

如果读一致性设置为1，则随机读取到任意一个节点上的数据就认为读取成功；为2则需要读取到两个节点的数据才认为成功；读一致性参数设置的越大，效率越低，但查询结果的可靠性就越大。如果读一致性过小，则可能读取到的节点正好是需要被修改过但还没有进行同步的旧数据。

写一致性

写入一个节点成功即认为成功（Cassandra自己的节点内部通信去同步到整个集群。Cassandra使用点对点通讯协议gossip在集群中的节点间交行位置和状态信息，gossip进程每秒运行一次，与至多3个其他节点交换信息。 Gossip:一个点对点协议，用于发现和共享在Cassandra集群中别的节点的数据的状态等信息。）。

memtable与sstable

Cassandra的设计目的是通过没有单点故障的多节点模式去处理海量数据工作负载，它的架构是基于理解系统和硬件故障是可以而且会发生的基础上的。Cassandra通过peer-to-peer分布式系统来解决故障问题，该系统中的节点是平等同类的，数据都分布在所有节点上。通过gossip通信协议，集群中的每一个节点频繁地交换着状态信息。每个节点上的commit log捕获写行为来确保数据的持久化。

数据会被索引并写入一个名为memtable的内存结构，每当内存结构满了后，数据就会被写到一个叫SSTablede 磁盘文件中。所有的写入都是自动分区和复制的。Cassandra会通过一个叫Compaction的进程周期性的整合SSTables，准备丢 弃的过期无用数据会标记上tombstone以待删除。为了确保所有数据在集群上保持一致，各种各样的修复机制被利用。

 Cassandra是一个分区的面向行存储的数据库。Cassandra的架构允许任何授权了的用户连接任何数据中心的任何节点，并使用cql访问数据。客户端的读写请求可以到达集群的任意节点。当一个客户端连接到一个节点做一个请求时，那个节点服务器就作为这个特定的客户操作的一个coordinator，coordinator扮演了客户应用和拥有用户请求的数据的节点之间的代理的角色。coordinator会根据集群中的配置决定哪些节点应该响应请求。相当于客户端连到哪个节点，哪个节点就是一个协调者，去所有节点中查询数据。

墓碑 tombstone

Cassandra删除数据是给待删除的数据打一个tombstone标记，说明该数据已经无用，但为了保证所有节点上的数据的一致性，所以不会直接去物理删除。

考虑这样的情况：复制因子为3，即3个节点上都有一个副本，删除数据时，有两个节点的副本删除成功，一个节点的副本删除失败，整个删除操作仍然被认为成功的（因为有两个节点应答成功，使用CL.QUORUM一致性）。接下来如果读发生在该节点上就会变的不明确，因为结果返回是空，还是返回数据，没有办法确定哪一种是正确的。

注意：这个问题没有完全解决，即便使用了墓碑，所以假设你的集群有删除操作的话我们还要有如下操作: Cassandra运维人员必须在每个gc_grace_seconds周期内对整个集群进行repair操作。

Repair操作

为什么要Repair?

在gc_grace_seconds设置的时间到达之前（一般为10天的秒数），每一次查询都会将符合条件是数据（包含已删除的）都给查询出来，然后Cassandra再将有墓碑标记的数据给过滤掉，这其实浪费了大量的计算资源。

Repair对Cassandra集群是极为重要的，因为频繁的数据删除以及机器Down掉（尽管有Hinted Handoff机制）都会可能导致数据不一致（多个副本之间）。在Cassandra日常维护中，我们要例行对集群进行Repair操作，使用nodetool的Repair命令，在每个节点上都执行一遍repair操作，使数据一致。

删除墓碑

墓碑的宽限期结束后，Cassandra在压缩过程中会删除墓碑。

逻辑删除的宽限期由属性gc_grace_seconds设置。它的默认值是864000秒（十天）。每个表都可以有自己的属性值。

在截止时间结束时，Cassandra在执行compaction 操作的过程中墓碑将被删除。