CKV+异地容灾探索和实践

见贤思齐

今天跟大家分享的题目为《CKV+异地容灾探索和实践》。CKV+是一个兼容redis协议的内存数据库，现在大部分用户对内存数据库的要求越来越高，对一致性、异地容灾等方面也提出更高的要求。下面从过往经验教训、可用性&一致性、CKV+架构演进、CKV+单活多可用区和CKV+多活架构探索等方面跟分享一些关于容灾的实践和思考。01过往的经验教训2016年亚马逊的CTO发表了一篇文章，总结了过去十年亚马逊云服务的经验教训，其中第二点就讲到接受一切的故障，“故障总是意料之外，情理之中发生”。确实是这样子，在过去几年，CKV+也出现过包括主机故障、磁盘写满、流量突发、机房网络中断等方面引起的一些故障。在故障层面，涉及主机级、机架级，可用区级，以及机房级等都各种各样不同的故障。对于城市级的故障，印象比较深的是，在2015年，天津机房附近的天津滨海新区危险品仓库发生大爆炸，导致天津数据中心岌岌可及，大量业务需要做迁移。所以，故障总是不可预料的，但不管是天灾还是人祸，需要我们是要对不同的容灾级别做一些处理，这也是今天我们主要讨论的内容。02CKV+数据可用性&一致性的探索和思考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+也能够在高性能上做一些取舍，损失一定性能，支持强一致性能力。所以，我们在未来架构演进过程中，需要考虑如何实现多种一致性来满足不同用户的要求，同时也考虑不同的容灾级别。03CKV+架构演进上图是CKV+架构，有以下特点：