数据库 流量切分_数据库多活方案

前言：

当企业互联网业务到达一定规模后，往往会考虑做多数据中心。一方面可能是面临业务增长带来的挑战，单个数据中心变得难以支撑；另一方面出于对业务容灾的考量，也可能在多个城市建立数据中心达到容灾目的；还有可能本身就是全球化的业务，用户遍布在全世界各个角落，为了提升用户体验，也需要建立多数据中心。本文来一块探讨下在多数据中心间实现业务多活在数据库层有那些常见的解决方案，以及业务在应用每种方案中会遇到那些挑战。

这张图摘自阿里云文档，图画的不错拿来一用。大部分业务都会存在上面3层架构，业务在多机房之间实现多活首先需要解决这3层架构拆分问题。流量层拆分：这个实现起来很简单，在流量上层DNS转发不同流量到不同机房即可。

应用层拆分：应用层基本上都是些无状态的服务，因此拆分起来很简单，可能需要对下层数据层一些异常做兜底。

数据层拆分：因为数据中心之间的网络是整个多数据中心架构的瓶颈，网络带宽时延高的问题、宽带费用成本的问题、专线不稳定(挖断机房光纤)。所以这块是设计多数据中心架构中最复杂的一块工作，需要做数据一致性和可用性方面的权衡。

数据层拆分

一般会根据某个业务维度来做数据的拆分比如：用户属性维度、地理位置维度，使得流量能够较为合理的分摊到不同的数据中心。 为了支持多数据中心可读写，数据拆分后在数据中心之间还要做数据复制、数据一致性校验，因此数据库多机房复制方案选型尤为重要！

数据复制

长期以来跨数据中心复制一直是开源数据库产品的弱项，在成熟的商业数据库产品中有很多解决方案，尽管现在看起来也没有那么完美。针对MySQL原生复制的种种缺陷，在开源社区中率先出现了基于Galera的数据复制强一致方案如：MariaDB Galera Cluster 和Percona XtraDB Cluster，MySQL官方也随后推出MySQL Group Replication给MySQL跨数据中心复制带来一丝曙光。

异步复制、MGR、Galera性能对比

主从复制

MySQL官方在很多年来一直都只有原生的复制解决方案，而原生的复制技术目前存在很多缺陷：主备数据复制延迟问题

集群选主需要依赖第三方工具实现自动化

异步复制不能保证主备数据一致，半同步复制会大大降低主节点写入性能

主备数据冲突异常导致复制中断

多主复制数据冲突问题等

如果放在跨数据中心复制的场景中，这些缺陷也可能会被放大，需要通过一定手段弥补。 设想一下机房间切流量的场景，数据库层对应的DB需要保证短时间内切库操作全部完毕无误！！！

中间件复制

阿里DTS、饿了么DRC自研数据同步中间件实现双向复制，多IDC不同可用单元可以做到流量切换。

优点：双向复制支持多点写入，可能存在写冲突的情况，需要中间件实现数据冲突处理算法

理论上可以做到数据最终一致

数据复制效率相对原生复制大大提升

不会牺牲数据库节点的性能

适合异构的多数据中心场景，比如混合云

缺点：运维成本高(包括引入中间件后DDL需要一套全新的方案复杂度高、节点间数据需要一致性校验、中间件自身组件的调度运维等)

需要中间件来解决双向复制的回环问题，完美实现难度巨大

数据质量难以保障，如果发生数据不一致，修复工作复杂

只能双向同步，适合两个数据中心

基于分布式一致协议复制

利用分布式一致性协议进行多数据中心间数据复制，可以做到CAP3个维度的均衡。如上图中是单主结构，也可以采用MGR中multi-master将集群中的节点分散到不同的IDC单元部署 做到多点写入，不过最好还是做好流量切分，避免出现多写带来的事务冲突。在业界落地的方案如：大名鼎鼎的蚂蚁OceanBase的三地五中心架构。

优点：数据中心之间能够保证数据强一致

适合多数据中心架构

运维复杂度大大降低

缺点：强一致会导致数据库响应延迟增加

多写模式冲突比较多时性能堪忧

不适合跨城机房网络时延大的场景

参考：饿了么MySQL异地多活的数据双向复制经验谈(附PPT)​mp.weixin.qq.com数据库异地多活解决方案_数据库异地多活解决方案_数据库解决方案_通用解决方案-阿里云​help.aliyun.comMongoDB · 同步工具 · MongoShake原理分析​mysql.taobao.org