本文详细讲述了Cassandra基础知识、数据模型、数据分布策略、存储机制、数据读写删、最终一致性、Gossiper

1. Cassandra架构与应用 For Cassandra 0.7.0 淘宝网 文茂

2. Agenda 基础知识 数据模型 数据分布策略 存储机制 数据读写删 最终一致性 Gossiper 面向未来

3. NoSql背景 随着互联网大规模的Web2．0应用的兴起，随着云计算需要的大规模分布式服务和分布式存储的发展，传统的关系数据库面临着诸多全新的挑战，特别是在那些超大规模和高并发的SNS类型的应用场景下，使用关系数据库来存储和查询用户动态数据已经显得力不从心，暴露了很多难以克服的问题，例如需要很高的实时插入性能；需要海量的数据存储能力同时还需要非常快的查询检索速度；需要将数据存储无缝扩展到整个群集环境下，并且能够在线扩展等等。在这样的背景下，NoSQL数据库就应运而生了。

4. NOSQL is simply Not Only SQL!

5. NOSQL特点 不要叫它们数据库 它们可以处理超大量的数据 它们运行在便宜的PC服务器集群上 它们击碎了性能瓶颈 Bootstrap支持

6. CAP

7. ACID/BASE ACID 原子性(Atomicity). 事务中的所有操作,要么全部成功,要么全部不做. 一致性(Consistency) 在事务开始与结束时,数据库处于一致状态. 隔离性(Isolation). 事务如同只有这一个操作在被数据库所执行一样. 持久性(Durability). 在事务结束时,此操作将不可逆转.(也就是只要事务提交,系统将保证数据不会丢失,即使出现系统Crash,译者补充). BASE Basically Available（基本可用） Soft state（柔性状态） 状态可以有一段时间不同步，异步 Eventually consistent（最终一致） 最终数据是一致的就可以了，而不是时时一致

8. 最终一致性 场景介绍 （1）存储系统 存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证。 （2）Process A ProcessA主要实现从存储系统write和read操作 （3）Process B 和ProcessC ProcessB和C是独立于A，并且B和C也相互独立的，它们同时也实现对存储系统的write和read操作。 强一致性 强一致性（即时一致性） 假如A先写入了一个值到存储系统，存储系统保证后续A,B,C的读取操作都将返回最新值 弱一致性 假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念，它特指从A写入值，到后续操作A,B,C读取到最新值这一段时间。 最终一致性 最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统，存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话，最终所有的读取操作都会读取到最A写入的最新值。此种情况下，如果没有失败发生的话，“不一致性窗口”的大小依赖于以下的几个因素：交互延迟，系统的负载，以及复制技术中replica的个数（这个可以理解为master/salve模式中，salve的个数）。

9. Casandra是什么？ Cassandra是一个高可靠的大规模分布式存储系统。高度可伸缩的、一致的、分布式的结构化key-value存储方案。 2007由facebook开发 已经在生产环境中使用，比如emailindexsearch 2009年成为Apache的孵化项目

10. Cassandra有什么特点？ 列表数据结构 在混合模式可以将超级列添加到5维的分布式Key-Value存储系统。 模式灵活 使用Cassandra，你不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。 真正的可扩展性 Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量，可以增加动态添加节点即可。你不必重启任何进程，改变应用查询，或手动迁移任何数据。 多数据中心识别 你可以调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的完全复制。 范围查询 如果你不喜欢全部的键值查询，则可以设置键的范围来查询。 分布式写操作 有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。

11. Agenda 基础知识 数据模型 数据分布策略 存储机制 数据读写删 最终一致性 Gossiper 面向未来

12. 数据模型 Column SuperColumn ColumnFamily Keyspaces Row

13. Column

14. Column Family{Columns}

15. Super Column

16. ColumnFamily {SuperColumns}

17. Keyspaces 一个Keyspace是Cassandra哈希第一维，是ColumnFamilies容器。 一般来说，我们的一个程序应用只会有一个Keyspace，相当于关系数据库的一个数据库.

18. Row Row以key为表示，一个key对应的数据可以分布在多个column family中，通常我们都只会存放在一个column family中。

19. 数据定位 第一层索引所用的 key 为 (row-key, cf-name)， 即用一个 row-key 和 column-family-name 可以定位一个 column family。column family 是 column 的集合。 第二层索引所用的 key 为 column-name， 即通过一个 column-name 可以在一个 column family 中定位一个 column。

