常见的几种数据层容灾架构比较分享

陈守志 腾讯公司平台运营开发组

一、关于容灾

  关于容灾主题,这里罗列对比了几种常见的容灾案例:

  相对接入层、应用层容灾而言,数据层的容灾相对比较复杂,实现起来难度大一些,下面主要针对公司内外常见的几种数据存储平台在容灾方面的实现进行探讨。

 二、数平厚德平台(HOLD)

  数平计费中心为了解决公司海量账户存储需求不断增加带来的传统db+cache存储架构的写操作并发不足、难以自动扩容等缺点,设计实现了高一致分布式Cache(简称厚德平台)。

  分为接入层、控制层、存储层和落地层四个主要的模块:

  接入层:负责统一的数据接入,对流量进行控制,并对外屏蔽存储节点的自动扩容、容灾切换等细节;

  控制层:全局配置管理,负责所有节点的管理、前端路由的下发、统一管理自动扩容和容灾切换的流程;

  存储层:负责数据在内存中高速读写存储,并保障数据最终一致性;

  落地层:负责数据落地固化,数据冷备或其他数据离线计算。

优点:

  1、数据一致性容灾:通过一致性中心CC的注册和黑名单锁定机制,来保障主备Cache的最终一致性,遇到灾难能够快速切换,对于主备不一致的数据处理遵循一个原则:宁可不服务,不能错账。且灾难时只有黑名单中的少量用户(百级别)不能提供服务,其他用户正常读写。从生产环境验证的效果看,故障自动切换影响的时间大概在10秒以内(10s主要用于确认故障),黑名单延迟在2秒以内。在一些需要重新加载数据的场景下(如当机恢复,服务重启),采用版本号的方法解决重入时数据覆盖引起的不一致问题。

  2、自动扩容:管理中心keeper实现统一调度,下发路由策略,并通过镜像搬迁和实时拉取两种方式,在不间断服务的情况下,实现数据层在高一致性要求下的一键无缝扩容。

  3、高性能:通过无锁编程、阻塞异步化等技术提升性能,单机读写(读和写10:1)性能可达到23w/秒,延迟<10ms。

 三、架构部CKV(原CMEM)

  CKV 全称Cloud KeyValue。具备高性能 、低成本、高可用的良好业务体验,能轻松应对海量数据访问、存储成本敏感、延时敏感等问题。CKV安全可靠 ,拥有2份热点数据,备Cache数据和流水落地,备份中心备份数据和流水,具备回档能力。

  由于CKV具备完善的接入流程和支持当前流行的多种协议,目前在公司运营推广较为成功,覆盖范围较广。

  系统分为接入层、管理层、Cache存储层和落地层,与厚德的分层功能大致类似,不再赘述。

优点:

  1、高性能:采用定制的内核态网络接入模块,具有高性能,低延时,单机性能出众,可平行扩展,性能不随数据规模的增加而降低。可同时提供19w/s的读服务,11w/s的写服务(平均时间<2ms,64字节小数据)。

  2、冷热数据分离:低成本,支持冷热数据自动分离,每一个KEY都将自动存放在性价比最高的介质上,这点非常有利于对外开放和第三方进行推广。

  3、高可用:日常运营包括扩容、缩容、负载调平、死机搬迁、容灾切换等,均已实现自动化处理。

  4、高可靠&回档能力:双份在线数据,可落地,持久存储。支持白名单、密码策略等功能,每日定时备份数据和实时记录流水,支持数据定点回档。

  5、便捷省心:由架构部集中统一部署,有成熟的接入指引和RTX实时咨询,即时申请即时使用,无需自行安装;拥有专业的运营团队,用户无需半夜去处理故障。这点我想应该是各BG很喜欢的特性之一。

 四、微信Quorum_KV

  Quorum_KV是微信开发的一套数据强一致性存储系统,主要支持key-table 和string-value两种存储模型。系统目前支持的特性有:

  1、强一致性的Quorum容灾方案,支持读写容灾,双机互备,双向可写;

  2、丰富的业务开发模型:

  a.支持类SQL接口(不支持事务),提供丰富查询和更新接口;

  b.支持string-val的高性能key-val接口;

  c.支持专用于存储索引的64bit有序数组接口;

  3、支持多机房部署容灾,目前支持kv2和kv6两种部署模式;

  4、支持自动化数据迁移扩容;

  5、高性能,在string-val模式下,已到达20wqps。

  系统采用强一致性的Quorum协议,它借鉴了paxos的思想,实现上更加简洁,解决了在多台机器并发写入时的数据一致性问题。

