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

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

一、关于容灾

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

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

 二、数平厚德平台(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 条评论
登录 后参与评论

相关文章

来自专栏大数据和云计算技术

对象存储入门

10.5.3 对象接口 对象存储系统(Object-BasedStorage System)是综合了NAS和SAN的优点,同时具有SAN的高速直接访问和NAS...

3653
来自专栏数据派THU

【独家】一文读懂非关系型数据库(NoSQL)

本文共11000字,阅读全文约需30分钟。 本文为大家解析非关系型数据库(NoSQL)。[ 在数据派THU后台(非留言区)回复"综述"即可获取资源。] 前言 N...

59310
来自专栏Albert陈凯

一文读懂非关系型数据库(NoSQL)

一文读懂非关系型数据库(NoSQL) 本文共11000字****,阅读全文约需30分钟****。本文为大家解析非关系型数据库(NoSQL)。 前言 ---- ?...

4846
来自专栏Java面试笔试题

什么是中间件?

计 算机技术迅速发展。从硬件技术看,CPU速度越来越高,处理能力越来越强;从软件技术看,应用程序的规模不断扩大,特别是Internet及WWW的出 现,使计算机...

762
来自专栏james大数据架构

0基础搭建Hadoop大数据处理-初识

  在互联网的世界中数据都是以TB、PB的数量级来增加的,特别是像BAT光每天的日志文件一个盘都不够,更何况是还要基于这些数据进行分析挖掘,更甚者还要实时进行数...

1827
来自专栏.NET技术

正确理解CAP定理

  CAP的理解我也看了很多书籍,也看了不少同行的博文,基本每个人的理解都不一样,而布鲁尔教授得定义又太过的简单,没有具体描述和场景案例分析。因此自己参考部分资...

902
来自专栏PPV课数据科学社区

【学习】NoSQL数据库的35个应用场景

现在我们站在各个用例的角度上来考虑那种系统适合于这些用例。 你的意见是首先,我们要纵览各种数据模型。这些模型的分类方法来自于Emil Eifrem 和 NoSQ...

2879
来自专栏喔家ArchiSelf

CAP理论与分布式系统设计

S 先生 是一位难得的技术同行,学者气质,一见如故。s 先生 作为本公众号(wireless_com) 的第一位投稿者,老曹深感荣幸。CAP 和 分布式系统的...

964
来自专栏企鹅号快讯

应用系统性能优化的几个思路

最近遇到一个互联网金融应用系统的性能问题,看了开发的优化方案,觉得还不够深入。结合之前看到一些互联网企业分享的方案,今天从运维角度整理一下比较理想的应用系统性能...

2179
来自专栏java达人

Base:Acid的替代方案

作者:DAN PRITCHETT 译者:java达人 来源:https://queue.acm.org/detail.cfm?id=1394128(点击阅读原...

3865

扫码关注云+社区