20. Agenda 基础知识 数据模型 数据分布策略 存储机制 数据读写删 最终一致性 Gossiper 面向未来

21. 数据分布策略 Distributed hash table Partitioner类型 RandomPartitioner OrderPreservingPartitioner ByteOrderedPartitioner CollatingOrderPreservingPartitioner 副本策略 LocalStrategy RackUnawareStrategy RackAwareStrategy DatacenterShardStategy

22. Distributed hash table

23. Partitioner类型 RandomPartitioner 随机分区是一种hash分区策略，使用的Token是大整数型(BigInteger)，范围为0~2^127，因此极端情况下，一个采用随机分区策略的Cassandra集群的节点可以达到2^127+1个节点。 为什么是2^127？ Cassandra采用了MD5作为hash函数，其结果是128位的整数值(其中一位是符号位，Token取绝对值为结果)。

24. Partitioner类型 RandomPartitioner 4个节点，随机分配的Token分布情况 采用随机分区策略的集群无法支持针对Key的范围查询。 假如集群有N个节点，每个节点的hash空间采取平均分布的话，那么第i个节点的Token可以设置为：i * ( 2 ^ 127 / N )

25. Partitioner类型 OrderPreservingPartitioner 如果要支持针对Key的范围查询，那么可以选择这种有序分区策略。该策略采用的是字符串类型的Token。 如果没有指定InitialToken，则系统会使用一个长度为16的随机字符串作为Token，字符串包含大小写字符和数字。

26. Partitioner类型

27. Partitioner类型 ByteOrderedPartitioner 和OrderPreservingPartitioner一样是有序分区策略。只是排序的方式不一样，采用的是字节型Token。

28. Partitioner类型

29. Partitioner类型 CollatingOrderPreservingPartitioner 和OrderPreservingPartitioner一样是有序分区策略。只是排序的方式不一样，采用的是字节型Token。支持设置不同语言环境的排序方式，代码中默认是en_US。 将制定的Token信息按照不同语言环境来编组转化为字节数组。 其它与ByteOrderedPartitioner完全一致。

30. 副本策略 LocalStrategy：只在本地节点中保持一个副本。 RackUnawareStrategy：不考虑机柜因素，将Token按照从小到大的顺序，从第一个Token位置处依次取N个节点作为副本。 RackAwareStrategy：考虑机柜因素，在primaryToken之外，先找一个处于不同数据中心的点，然后在不同机柜找。

31. 副本策略 LocalStrategy：只在本地节点中保持一个副本。 RackUnawareStrategy：不考虑机柜因素，将Token按照从小到大的顺序，从第一个Token位置处依次取N个节点作为副本。 RackAwareStrategy：考虑机柜因素，在primaryToken之外，先找一个处于不同数据中心的点，然后在不同机柜找。

32. 副本策略 LocalStrategy：只在本地节点中保持一个副本。 RackUnawareStrategy：不考虑机柜因素，将Token按照从小到大的顺序，从第一个Token位置处依次取N个节点作为副本。 RackAwareStrategy：考虑机柜因素，在primaryToken之外，先找一个处于不同数据中心的点，然后在不同机柜找。

33. 副本策略 DatacenterShardStategy：这需要复制策略属性文件，在该文件中定义在每个数据中心的副本数量。在各数据中心副本数量的总和应等于Keyspace的副本数量。 举例来说，如果Keyspace的副本总数是6，数据中心副本因子可能是3、2和1 ，3个副本、2个副本、1个副本分别在不同数据中心 - 共计6。

34. 副本策略 Cassandra-rack.properties # Cassandra Node IP=Data Center:Rack 192.168.1.200=DC1:RAC1 192.168.2.300=DC2:RAC2 10.0.0.10=DC1:RAC1 10.0.0.11=DC1:RAC1 10.0.0.12=DC1:RAC2 10.20.114.10=DC2:RAC1 10.20.114.11=DC2:RAC1 10.21.119.13=DC3:RAC1 10.21.119.10=DC3:RAC1 10.0.0.13=DC1:RAC2 10.21.119.14=DC3:RAC2 10.20.114.15=DC2:RAC2 # default for unknown nodes default=DC1:r1

35. Agenda 基础知识 数据模型 数据分布策略 存储机制 数据读写删 最终一致性 Gossiper 面向未来

36. 存储机制 Storage Model Memtable SSTable Commitlog Compaction