五、开源Redis

  Redis是一个开源的实现相对简单的高性能的key-value存储系统,业界有很多知名公司都在用,比如新浪、京东等。它有一个突出的优点在于,它支持存储比较多的value类型,包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash(哈希类型)。这些数据类型都支持丰富的操作,而且都是原子性的。在此基础上,redis支持各种不同方式的排序适用于很多业务场景。

  架构如下图:

  如上图,redis数据落地有rdb和aof两种模式,可配置。redis会周期性的把更新的数据写入磁盘(rdb模式)或者把修改操作写入追加的记录文件(aof模式)。

  rdb模式缺点:存在时间间隔T,灾难恢复时会丢失最大T时间的数据;

  aof模式缺点:由于所有命令都写入aof文件,aof相对较大,所以redis也提供了aof文件重写机制来给aof瘦身;另外aof的写入模式选择也会对redis的性能产生影响。

六、淘宝Tair

  Tair 是淘宝开发并开源的一个分布式 key/value 存储引擎。tair 分为持久化(ldb)和非持久化(mdb,rdb)两种使用方式。非持久化的 tair 可以看成是一个分布式缓存;持久化的 tair 将数据存放于磁盘中。为了解决磁盘损坏导致数据丢失,tair 可以配置数据的备份数目,tair 自动将一份数据的备份放到不同的主机上, 当有主机发生异常, 无法正常提供服务的时候, 其余的备份会继续提供服务。

  1、Tair总体结构

  tair 作为一个分布式系统, 一个集群是由客户端(Client)、控制中心节点(config server)和一系列的数据节点(data server),再加一个可选的InvalidServer(用多独立集群的一致性)组成。

  config server 负责管理所有的data server, 维护data server的状态信息,有主备两台config server;data server 对外提供各种数据服务, 并以心跳的形式将自身状况汇报给config server,所有的 data server 地位都是等价的,数据在集群中保留的份数可配置。

  Tair主要有mdb,rdb,ldb三种存储引擎,容灾方式不一样,分别来支持不同的应用场景,也分别对应着不同的IDC部署方式。

  2、 Tair部署方式及容灾

  Tair通过多种集群部署方式,来满足各类应用的容灾需求。下面所述的双机房可以扩展到多机房,淘宝现阶段基本还是采用的双机房。

  现总共有4种方式:

  双机房单集群单份,双机房各独立集群,双机房单集群双份,双机房主备集群;

  mdb存储引擎适用于双机房单集群单份,双机房各独立集群,双机房单集群双份;

  rdb存储引擎适用于双机房单集群单份;

  ldb存储引擎适用于双机房主备集群,双机房单集群单份。

