在一个数据为王时代,数据安全视为一家企业命根子,因此如何保障企业数据安全尤为重要。本文主要从数据库容灾方案视角,基于当前客户业务并结合技术&产品,制定最佳容灾方案。主要从以下三个方面来介绍:
- 方案设计要素
- 云上容灾方案
- 云上客户案例
1.方案设计要素
数据库容灾方案设计要素主要数据同步,数据一致性以及数据修复三个方面 。
1.1 数据同步
数据同步主要指两个可用区或者不同地域之间的数据同步,主要分为单向同步和双向同步。
同步方式 |
复制原理 |
具体场景 |
优势 |
劣势 |
---|---|---|---|---|
单向同步 |
采用主从复制方式 |
上层业务单写模式 |
1.数据一致性挑战低 |
业务延时依赖较强 |
双向同步 |
采用主主双向复制方式 |
上层业务单写或者双写模式 |
业务延时依赖较弱 |
1.数据一致性挑战高 |
针对双向同步的业务单写场景进行说明:
业务流量单个游戏服务在单个地域承载,如下图通常情况下,红色框的业务不承载流量,而是作为业务紧急逃生通道;同时数据库读写均在同一地域,不同地域之间进行主主双向同步。
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 |
支持 |
支持 |
方案一:通过DTS支持,需要业务手工切换VIP |
redis |
支持 |
支持 |
方案一:通过DTS复制支持 |
TDSQL |
支持 |
支持读写自动分离 |
通过DCN复制来支持 |
MongoDB |
支持 |
支持 |
通过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节点。 |
1. 数据一致性:数据一致性较差,强同步均依赖于Slave1,对于slave2数据可能不是最新数据,可用区故障可能会存在数据不一致的情况 |
方案二 |
双可用区部署:一个可用区一主,另外一可用区两从 |
1. 数据一致性:master可用区故障,根据强同步规则,保证数据最终一致性。 |
1. 业务延时:跨AZ会有3ms网络延时,业务结合具体事务综合来评估。 |
方案三 |
三可用区部署:三个可用区,每个可用区一个节点 |
1. 数据一致性:master可用区故障,根据强同步规则,保证数据最终一致性。 |
跨AZ会有3ms网络延时,业务结合具体事务综合来评估 |
原创文章,作者:kirin,如若转载,请注明出处:https://blog.ytso.com/212310.html