37. Storage Model

38. Memtable/SSTable 数据先写入内存中的Memtable，写入关键路径上不需要持有任何锁，Memtable达到条件后刷新到磁盘，保存为SSTable，SSTable不可修改 Memtable刷新到磁盘的三个条件

39. Memtable/SSTable 同一个CF的多个SSTable可以合并(Compaction)以优化读操作 通过布隆过滤算法(Bloom Filter)减少对不可能包含查询key的SSTable的读取。 将随机写转变为顺序写，提升系统写性能。

40. Memtable/SSTable SSTable包含对应的三种文件 Datafile 按照Key排序顺序保存的数据文件 文件名称格式如下：ColumnFamilyName-序号-Data.db Indexfile 保存每个Key在Datafile中的位置偏移 文件名称格式如下： ColumnFamilyName-序号-Filter.db Filterfile 保存BloomFilter的Key查找树 文件名称格式如下： ColumnFamilyName-序号-index.db

41. Commitlog Commitlog是server级别的，不是Column Family级别的，每一个节点上的Commitlog都是统一管理。 每个Commitlog文件的大小是固定的，称之为一个CommitlogSegment，目前版本(0.7.0)中，这个大小是128MB，硬编码在代码中。 当一个Commitlog文件写满以后，会新建一个的文件。 SSTable持久后不可变更，故Commitlog只用于Memtable的恢复，相当于Oracle的Instance Recovery。Cassandra不需要做Media Recover 当节点异常重启后，将根据SSTable和Commitlog进行实例恢复，在内存中重新恢复出宕机前的Memtable。 当一个Commitlog文件对应的所有CF的Memtable都刷新到磁盘后，该Commitlog就不再需要，系统会自动清除。

42. Commitlog 每个Commitlog文件(CommitlogSegment)都有一个CommitlogHeader，紧随其后则是序列化之后的变更的RowMutation对象。 Key是在Memtable中存在更新的CF_ID Value保存的是Column Family在上一次Flush时日志的偏移位置，恢复时则可以从这个位置读取Commitlog记录。

43. Commitlog Commitlog刷新有两种机制： Batch：当CommitlogSegment刷新到磁盘后，插入Memtable操作才可继续。并且需要等待CommitLogSyncBatchWindowInMS毫秒（默认值1，建议0.1~10）内的其他写操作一起批量刷日志到磁盘。可以类比为Oracle的batch/wait模式。 Periodic ：每隔CommitLogSyncPeriodInMS毫秒（默认值10000）性刷新CommitlogSegment，不阻塞数据写操作，可以类比为Oracle的batch/nowait模式。

44. Compaction

45. Compaction 一个CF可能有很多SSTable，系统会将多个SSTable合并排序后保存为一个新的SSTable，称之为Compaction。 一次compaction最多请求合并32个SSTable，最少4个。超过32个则按时间排序分批进行（这两个阈值可以设置）。 如果空间不足，则尝试去掉最大的SSTable再合并，如果连合并两个最小的SSTable的空间都不足，则告警。 Major Comaction：合并CF的所有SSTable为一个新的SSTable，同时执行垃圾数据(已标记删除的数据tombstone)清理。 Minor Compaction：只合并大小差不多的SSTable，超过4个需要合并的SSTable就会自动触发。 可通过nodetool compact命令手动触发。 数据目录最好保持50%以上的可用空间。

46. Compaction Compaction将旧的SSTable的记录按序写入到新的名字包含tmp的SSTable，完成后重命名去掉tmp，切换到新文件后，再将原SSTable删除。 可以通过设置Compaction的minthreshold(默认4)和maxthreshold(默认32)来改变触发一次Comaction合并的最少SSTable数和最多SSTable数。 如果设置minthreshold=0或者maxthreshold=0，则会禁止系统自动执行Minor Compaction。建议在业务高峰期禁止Compaction，定期到业务低峰期通过nodetool compact手工执行Major Compaction。 以上两个参数可以通过nodetool设置： Nodetoolsetcompactionthreshold[minthreshold] ([maxthreshold])

47. Agenda 基础知识 数据模型 数据分布策略 存储机制 数据读写删 最终一致性 Gossiper 面向未来

48. 数据读写删 Quorum NRW Read Write ConsistencyLevel Delete

49. Quorum NRW N: 复制的节点数量 R: 成功读操作的最小节点数 W: 成功写操作的最小节点数

