活动精彩实录|Cassandra在360的最新进展（二）

针对上面这个设计我们也需要更改我们的数据副本分布策略。

默认的副本分布策略是SimpleStrategy，也就是说三副本的情况是往环里的下面两个节点顺延来存储另外两个副本。

我们设计里的Chunk表需要采取一个新的副本分布策略，因为我们需要保证Chunk表里10+4的所有块最大限度的分布到尽可能多的节点里，所以我们新增了一个条带化的副本分布策略，如上图所示。

我们的Key Meta还是使用普通的副本存储策略，因为这个元数据是非常重要的，如果它丢了，那就代表整个key下面的数据都丢掉了。所以元数据还是使用Simple的副本分布策略。

针对我们刚才提到的加入EC纠删码以后，我们需要更改我们数据读写的路径，以及加入两个新的扩展表，我们在读取的路径下做了一些修改，并且针对于它的数据修复做了一个定制化的读修复的功能。

每次需要读一个key的时候，先去读取它的元信息，拿到它的所有Chunk的数据块的信息。如果所有的数据块都是健康的，我们会在协调者节点上直接把数据拼装好了以后直接发送给我们的客户端。

如果发现有数据块是丢失的，我们会去读取我们的EC校验块，再加上我们原有的数据块进行一个EC的反解码，拿到最终的数据，把这部分的数据直接返回给我们的客户端。

另一部分因为发现有数据缺失，我们会在系统表里（System Keyspace里我们创建了一张默认的系统表）记录我们丢失的数据块的信息。

为什么要加这张表？因为我们有数据块丢失发生的时候往往是这个数据块的节点已经挂掉了。这时如果我们把这个信息存到这样的本地表里，不管对方的节点是不是还是存活的，再由一个repair task异步的去消费这个表里的数据，如果那个节点还是挂掉的，我们这个表里的数据不会删。

如果节点是健康的状态的话，相当于我们发送了写请求把这个修回来了之后，对应的我们会清除本地表的内容。这样可以做到读取过程中的读修复。

我们还针对这个EC功能加了一个异步删除的功能。也就是说我们在写入一条删除请求的时候，相当于也是写入了一条Delete的标志。

所以我们在截取到Delete标志的时候，会在协调者节点读取我们的元信息，然后同步地标记删除元信息，同时也会开一个异步的线程池一点一点地标记Chunk信息的删除。下次读取的时候只要元信息已经被标记删除了，就会正常返回删除。

这张slide继续说明我们针对成本节约的另一个改进。

我们这种对象存储的场景，有些用户会使用删除的请求。

Cassandra默认的是在SSTable层面把正常的数据和删除的数据混合的，如果我们要释放数据空间的话，需要对这些SSTable做Compaction才能真正的删除，这样并不能做到一个精准的删除。

在用户删除无规律的情况，怎样能性价比更高的精准删除，释放空间呢？

我们改了Cassandra做Flush memtable的过程，在里面加了一个迭代器，对每一个row都做DeletionTime.isLive()判断。如果这个row是带删除标记的数据，就flush到delFile SSTable里；如果是普通的数据，就flush到正常的SSTable里。

这样可以把带删除标记的数据和正常数据分开，在做compaction的时候就可以非常精准的释放空间。

Compaction里面是这样做的：首先我们挑一些DelFile SSTable出来，每个DelFile SSTable也会有一个StartKey以及EndKey，我们根据这个范围在正常的SSTable扫描看看有没有交集，把有交集的SSTable筛选出来。

然后确认DelFile的Rowkey也在这些筛选出来的SSTable里，形成SSTable的列表，把这些SSTable和我们的DelFile做一次Compaction，这样可以精准的释放我们删除的空间，形成新的SSTable。

这里我们对数据的可靠性做了二次开发，也就是摘盘自愈的功能。

一个存储系统避免不了出现坏盘的问题。如何处理坏盘丢数据的问题呢？

大家知道Cassandra自带有一些修复功能：Hinted Handoff, Read Repair读修复, Anti-Entropy Node Repair反熵修复。但是对于我们这样重IO的场景，反熵修复的开销也是非常大的，所以我们一般也不会去开启反熵修复。

这里Cassandra的主要问题，是并不能自主的知道哪些数据丢失了，比如我们有一个坏盘，它并不知道哪些数据丢失了，它需要一个精准的方式知道哪些范围的数据丢失。

Cassandra在检测到IO Exception（比如有坏盘）的时候，默认的机制是STOP，也就是进入一个对客户端和其他节点看来都是挂掉的状态。同时它会把BadDataDir加入到一个黑名单BlackList里面，这样后续和IO相关的一些操作（比如Flush memtable）就会避免这个目录。

我们在这个加入Blacklist的地方做了一些二次开发。

首先我们对IOException加了一个引用的计数。比如说，我们有十块盘，如果盘1出现了十次IOException，我们会把它标记为一个不可用的状态，把它加入黑名单。

然后我们会去通过一个Hook去扫SSTableTracker（这是Cassandra内部的一个数据结构，用来存储CF下面都有哪些SSTable）中属于坏盘数据目录下面的SSTable，并且把这些SSTable对应的Keyspace、CF以及token范围加到一个叫SSTableLost的系统表里。

后面会有一个异步的RepairTask对这些范围做修复。

有了这个实现，就解放了我们的一些运维的压力。因为出现了坏盘以后，不用运维去特别快速的修复，因为系统有自动修复的能力。

---未完待续---

本文版权归DataStax所有

未经书面允许禁止转载