MySQL异地多活的数据双向复制方案.docx

MySQL异地多活的数据双向复制方案异地多活背景在讲DRC或者讲数据复制之前，先跟大家回顾一下异地多活的背景。今天我主要分享饿了么多活的底层数据实施，介绍在整个多活的设计和实施过程中我们是怎么处理异地数据同步的，而这个数据同步组件在我们公司内部称之为DRC。去年我们在做多活调研的时候，整个公司所有的业务服务都是部署在北京机房，服务器大概有四千多台，灾备的机器是在云端，都是虚拟机，大概有三千多台。当时我们峰值的业务订单数量已经接近了千万级别，但是基本上北京机房（IDC）已经无法再扩容了，也就是说我们没有空余的机架，没有办法添加新的服务器了，必须要再建一个新的机房，于是我们在上海建一个新的机房，上海机房要在今年的4月份才会投入使用，所以需要在上海机房建成之后，异地多活项目能具备在生产环境上进行灰度。异地多活的底层数据同步实施这是异地多活的底层数据同步实施的一个简单的概要图，大家可以看到，我们有两个机房，一个是北京机房，一个是上海机房。在这个时候，我们期望目标是北方所有的用户请求、用户流量全部进入北京机房，南方所有的用户请求、用户流量进入上海机房。困难的地方是，这个用户有可能今天在北方，明天在南方，因为他在出差，还有就是存在一些区域在我们划分南北shard的时候，它是在边界上面的，这种情况会加剧同一个用户流量在南北机房来回漂移的发生。还有个情况，当我们某个机房出现故障，如核心交换机坏掉导致整个机房服务不可用，我们希望可以把这个机房的所有流量快速切到另外的数据中心去，从而提高整个饿了么服务的高可用性。以上所有的因素，都需要底层数据库的数据之间是打通的。而今天我所要分享的DRC项目就是饿了么异地MySQL数据库双向复制的组件服务，即上图中红色框标记的部分。异地多活对底层数据的要求我们在前期调研DRC实现的时候，主要总结了的三点，而在后续的设计和实施当中，基本上也是围绕这三点来去解决问题。第一个我们觉得是延迟要低，当时给自己定的目标是秒级的，我们希望在北京机房或上海机房写入的数据，需要在1秒钟之内同步到上海或者北京机房。整个延迟要小于1秒钟。第二个就是我们要确保数据的一致性，数据是不能丢也不能错的，如果出现数据的不一致性，可能会给上层的业务服务、甚至给产品带来灾难性的问题。第三个就是保证整个复制组件具备高吞吐处理能力，指的是它可以面对各种复杂的环境，比方说业务正在进行数据的批量操作、数据的维护、数据字典的变更情况，这些会产生瞬间大量的变更数据，DRC需要面对这种情况，需要具备高吞吐能力去扛住这些情况。数据低延迟和一致性之间，我们认为主要从数据的并发复制这个策略上去解决，安全、可靠、高效的并发策略，才能保证数据是低延迟的复制，在大量数据需要复制时，DRC并发处理才能快速在短时间内解决。数据一致性，用户的流量可能被路由到两个机房的任何一个机房去，也就是说同样一条记录可能在两个机房中被同时更改，所以DRC需要做数据冲突处理，最终保持数据一致性，也就是数据不能出错。如果出现冲突且DRC自身无法自动处理冲突，我们还提供了一套数据冲突订正平台，会要求业务方一道来制定数据订正规则。高吞吐刚才已经介绍了，正常情况用户流量是平稳的，DRC是能应对的，在1秒钟之内将数据快速复制到对端机房。当DBA对数据库数据进行数据归档、大表DDL等操作时，这些操作会在短时间内快速产生大量的变更数据需要我们复制，这些数据可能远远超出了DRC的最大处理能力，最终会导致DRC复制出现延迟，所以DRC与现有的DBA系统需要进行交互，提供一种弹性的数据归档机制，如当DRC出现大的复制延迟时，终止归档JOB，控制每轮归档的数据规模。如DRC识别属于大表DDL产生的binlog events，过滤掉这些events，避免这些数据被传输到其他机房，占用机房间带宽资源。以上是我们在实施异地多活的数据层双向复制时对DRC项目提出的主要要求。数据集群规模（多活改造前）这是我们在做多活之前的北京数据中心的数据规模，这个数据中心当时有超过250套MySQL的集群，一千多台MySQL的实例，Redis也超过四百个集群。DRC服务的目标对象就是这250套MySQL集群，因为在正在建设的第二个数据中心里未来也会有对应的250套MySQL集群，我们需要把两个机房业务对等的集群进行数据打通。多活下MySQL的用途分类我们按照业务的用途，给它划分了多种DB服务类型。为什么要总结这个呢？因为有一些类型，我们是不需要复制的，所以要甄别出来，首先第一个多活DB，我们认为它的服务需要做多活的。比方说支付、订单、下单，一个机房挂了，用户流量切到另外新的机房，这些业务服务在新的机房是工作的。我们把这些多活服务依赖的DB称为多活DB，我们优先让业务把DB改造成多活DB，DRC对多活DB进行数据双向复制，保障数据一致性。多活