七、对比总结

  1、数据一致性:

  正如CAP理论所指出的,一致性、可用性和分区容错性不能同时满足,在进行系统设计时需要在这三者之间做出权衡。作为互联网企业,为了给用户带来更好的用户体验,一般都是牺牲部分强一致性来提高可用性和系统性能,而仅提供“最终一致性”。(这里是指发生容灾切换时的一致性,正常情况下比如主备模式只有主可写,正常情况下当然是强一致的)

  而在最终一致性策略上,不同的系统有不同的策略或者其组合方式,包括:Quorum的NWR策略、两阶段提交协议、第三方、时间戳、版本号等。比如hold/ckv/tair都加了一个第三方来检测主备数据一致性,大家在落地+同步+对比检测修复的思路基本一样。

  2、容灾切换:

  容灾切换方案总体来看就两类:一种是主备切换模式,切换时提供短暂只读迅速恢复或者黑名单机制来保障灾难时服务的可用性,把损失降低到最低;另外一种是用类似paxos协议或者分布式锁和两阶段提交协议来保障强一致性,但是会牺牲一部分性能,多备份的扩展性也会略差。

  相对来说,hold的代价比较小,在灾难时,只是牺牲少部分黑名单的不一致性来保障高可用性。Quorun_kv也是同样,只是在备份扩展情况下,协商等待的延迟较大,而ckv在专业运营、多协议支持和冷热数据低成本方面的考虑也是非常有吸引力的。

  3、灾难检测:

  容灾切换时,一般都会有少量的交易损失,因此灾难检测一定要保障判断的正确性,防止因网络抖动等原因造成误切。容灾检测最好采用双重或多重检测的方法,来确保灾难判断的正确。

  4、100%可用:

  上述的容灾切换方案无法保证机器故障的那一瞬间的所有交易都会成功,若要保证100%绝对可用,需使用分布式事务或者在前端加一个消息队列或cache,采用重试或者其他方法来保障,但同时也会增加业务代码的复杂度。最好是在方案的agent端提供重试等配置策略,是否需要取决于业务的重要程度。

 八、旁观支付宝/携程事件

  5月27日、28日,国内知名的支付宝、携程相继出事,关于异地多活的容灾讨论重新被激活,引起业界的广泛关注。

  我们首先相信支付宝是有容灾策略的,但由于我们是局外人,尚不知支付宝在服务中断的这2个多小时里,是因为什么原因没有立即切换服务,但是足以给我们的警示,我们的服务是否可以做到灾难时自动切换?我们不能等待真正灾难来临时才意识到危险,需要定期进行容灾演练,并积极解决演练中出现的每一个细小的问题,其实在公司内部已经有很多部门都这么做了。

  而关于携程,官方解释是由于员工错误操作,删除了生产服务器上的执行代码导致。但是服务中断将近12小时,也反应出携程内部在代码、发布管理上或需要继续加强,同时大胆猜测其应该是花费了很多时间在数据恢复和验证上,如何保障数据的异地多活存储和灾难时的及时恢复,也是业界互联网公司应该借鉴和吸取的教训。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

微博热点事件背后数据库运维的“功守道”

【导语】 微博拥有超过3.76亿月活用户,是当前社会热点事件传播的主要平台。而热点事件往往具有不可预测性和突发性,较短时间内可能带来流量的翻倍增长,甚至更大。如...

19010
来自专栏程序员互动联盟

【前沿技术】啥叫实时虚拟化?

实时虚拟化听起来有点矛盾,但是它确实是有用的(在某些条件下),并且为 Linux 内核的灵活性又提供了一个强有力的证明。KVM2015 论坛的前两个演讲就详细的...

3374
来自专栏CSDN技术头条

容器集群支持数据库实践

京东容器数据库系统,管理1800台物理计算节点,生产1W+ 多MySQL Docker容器实例。架构简单可靠,Docker容器计算平台与MySQL集群管理平台解...

2248
来自专栏程序员宝库

两年 PHP程序员 聊下架构

前言 2016年很有幸参与了公司内部系统架构3.0的升级,我们把公司的业务进行了四大板块的拆分,分别是应用服务、内容服务、电商服务、支付服务。其他和业务无关的功...

30212
来自专栏微服务

全面解读NoSQL数据库Redis的核心技术与应用实践

互联网和Web的蓬勃发展正在改变着我们的世界,随着互联网的不断发展和壮大,企业数据规模越来越大,并发量越来越高,关系数据库无法应对新的负载压力,随着Hadoop...

2816
来自专栏JAVA高级架构

谈谈为什么需要服务治理(Dubbo)

1173
来自专栏IT技术精选文摘

京东网络接入体系解密之高性能四层网关DLVS

DLVS诞生之初 在SLB这块,京东用户接入系统提供四层负载均衡服务和应用层负载均衡服务,对于公网流量接入部分,和很多公司一样采用的是四层和应用层负载相结合的架...

2849
来自专栏编程

做好容错才能确保服务器的不间断运行

服务器容错 服务器运行时,如果出现故障服务器是否还能正常运转,且业务不会中断运行,这时候就会确认服务器容错如何?如果用户的网站、应用程序或网络系统没有适当的容错...

1888
来自专栏领域驱动设计DDD实战进阶

领域驱动设计之聚合与聚合根实例一

2737
来自专栏CSDN技术头条

共享出行业务下的高并发场景

某共享汽车出行平台从随着业务的发展,可能大家听到出行以为是滴滴,然而不是,不过今年美团等巨头也入场共享汽车行业,表明公司业务至少是不错的,城市也在不断扩张。

1006

扫描关注云+社区