50. Read

51. Read

52. Write

53. ConsistencyLevel(Write)

54. ConsistencyLevel(Read)

55. Delete 分布式删除存在的问题？ 一个删除操作不可能一下子就将被删除的数据立即删除掉：如果客户端执行一个删除操作，并且有一个副本还没有收到这个删除操作，这个时候这个副本依然是可用的，此外，该节点还认为那些已经执行删除操作的节点丢失了一个更新操作，它还要去修复这些节点。

56. Delete Cassandra中是怎么做的？ 不会去直接删除数据，Cassandra使用一个被称为墓碑的值。这个墓碑可以被传播到那些丢失了初始删除请求的节点。让每一个节点跟踪本地数据的墓碑值年龄。 常量GCGraceSeconds，默认为10天。 一旦数据持有的墓碑值的年龄超过这个常量，它将进行收集。

57. Delete 什么时候才真正被删除掉呢？ 我们在使用客户端从Cassandra中读取数据的时候，节点在返回数据之前都会主动检查是否该数据被设置了删除标志，并且该删除标志的添加时长已经大于GCGraceSeconds，则要先删除该节点的数据再返回。

58. Agenda 基础知识 数据模型 数据分布策略 存储机制 数据读写删 最终一致性 Gossiper 面向未来

59. 最终一致性 Hinted Handoff（提示移交） Read Repair（读修复） Anti Entropy（逆熵）

60. Hinted Handoff Key A按照规则首要写入节点为N1，复制到N2 假如N1宕机，如果写入N2能满足ConsistencyLevel要求，则Key A对应的RowMutation将封装一个带hint信息的头部（包含了目标为N1的信息），然后随机写入一个节点N3，此副本不可读。同时正常复制一份数据到N2，此副本可以提供读。如果写N2不满足写一致性要求，则写会失败。 N1恢复后，原本应该写入N1的带hint头的信息将重新写回N1。 HintedHandoff是实现最终一致性的一个优化措施，可以减少最终一致的时间窗口。

61. Read Repair 读取Key A的数据时，系统会读取Key A的所有数据副本，如果发现有不一致，则进行一致性修复。 如果读一致性要求为ONE，会立即返回离客户端最近的一份数据副本。然后会在后台执行Read Repair。这意味着第一次读取到的数据可能不是最新的数据。 如果读一致性要求为QUORUM，则会在读取超过半数的一致性的副本后返回一份副本给客户端，剩余节点的一致性检查和修复则在后台执行。 如果读一致性要求高(ALL)，则只有Read Repair完成后才能返回一致性的一份数据副本给客户端。 该机制有利于减少最终一致的时间窗口。

62. Anti Entropy

63. Anti Entropy 数据的最终一致性由AntiEntropy（逆熵）所生成的MerkleTrees对比来发现数据复制的不一致，通过org.apache.cassandra.streaming来进行完整的一致性修复。 Merkle Tree是一种Hash Tree，叶子节点是Key的hash值，父节点是所有子节点值的hash值，通过判断父节点的异同可以知道所有子节点的异同。 通过判断root的异同可以快速判断所有叶子节点数据的异同。 执行nodetool repair可以启动Anti-Entropy，此操作需要扫描所有数据，对系统的IO有较大压力，建议在业务低峰期定期执行。

64. Agenda 基础知识 数据模型 数据分布策略 存储机制 数据读写删 最终一致性 Gossiper 面向未来

65. Gossip的作用 Cassandra集群没有中心节点，各个节点的地位完全相同，它们通过一种叫做gossip的协议维护集群的状态。 通过gossip，每个节点都能知道集群中包含哪些节点，以及这些节点的状态，这使得Cassandra集群中的任何一个节点都可以完成任意key的路由，任意一个节点不可用都不会造成灾难性的后果。

66. Gossip协议 gossip的学名叫做Anti-entropy（逆熵？），比较适合在没有很高一致性要求的场景中用作同步信息。信息达到同步的时间大概是log(N)，这里N表示节点的数量。 gossip有两种形式：anti-entropy和rumor-mongering。 gossip中的每个节点维护一组状态，状态可以用一个key/value对表示，还附带一个版本号，版本号大的为更新的状态。 消息的处理有3种方式，Cassandra采用第三种方式——Push-pull-gossip

