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

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

一、关于容灾

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

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

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

相关文章

来自专栏恰同学骚年

《大型网站技术架构》读书笔记之七:随需应变之网站的可扩展架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

1003
来自专栏JAVA高级架构

大型分布式电商系统架构是如何从0开始演进的?

2163
来自专栏人人都是极客

手把手教你如何向 Linux 内核提交代码

说到开源大家都会想到黑客和极客,开源的概念最早也是在极客们推出和推崇的。开源的提倡旨在开放源代码使之更方便自由的使用和再创作。随着这一思想的发展,衍生出诸多的开...

1692
来自专栏架构说

分布式配置中心架构与实战

声明:信息来源 docker.io 分享主题:分布式配置中心架构与实战 分享主题:分布式配置中心架构与实战 声明 信息来源docker.io 今天的大规模...

1.1K8
来自专栏FreeBuf

经验分享 | 企业如何做好安全基线配置

一、为什么要做基线配置管理 一个组织在不同的时期部署了不同的业务系统,承载业务系统的是不同的操作系统和支持系统。业务系统在运行期间,基本上很少做操作系统的升级或...

4645
来自专栏杨建荣的学习笔记

平台设计中的脚本管理

前期揉入了一些功能,因为主要是面向基础功能,所以进度略慢,如果要想一下子有种井喷的效果,那就是脚本化和流程化大显身手的时候了。 如果尽可能减少开发和业务同学之间...

3904
来自专栏Java架构沉思录

淘宝大秒系统设计详解

大家还记得2013年的小米秒杀吗?三款小米手机各11万台开卖,走的都是大秒系统,3分钟后成为双十一第一家也是最快破亿的旗舰店。经过日志统计,前端系统双11峰值有...

1082
来自专栏CSDN技术头条

Uber是如何通过Mesos和Cassandra实现跨多个数据中心每秒100万的写入速度的?

每隔三十秒就会有位置数据返回,包括来自于司机和乘客应用的各类数据,需要实时使用的实时数据非常之多,那么Uber是如何存储这些位置数据的呢? Uber的解决方案非...

2139
来自专栏猿人谷

一个项目的简单开发流程——需求、数据库、编码

关于一个项目的简单开发流程   前言:从11月8号开始到11月12号我们小组使用html+easyUI+ashx+异步,开发了一个简易的网 站,也就是简单的门户...

2615
来自专栏IT笔记

微服务化的基石——持续集成

在很多微服务化的文章中,很少会把持续集成放在第一篇,因为大多数的文章都会将如何拆的问题,例如拆的粒度,拆的时机,拆的方式。

5238

扫码关注云+社区