Cassandra实战阅读记录，cassandra实战阅读
1.thrift中Cassandra的数据类型
1.1 Column ：{name：key，value：value，timestamp：long}
1.2 SuperColumn {name ：key ，value：{column 1，...，column n} }
1.3 ColumnOrSuperColumn{optional}
1.4 ColumnParent 可以理解问文件系统中对应的一个目录,需要指定{CF,[superColumn]}
1.5 ColumnPath 文件系统中对应的一个文件 指定 {CF,[superColumn][column]}
....不在一一列举
2 编程接口
get 获取key对应的Column或者SuperColumn 指定{KeySpace,key,(ColumnPath)==(CF,[SuperColumn],[Column])}
3.一致性哈希
3.1 求出集群中每一个结点的hash值，并映射到0~2**32的圆环上
3.2 求出存储数据的hash，映射到圆环上
3.3 从映射位置开始顺序查找，将数据保存到找到的第一个服务器上
3.4 超过2**32仍然找不到相应服务器，则保存到第一个服务器上
最大限度的限制了key的重新分布
虚拟结点的思想：每个server分配100~200个点
4.一致性哈希在Cassandra的应用
4.1 Token
4.1.1每个节点对应一个Token，相当于圆环中的一个节点地址
4.1.2 4种实现 BigIntegerToken BytesToken ，LocalToken，StringToken
4.2 Range
4.2.1每个节点负责处理的数据在圆环中对应的位置
4.2.2 自己为right，逆时针第一个为left 则Range = （left，right]
4.3 Partitioner
4.3.1 管理token在圆环中的生成规则
4.3.2 每个Cassandra实例只能指定一个partitioner
4.3.3 5种实现 （略）
5.Gossip
5.1 Failure Detector （失效节点检验）
5.1.1 记录摸个节点与本节点通信的历史，然后根据当前时间和某个节点的通信历史判断一个节点是否存活
5.2 Gossiper
每个节点都能获取到集群中包含哪些节点，以及节点的状态
每个节点都能完成任意读取和写入操作，if 本机，处理 else 转发合适节点
5.2.1 gossip 初始化
构造4个集合 1,liveEndPoints 2，unreachableEndpoints 3，seeds 4，endpoint-stateMap
5.2.2 启动 从配置文件中load seeds的信息，然后启动一个GossipTask的定时任务，每1s执行一次
5.3 GossipTask
5.3.1 首先更新本节点心跳版本号，构造要发送给其他节点的Gossip Digest Syn Message
5.3.2 讲Gossip Digest Syn Message 发送给合适的结点，
5.3.3 通过调用Failure Detector 的interpret 检查集群中是否有失效的结点
5.4 发送给合适的结点
5.5 接收到 GossipDigestSynMessage 的节点
5.5.1 GossipDigestSynMessage 包含的信息
节点地址，心跳版本号，状态版本号
5.5.2
1） 根据GossipDigest集合，调用FailureDetector的report方法跟新节点状态
2） 对GossipDigest集合进行排序
3） 对比接收到的GossipDigest和自己的GossipDigest的差异，
本节点需要继续获取的节点信息由deltaGossipDigest保存，
本节点需要告诉发送节点的信息由deltaEpGossipDigest保存
4） 利用deltaGossipDigest 和deltaEpGossipDigest构建 GossipDigestAckMessage消息，并发给发送节点
5.6 接收到 GossipDigestAckMessage
5.6.1
1） 跟新本地节点信息，并调用FailureDetector 的report跟新集群中节点状态
2） 上面的那个节点所需要的信息构造GossipDigestAck2Message
3） 将上面的Ack2发送给上面的那个节点
5.7 GossipDigestAck2Message
更新本地节点信息，并调用Failure的report 方法更新节点状态
6.备份机制
6.1 EndPointSnitch （机架感应）
找到自己属于那个数据中心和同一个机架
4中方法 略
6.2 ReplicationStrategy
6.2.1 Simple Strategy ：圆环中顺时针找
6.2.2 OldNetworkTopologyStrategy :顺时针，第二个与第一个不在同一个机架，第三个与第二个不在一个数据中心
6.2.3 NetworkTopologyStrategy ：指定在数据中心中的备份数量
7.数据存放规则
7.1 data目录
真正的数据文件 即SSTable
7.2 commitlog
存储未写入SSTable的数据，保证宕机后数据不会丢失
7.2.1 由 log 和 log.header 组成
log （每次更新操作的值）
log.header（记录了从MemTable写入SSTable的数据）
7.2.2 记录Commitlog的两种方式
1）periodic 周期记录
每次更新都记录进去Commitlog，可以保证数据不丢失
2）batch 批量记录
先将每次更新缓存，然后再写入commitlog
7.3 cache
存储系统中的缓存数据
8.Memtable
数据写入commitlog后，将缓存到MemTable中
Cassandra中每一个MemTable只为一个ColumnFamily服务
8.1 写入SSTable的条件
1）MemTable中缓存达上限
2）MemTable中数据条数超上限
3）距离上次写入超过某个间隔
8.2 优势
将随机IO写变为顺序IO写
8.3 Cassandra将MemTable持久化为SSTable的时候，将构造一个SSTableWriter
MemTable --> SSTableWriter -->SSTable
9.SSTable
9.1ColumnFamily 为 Cf1的一个SSTable 由如下文件组成
e是版本的标识 1代表Cf1是ColumnFamily的第一个SSTable，会不断增加
1）Cf1 -e - 1 - Data.db
保存3类信息：key ， ColumnIndex（Bloom Filter 和Index） ，ColumnValue
读取Data中的Key的某个Column的时候，ColumnIndex的BloomFilter去看有没有，然后根据Index去查找
而且这里的Index仅仅对Standard ColumnFamily有效
key对应的superColumn有很多的Column ，Cassandra只会对superColumn建索引，
要遍历Column才能找到合适的值
生成：
在初始化SSTable的实例的时候，会构造一个BufferedRandomAccessFile（dataFile）实例
在写入的时候，dataFile将数据写入磁盘，形成Data文件
2）Cf1 -e - 1 - Filter.db
作用：
快速定位一个Key是否在SSTable中（Bloom Filter）
生成：
初始化SSTable实例的时候，也会构造一个BloomFilter的实例，
在写入SSTable的过程中，也会将数据传入BloomFilter中，产生缓存位数组filter_
然后写入到磁盘中，形成Filter文件
同时，构建出来的filter_也会一直保存在内存中，用于快速判断key是否存在
3）Cf1 -e - 1 - Index.db
作用：
若key存在，在Index文件中找到key对应的Column值在Data文件中的具体位置
Index文件中保存 key值 和key值在Data文件中的位置
所以要找key的位置只要顺序去扫描Index文件就可以了
优化:
Index 中key是由小到大顺序写的
将key 以及key在Index文件中的位置按照某个间距放入内存中
二分查找，找到key对应的区间，扫描这个区间就可以了
生成：
初始化SSTable的时候会构造一个IndexWriter
在写入SSTable的时候会将数据传给IndexWriter,并构建自己的内存缓存 summary
将IndexWirter中的数据写入磁盘，形成Index文件
summary将存于内存，加速查找
keyCache：
缓存上一次查找的key在Data中的位置
4）Cf1 -e - 1 -Statistics.db
作用：
Column的个数以及Row的大小
在生成SSTable文件的时候产生的
10.系统表空间 system keyspace
只能系统自己创建
1）管理Cassandra的系统元数据信息
2）缓存HINT数据
某个节点宕机，会把发送给此节点的数据以HINT的形式发送给另外 一台Cassandra服务器
接收到HINT数据的server会将数据缓存到系统表空间中
宕机节点恢复后，将缓存的HINT发送给恢复的节点
传输完成，删除HINT
11.集群数据更新策略
ANY ：任意一个server写入成功（包括HINT）
ONE：任意一个server写入成功（不包括HINT）
QUORUM ，LOCAL_QUORUM，EACH_QUORUM，ALL
跟备份策略有一定关系
12 .二级索引
没看懂，感觉是对Column中的某个字段建索引，增加了空间的消耗
13.数据读流程
13.1 Cassandra会为每一个ColumnFamily生成一个或者多个SSTable
读MemTable以及SSTable，合并产生结果
13.2 Cassandra存储是面向列的，可以一个key所要查询的结果存在3个不同的SSTable中
13.3 弱读取（Weak Read）
一致性级别为ONE
13.4 强读取（StrongRead）
13.5 读修复
可以设置读修复的概率
13.6 数据缓存
1）两类缓存 RowCache 和 KeyCache
RowCache 缓存读取的列的信息
KeyCache缓存的是key在SSTable中的位置
2）Cassandra为每个ColumnFamily单独配置缓存个数
14 数据压缩
Cassandra中的数据压缩 是同步进行的
14.1 控制压缩
min_compaction_threshold ：>=这个min的时候，可以进行压缩了
max_compaction_threshold：每次最多合并的SSTable的个数
任意一个为0 ，则不会主动去压缩
14.2 压缩流程如图
14.3维护Cassandra中的数据
1）数据清理压缩
新节点加入，旧节点退出，某些节点宕机，某个server的SSTable会存不属于它的数据
2）数据一致性校验
检测多个节点上的数据是否一致
15 .Cassandra启动流程
15.1 根据log4j的配置初始化
15.2 读取校验配置文件信息
从system 表中获取集群名称(Cluster Name),和分区器（Partitioner）
若与配置文件中信息不一致，则不予启动
15.3 加载所有的数据文件
1）针对每个keyspace，删除临时的，不完整的，成功执行的数据压缩文件
2）加载keyspace中的Filter，Index，缓存文件，获取二级索引
15.4 修复数据
1）读取Commitlog，恢复没有持久化到SSTable中的数据
2）根据数据压缩规则，若CF下面的SSTable的数量过多，则压缩
3）应用变更元数据信息，保证本server的元数据信息与其他的服务器一致
15.5 启动Gossiper服务
加载配置文件中的seeds信息和系统中的集群节点信息
启动GossipTask，开始集群的消息传播
15.6 判断是否Bootstrap
当心的服务器加入到集群的时候，可以执行这个bootstrap
可以指定token，留空则有partitoner计算
条件：
1）配置文件中auto_bootstrap 的值为true
2）该服务器没有进行过bootstrap操作，这个是记录在system的表中的，想再次进行智能删除系统表
3）本server不在seed中
15.7 监听Thrift端口，提供thrift服务
16 .分布式环境中搭建与使用Cassandra
主要我觉得是修改seed字段
启动seeds中的节点的时候，会看到已经Up的节点的信息
16.1查看集群运行状况：
nodetool -h host -p port ring
查看某个节点状态：
nodetool -h host -p port info
16.2添加节点：
aotu_bootstrap：true
seeds字段一样
配置文件都一样
当不在seeds中的server启动的时候，会执行bootstrap操作
使用nodetool -h host -p port ring 查看是否加入成功
16.3删除节点：
nodetool -h host -p port decommission
-h 后面接的是要被删除的server
可以杀进程
nodetool -h host -p port removetoken token
移动节点：
相当于在集群中删除需要移动的节点，然后再对删除的节点bootstrap
nodetool -h host -p port move token值
移动到token值得地方
json和SStable的数据相互转换