发布日期:2022-09-02 18:52浏览次数:
今天跟大家分享的题目为《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+架构,有以下特点:
总体上,CKV+在架构设计上,是希望充分的压榨单机的性能,在追求极致性能的同时控制成本。
然而,基于CKV+原架构的特点,在容灾和性能平衡方面还有一些难点和问题。首先,数据和日志耦合性大。无论是异步还是raft复制,复制流程与当前的操作主流程耦合,尤其是raft实现,维护代价比较大。第二,repication占用资源较多。复制模块目前占用现有资源比例不低,特别时在写流量特别大的情况下,它占用的资源会比较多,在一定程度上影响了单核的性能。并且默认主分片的日志通过流的方式直接同步给备分片,但当备分片故障时或者网络短暂异常,日志是需要落盘的,这就会影响到主分片的性能,毛刺会更明显。第三,cache node无法处理大量日志。当前Cache Node一般使用内存容量较大的机型,对日志的落地存储空间和性能要求不高,是没有办法存大量的日志的。这就面临着备分片长时间断开后的断点续传,以及备份回档功能等较难落地,数据安全性上面同样面临挑战。所以,在用户对一致性强要求和容灾级别提出新的要求的情况下,我们提出了一个新的架构。
从以上图示看,对比于原架构,新架构有以下特点:
04CKV+单活多可用区异地容灾实践
CKV+为了满足不同的容灾要求,已上线了单活多可用区特性,支持不同容灾级别:
默认的情况下,CKV+的容灾级别是跨机架容灾,保证主备分片必须跨机架,避免一个机架掉电导致主备分片都不可用的问题。如果希望更高的容灾级别,可以选择同地域多可用区以及跨地域多可用区,当然这样可能导致的访问和主备延时会更大。在不同的级别上,容灾对于性能和成本其实是一个很微妙的关系。如果你需要更高的容灾级别,那么可能就需要牺牲一点性能和提高一点成本。
当然,CKV+在多可用区特性上,额外做了以下优化:
CKV+在故障的探测和切换上,目前的逻辑上副本所在节点连续两三个周期不可达(默认周期是2秒),就会进行一些判死,并经过第三方server二次确认仍然不可达就可进行切换,RTO目前是6~10s。不过,主备分片切换会导致可用区的变化,如原来分片1是a可用区的,切换后会变成b可用区,这个分片的访问延时很可能会变大。因此,CKV+在触发主备分片切换后,会尽快在原主可用区重建一个新副本,重建完后会自动执行分片的可用区调整,恢复主可用区的低延时访问。
05CKV+多活架构异地容灾探索
异地单活虽然提供了不同的容灾级别,甚至不同可用区提供了读能力,但只能在主可用区执行写操作。跨城延时一般在10~50ms级别,如果部署在上海的client希望对深圳集群执行写操作,网络延时将极大地影响性能。这个时候,应用希望总是以就近方式写入集群,多地的数据支持互相同步,并且解决一致性问题。这也是CKV+异地多活架构需要解决的问题。
CKV+多活架构存在着一些特点:首先,它是一个多城部署、就近读写访问,最终一致的形态。其次,将日志模块和存储服务分开,日志模块保障稳定可靠的日志服务。第三,新增日志订阅转发模块,并作为日志模块的raft learner(非DTS)节点,同时把增量日志同步到跨城集群中。第四,CKV+新架构衍生于存储和日志解耦的架构,对架构的入侵少。
基于CKV+的新架构,可解决以下场景的问题。第一,跨城容灾,每个城市都有一份完整的数据,即使发生城市级的灾难,数据和服务都能得到有效的保证。其次,边缘分布,就近提供最近端的服务,就近读写,性能会达到最高。另外,异地多活方案同样适用于未来跨云部署的方案。例如公有云A和公有云B都部署了各自的CKV+集群和Forwarder模块,Forwarder模块只需向另一个云端集群同步增量日志即可,解决跨云同步的问题,为实现多云数据访问创造可能。
CKV+新架构的优点和使用场景非常明显,但在实现过程中也存在着一些难点。主要包括:
异地多活是CKV+ 2022年上线最重要的新特性之一,会基于数据和日志分离的架构继续演进,预计2022年5月能上线,敬请期待。
文章来源于腾讯云开发者社区,点击查看原文