Apache Cassandra架构理解

架构

基本流程: 点对点分布式系统，集群中各节点平等，数据分布于集群中各节点，各节点间每秒交换一次信息。

每个节点的commit log提交日志捕获写操作来确保数据持久性。

数据先被写入MemTable(内存中的数据结构)，待MemTable满后数据被写入SSTable(硬盘的数据文件)。

所有的写内容被自动在集群中partition分区并replicate复制。

库表结构: Cassandra数据库面向行。用户可连接至集群的任意节点，通过类似SQL的CQL查询数据。

集群中，一个应用一般包含一个keyspace，一个keyspace中包含多个表。

读写请求: 客户端连接到某一节点发起读或写请求时，该节点充当客户端应用与拥有相应数据的节点间的

coordinator协调者以根据集群配置确定环(ring)中的哪个节点应当获取这个请求。

CQL是客户端,Driver也是一种客户端. 使用CQL连接指定的-h节点就是协调节点.

图解: 协调节点(10)负责和客户端的交互.真正的数据在节点1,4,6上,分别表示数据的三个副本,最终只要节点1上的数据返回即可.

关键词

节点间通信gossip

Cassandra使用点对点通讯协议gossip在集群中的节点间交换位置和状态信息。

gossip进程每秒运行一次，与至多3个其他节点交换信息，这样所有节点可很快了解集群中的其他节点信息

gossip协议的具体表现形式就是配置文件中的seeds种子节点. 一个注意点是同一个集群的所有节点的种子节点应该一致.

否则如果种子节点不一致, 有时候会出现集群分裂, 即会出现两个集群. 一般先启动种子节点,尽早发现集群中的其他节点.

每个节点都和其他节点交换信息, 由于随机和概率,一定会穷举出集群的所有节点.同时每个节点都会保存集群中的所有其他节点.

这样随便连到哪一个节点,都能知道集群中的所有其他节点. 比如cql随便连接集群的一个节点,都能获取集群所有节点的状态.

也就是说任何一个节点关于集群中的节点信息的状态都应该是一致的!

失败检测与恢复

●gossip可检测其他节点是否正常以避免将请求路由至不可达或者性能差的节点(后者需配置为dynamic snitch方可)。

●可通过配置phi_convict_threshold来调整失败检测的敏感度。

●对于失败的节点，其他节点会通过gossip定期与之联系以查看是否恢复而非简单将之移除。若需强制添加或移除集群中节点需使用nodetool工具。

●一旦某节点被标记为失败，其错过的写操作会有其他replicas存储一段时间. (需开启hinted handoff，若节点失败的时间超过了max_hint_window_in_ms，错过的写不再被存储). Down掉的节点经过一段时间恢复后需执行repair操作，一般在所有节点运行nodetool repair以确保数据一致。

dynamic snitch特性: 查询请求路由到某个节点,如果这个节点当掉或者响应慢,则应该能够查询其他节点上的副本

删除节点: 节点失败后,仍然在集群中,通过removenode可以将节点从集群中下线.区别就是status如果不存在就说明下线了. DN则仍然在集群中.

失败节点数据: 数据无法正常存储到失败的节点,所以会由其他节点暂时保存,等它恢复之后,再将错过的写补充上去.

一致性哈希DHT