容灾系列(五)——数据库容灾建设

在一个数据为王时代,数据安全视为一家企业命根子,因此如何保障企业数据安全尤为重要。本文主要从数据库容灾方案视角,基于当前客户业务并结合技术&产品,制定最佳容灾方案。主要从以下三个方面来介绍:

  • 方案设计要素
  • 云上容灾方案
  • 云上客户案例

1.方案设计要素

数据库容灾方案设计要素主要数据同步,数据一致性以及数据修复三个方面 。

1.1 数据同步

数据同步主要指两个可用区或者不同地域之间的数据同步,主要分为单向同步和双向同步。

同步方式

复制原理

具体场景

优势

劣势

单向同步

采用主从复制方式

上层业务单写模式

1.数据一致性挑战低
2.业务改动较小

业务延时依赖较强

双向同步

采用主主双向复制方式

上层业务单写或者双写模式

业务延时依赖较弱

1.数据一致性挑战高
2.业务改动较大

针对双向同步的业务单写场景进行说明:

业务流量单个游戏服务在单个地域承载,如下图通常情况下,红色框的业务不承载流量,而是作为业务紧急逃生通道;同时数据库读写均在同一地域,不同地域之间进行主主双向同步。

数据库单写,双向同步场景

1.2 数据一致性

数据一致性,主要指上层业务在读库时候,数据库集群主从库存储的数据保持一致。如果数据库集群不同库数据不一致,业务就会读到脏数据。举个例子,银行余额数据库存在数据不一致情况,某天当白领小王刚发工资,同时收到短信通知余额3万元,但是当小王登录银行APP查询发现余额仅有2000元,由于新增余额没有及时同步到所有主从库,导致数据不一致;试想一下这种情况,银行需要多少客服人员来支持呢?

1. 单写业务场景

单写业务场景,说明业务只有一套数据库系统,因此一致性保障依赖于数据库集群内主从库复制方式,包括异步,半同步,以及强同步。正常来讲,一般业务采用数据最终一致性,折中选择半同步复制方式居多。

复制方式

技术原理

一致性

性能

异步复制

应用发起更新请求,主节点完成相应操作后立即响应应用,主节点向从节点异步复制数据。

半同步复制

应用发起更新请求,主节点在执行完更新操作后立即向 从节点 复制数据,从节点接收到数据并写到 relay log 中(无需执行) 后才向主节点返回成功信息,主节点必须在接受到从的成功信息后再向应用程序返回响应。

强同步

应用发起更新请求,主节点完成操作后向从节点复制数据,从节点接收到数据后向 主节点返回成功信息,主节点接到从的反馈后再应答给应用。Master 向 Slave 复制数据是同步进行的

2.针对双写业务场景

业务双写,说明业务系统有两套数据库集群,数据一致性保障一方面是集群内数据复制方式,另一方面两个集群间数据复制方式。双写数据一致性保障主要还是依赖于业务层。如下图是业内主流数据库双写方案,

1)根据用户信息划分不同IDC机房,通过API网关把不同用户转发到不同的IDC集群

2)数据库mysql数据已做单元化拆分,双入口可写,但是同一个用户数据仅在一个入口访问,来保障读数据一致性。

3)如果数据发生冲突,系统可以通过时间戳顺序覆盖旧数据。

业内主流数据库双写方案

1.3 数据修复

数据库集群发生故障中断后,如何来保障数据一致性。

1)中断场景感知和切换

一般通过仲裁中心探测,在探测周期内,发现主节点异常,进行VIP的切换。MHA作为业内较为成熟的数据库高可用故障解决方案;而腾讯云采用ZK方式去感知切换,经过测试准备切换大约30s完成。

2)中断场景一致性保障

基于1.2章节描述保障数据一致性外,主要还是依赖实际业务场景来进行加固。通常来讲,对数据不是很敏感业务,主从切换不需要对比数据一致性的。如果有业务对数据一致性要求较为敏感,一般都有内部全量校对工具来校验,如果发现不一致,通过既定原则按照时间戳方式来覆盖自动修复,或者通过本地日志来分析人工处理来保障数据安全。

2. 平台容灾方案

客户业务场景最常用腾讯云数据产品主要是redis,cdb,mongoDB以及TDSQL。

数据产品

跨区容灾

就近访问

跨地容灾

CDB

支持
控制台自助配置

支持
跨AZ/跨地域RO实例

方案一:通过DTS支持,需要业务手工切换VIP
方案二:支持DTS双写能力,云上云下或多地域。

redis

支持
控制台自助配置

支持
跨AZ/地域副本

方案一:通过DTS复制支持
方案二:通过DTS支持全球复制能力,多地就近读取

TDSQL

支持
控制台自助配置

支持读写自动分离
跨AZ/跨地域

通过DCN复制来支持

MongoDB

支持
控制台自助配置

支持
跨AZ副本

通过DTS复制支持

3.云上客户案例

目前云上某家金融公司,使用云上TDSQL产品,数据库存放数据是订单业务,需要将当前单可用能力升级为多可用区能力。同时升级为多可用区能力,会引入以下风险因子

  • 业务时延会有3ms左右网络延时,tdsql在proxy到db无就近原则
  • 极端情况下主从一致性问题概率变大
  • 跨可用区网络抖动会导写业务hang住

同地域不同AZ会存在3ms网络延时,实现容灾建议这里性能进行取舍,对于2和3的诉求点,结合tdsql产品提供容灾建议。

基于当前tdsql核心数据库采用单可用区一主两从架构,数据复制方式为强同步,主要有三种方案,综合考虑采用方案三

其中TDSQL强同步说明:https://cloud.tencent.com/document/product/557/10570

方案

方案详情

优势

劣势

方案一

双可用区部署:一个可用区一主一从,另一可用区一从

1.业务延时:业务延时受跨可用区延时影响较小,与同可用区延时几乎无差别,从强同步理论上多数ACK均由Slave1返回给Master节点。
2.写数据hang住:与同可用区业务场景一致。

1. 数据一致性:数据一致性较差,强同步均依赖于Slave1,对于slave2数据可能不是最新数据,可用区故障可能会存在数据不一致的情况
2. 读脏数据:AZ1和AZ2跨可用区之间网络异常,当ZK在判断剔除slave2期间(20s),只读业务有在slave2概率会读过期脏数据的情况(对延迟敏感业务,本身也不建议读取从节点数据)

方案二

双可用区部署:一个可用区一主,另外一可用区两从

1. 数据一致性:master可用区故障,根据强同步规则,保证数据最终一致性。
2. 读脏数据:理论上两台slave返回ack时间差别较小,因此跨可用区之间网络异常,在两个slave节点读取脏数据可能性非常低。

1. 业务延时:跨AZ会有3ms网络延时,业务结合具体事务综合来评估。
2. 写数据hang住:逻辑链路跨可用区只有一条,依赖于可用区之间链路稳定性,会增加写数据hang住概率。

方案三

三可用区部署:三个可用区,每个可用区一个节点

1. 数据一致性:master可用区故障,根据强同步规则,保证数据最终一致性。
2. 读脏数据:理论上两台slave返回ack时间差别较小,因此跨可用区之间网络异常,在两个slave节点读取脏数据可能性非常低。
3. 写数据hang住:逻辑链路跨可用区有两条,增强跨AZ网络稳定性,会降低写数据hang住概率

跨AZ会有3ms网络延时,业务结合具体事务综合来评估

原创文章,作者:kirin,如若转载,请注明出处:https://blog.ytso.com/212310.html

(0)
上一篇 2021年12月16日
下一篇 2021年12月16日

相关推荐

发表回复

登录后才能评论