67. Gossip消息如何如何发送 当一个节点启动时，获取配置文件（cassandra.yaml）中的seeds配置，从而知道集群中所有的seed节点。 Cassandra内部有一个Gossiper，每隔一秒运行一次（在Gossiper.java的start方法中），按照以下规则向其他节点发送同步消息： 1、随机取一个当前活着的节点，并向它发送同步请求 2、向随机一台不可达的机器发送同步请求 3、如果第一步中所选择的节点不是seed，或者当前活着的节点数少 于seed数，则向随意一台seed发送同步请求

68. Gossip消息如何如何发送 如果没有这个判断，考虑这样一种场景，有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通信，从而打破这个孤岛。

69. 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 一个节点自身的状态只能由自己修改，其他节点的状态只能通过同步更新。

70. Gossip状态信息有哪些 负载信息（LOAD-INFORMATION） 迁移信息（MIGRATION） 节点状态信息（MOVE） BOOT（启动阶段）节点正在启动 NORMAL（正常）节点加入了Token的ring，可以提供读 LEAVING，节点准备离开Ring LEFT，节点被踢出集群或者是Token信息被手工变更

71. Gossip消息同步过程

72. Gossip消息同步实例 （1）Node 10.0.0.1(endPointStateMap):

73. Gossip消息同步实例 （2）Node 10.0.0.2(endPointStateMap):

74. Gossip消息同步实例 GossipDigestSynMessage （节点10.0.0.1）: 10.0.0.1:1259909635:325 10.0.0.2:1259911052:61 10.0.0.3:1259912238:5 10.0.0.4:1259912942:18 （节点10.0.0.2）: 10.0.0.1:1259909635:324 10.0.0.2:1259911052:63 10.0.0.3:1259812143:2142 GossipDigestAckMessage （节点10.0.0.2）: 10.0.0.1:1259909635:324 10.0.0.3:1259912238:0 10.0.0.4:1259912942:0 10.0.0.2: [ApplicationState "normal": AujDMftpyUvebtnn, generation 1259911052, version 62], [HeartBeatState, generation 1259911052, version 63]

75. Gossip消息同步实例 GossipDigestAck2Message（节点10.0.0.1）: 10.0.0.1: HeartBeatState: generation 1259909635, version 325 ApplicationState "load-information": 5.2, generation 1259909635, version 45 ApplicationState "bootstrapping": bxLpassF3XD8Kyks, generation 1259909635, version 56 ApplicationState "normal": bxLpassF3XD8Kyks, generation 1259909635, version 87 10.0.0.3: HeartBeatState: generation 1259912238, version 5 ApplicationState "load-information": 12.0, generation 1259912238, version 3 10.0.0.4: HeartBeatState: generation 1259912942, version 18 ApplicationState "load-information": 6.7, generation 1259912942, version 3 ApplicationState "normal": bj05IVc0lvRXw2xH, generation 1259912942, version 7

76. Agenda 基础知识 数据模型 数据分布策略 存储机制 数据读写删 最终一致性 Gossiper 面向未来

77. Twitter放弃Cassandra 1. Cassandra仍然缺少大并发海量数据访问的案例及经验，Cassandra来源自Facebook，但是在Facebook内部Cassandra目前只用在inbox search产品上，容量大约有100-200T。且Inbox Search在Facebook的基础架构中也并非核心应用。 2. 新产品需要一定稳定期，Cassandra代码或许还存在不少问题，但是Twitter如果投入大量的精力来改进Cassandra和比较优化MySQL的投入来看有点得不偿失。

78. Flowdock转向MongoDB 稳定性问题 所有的节点都陷入无限循环(infinite loop)，运行垃圾回收工作(GC， Garbage Collection)并尝试压缩数据文件——并偶尔导致集群瘫痪。除了对集群进行重启并经常性的手工对节点做压缩工作以让其稳定一会外，无计可施。其他人也报告过类似的问题。在前面几周的时间里，我们的Cassandra节点总是会吃掉给他分配的所有资源，而导致Flowdock运行缓慢。 运维问题 从Cassandra 0.4升级到0.5的时候，我们被迫关闭了整个集群，仅仅是为了将所有的数据刷新到磁盘上(虽然，我们已经按照文档进行了手工刷新的操作)。这个操作导致我们丢失了几分钟的讨论内容，以及我们手工创建的索引出现严重的不一致，以致于需要做完全的重建。

79. Nosql支持率调查报告

80. Performance improve

81. 路还很长……

82. Thanks！