CKV+异地容灾探索和实践

2016年亚马逊的CTO发表了一篇文章，总结了过去十年亚马逊云服务的经验教训，其中第二点就讲到接受一切的故障，“故障总是意料之外，情理之中发生”。确实是这样子，在过去几年，CKV+也出现过包括主机故障、磁盘写满、流量突发、机房网络中断等方面引起的一些故障。在故障层面，涉及主机级、机架级，可用区级，以及机房级等都各种各样不同的故障。对于城市级的故障，印象比较深的是，在2015年，天津机房附近的天津滨海新区危险品仓库发生大爆炸，导致天津数据中心岌岌可及，大量业务需要做迁移。所以，故障总是不可预料的，但不管是天灾还是人祸，需要我们是要对不同的容灾级别做一些处理，这也是今天我们主要讨论的内容。

CKV+作为一个内容数据库，在容灾级别的探索上，数据可用性和一致性需要做怎么样的考虑或取舍，有几个点我们必须要先考虑的。第一，数据如何分布；第二，数据同步算法；第三，读写分离/异地多活等如何考虑？

大家都知道，CAP理论包含一致性、可用性和分区容忍性，这三点不能完全满足，只能同时满足其中两项。现有系统可能会区分为一个CA，或者AP，或者CP等。对于分布式系统来说，数据一定是分布式存储的，因此“分区容忍性”这一点是必须要满足。数据分布算法一般有hash算法，一致性hash，基于范围，以及hash+范围混合算法。hash和范围混合算法是将数据通过hash算法拆分为足够多的分片（编号0~n)，每一个node负责一段连续的区间，是比较常用的分布算法，例如redis-cluster。ckv+也同样使用这种算法进行数据分布式分布。

在数据可用性和一致性上，CKV在默认的情况下，主要考虑性能，跟redis类似，使用类似的异步复制算法。在master故障的时候，slave可能无法保证数据跟master完全一致(可能丢失最近的一段日志)，无法保证故障场景的强一致性，属于一个AP系统。但现在主流的NoSQL数据库，如dynamoDB，MongoDB，Cassandra等，支持可调一致性，既支持AP场景，也支持CP场景。因此，对于一些客户来说，也是希望CKV+也能够在高性能上做一些取舍，损失一定性能，支持强一致性能力。所以，我们在未来架构演进过程中，需要考虑如何实现多种一致性来满足不同用户的要求，同时也考虑不同的容灾级别。

从以上图示看，对比于原架构，新架构有以下特点：

1. 新增日志模块，实现数据和日志的解耦。将日志模块独立成一个服务，并且是基于raft的强一致日志存储。Node节点主要关心核心数据操作流程，增量日志只需通过RPC调用同步到日志服务即可，无需关心日志的持久化和同步问题，日志服务会自动解决这些问题。

2. 故障处理更简单。每一个分片会组建一个raft group，Node的主分片无需处理replication，只需向对应的raft group提交增量日志即可，备分片会作为raft group的learner。当主分片发生故障，备分片只需保证将raft log执行完毕，就可以提升为master。当日志模块的master或着备分片发生故障，备分片基于raft算法能自动选主并且同步日志，解决故障或者网络瞬断等情况的复制异常问题。这样都可以简化整体故障处理流程，同时能保证数据不丢失。

3. 成本控制更灵活。日志模块独立出来后，可以使用更灵活的机型，例如一些ssd类型的机型（内存较少，磁盘空间较大），成本更低。同时，日志模块能存储更多的日志，实现强一致性和持久化能力。并且数据模块和日志模块的副本数可以不一样，例如Node一主一备，日志模块一主两备，结合不同可用区/城市的部署关系，能够更灵活的控制整体成本。

4. 其他高级特性更容易实现。得益于CKV+日志的解耦，理论上可以支持获取任意时刻的日志。例如PITR(Piont-in-Time Recovery)，Change Data Capture等就比较容易实现了。同样的，异地多活也可以基于这个架构进行扩展，下面会详细描述。

CKV+为了满足不同的容灾要求，已上线了单活多可用区特性，支持不同容灾级别：

• 单可用区：机架级容灾能力。

• 同地域多可用区：机架、可用区级容灾能力。

• 跨地域多可用区：跨城际容灾。

默认的情况下，CKV+的容灾级别是跨机架容灾，保证主备分片必须跨机架，避免一个机架掉电导致主备分片都不可用的问题。如果希望更高的容灾级别，可以选择同地域多可用区以及跨地域多可用区，当然这样可能导致的访问和主备延时会更大。在不同的级别上，容灾对于性能和成本其实是一个很微妙的关系。如果你需要更高的容灾级别，那么可能就需要牺牲一点性能和提高一点成本。

当然，CKV+在多可用区特性上，额外做了以下优化：

1. 对于同一个CKV+实例，主分片部署在一个可用区。客户也会尽量将client部署在主可用区，从而获得同一个可用区的低延时访问。

2. 备可读特性。其他可用区的备节点可以提供读能力，提高整体的读吞吐能力。

3. client就近访问。不同可用区的client可以自动访问到就近的节点进行访问，对用户透明。

CKV+在故障的探测和切换上，目前的逻辑上副本所在节点连续两三个周期不可达（默认周期是2秒），就会进行一些判死，并经过第三方server二次确认仍然不可达就可进行切换，RTO目前是6~10s。不过，主备分片切换会导致可用区的变化，如原来分片1是a可用区的，切换后会变成b可用区，这个分片的访问延时很可能会变大。因此，CKV+在触发主备分片切换后，会尽快在原主可用区重建一个新副本，重建完后会自动执行分片的可用区调整，恢复主可用区的低延时访问。

异地单活虽然提供了不同的容灾级别，甚至不同可用区提供了读能力，但只能在主可用区执行写操作。跨城延时一般在10~50ms级别，如果部署在上海的client希望对深圳集群执行写操作，网络延时将极大地影响性能。这个时候，应用希望总是以就近方式写入集群，多地的数据支持互相同步，并且解决一致性问题。这也是CKV+异地多活架构需要解决的问题。

1. 环路复制检查。这里的重点需要保证保障复制不要形成环路，不要重复消费。

2. 日志幂等处理，冲突解决。CKV+会对数据和日志进行深度定制，实现幂等的记录级日志，同时通过vector lock等机制来解决多地数据冲突的问题。

3. 低延迟复制。目前所有节点的复制都是基于raft，raft算法可以基于pipeline和批量的方式来提升效率，降低延时。另外，日志订阅模块收到raft日志后，可以通过并行和批量执行等方式来增大整体吞吐，从而降低多地集群的同步延时。

4. 故障处理。多活比较主流的做法是基于dts+mq机制来实现，这个做法其实是存在一些问题和挑战的，例如模块出现故障，需要选择从新的组里处理，在日志层面进行断点、续传等行为，这些都是非常麻烦的事情。但目前基于raft learner的方式，故障处理的难度将会大大降低。

5. 扩缩容处理。数据分片扩容，就是将分片A的部分slot迁移到分片B。CKV+扩分片机制是snapshot加增量日志的模式，这样就有可能在不同的raft group中有两段相同的增量日志，需要一定的策略来处理这些相同的日志。

异地多活是CKV+ 2022年上线最重要的新特性之一，会基于数据和日志分离的架构继续演进，预计2022年5月能上线，敬请期待。