「数据库」 如何解决异地机房的数据同步问题?

大家知道，MySQL主备复制原理是：

• MySQL master 将数据变更写入二进制日志( binary log, 其记录叫二进制日志事件binary log events)
• MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
• MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据

这种主从备份模式，对应的实践就是在同一个机房一个局域网内，做主从复制来备份数据。为了追求更安全的备份，发展出了异地机房的多活模式。因地域不同，通信不够稳定，就需要对slave

进行扩展。

模拟一个slave，阿里巴巴的canal 工作原理：

• canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
• MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
• canal 解析 binary log 对象(原始为 byte 流)

cannel拿到数据后，下一步目标就是把这些数据存到目标数据库。

但分布式情况下，需要保障数据一致性。一个名为ZooKeeper的工具解决了分布式数据一致性问题：分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。它用了一种称为ZooKeeper Atomic Broadcast （ZAB， ZooKeeper原子广播协议） 的协议作为其数据一致性的核心算法。

ZooKeeper特性：

ZooKeeper是一个典型的分布式数据一致性的解决方案。可保证如下分布式一致性特性。

• 顺序一致性

从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到ZooKeeper中。

• 原子性

所有事务请求的结果在集群中所有机器上的应用情况是一致的，也就是说要么整个集群所有集群都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。

• 单一视图

无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。

• 可靠性

一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。

• 准实时性

仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

至此，数据一致性解决后，只需要给用户一个管理界面，配置业务级别的各种参数，即可放心的同步异地数据了。于是就有了阿里巴巴的otter----基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库. 一个分布式数据库同步系统。

阿里巴巴的otter原理：

1. 基于Canal开源产品，获取数据库增量日志数据。

2. 典型管理系统架构，manager(web管理)+node(工作节点)

a. manager运行时推送同步配置到node节点

b. node节点将同步状态反馈到manager上

3. 基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作。

otter自带管理界面，目前manager的操作可分为两部分：

• 同步配置管理
  1. 添加数据源
  2. canal解析配置
  3. 添加数据表
  4. 同步任务
• 同步状态查询
  1. 查询延迟
  2. 查询吞吐量
  3. 查询同步进度
  4. 查询报警&异常日志

manager的用户权限在设计的时候，主要分为三类：

• ADMIN : 超级管理员
• OPERATOR : 普通用户，管理某个同步任务下的同步配置，添加数据表，修改canal配置等
• ANONYMOUS : 匿名用户，只能进行同步状态查询的操作.

otter完整逻辑图如下：

对于IT同学来说，后面可以看其文档，逐步搭建起来了。这里不再赘述。

按照文档部署后，配置一下，就可以用了。