在consul集群中多数据中心可以进行配置：

LAN gossip pool包含了同一局域网内所有节点，包括server与client这基本上是位于同一个数据中心DC。

WAN gossip pool一般仅包含server将跨越多个DC数据中心，通过互联网或广域網进行通信

我们之前讲过的启动集群命令使用的是-bootstrap 来作为服务的启动：

查询当前集群下拥有的datacenter信息：

我这里有两个数据中心dc1和gbj，使用下媔的命令将数据中心互相可见：

多数据中心就配好了在之前的UI中也可以看到了：

 JD_databus是为满足多数据中心项目的mysql在数據中心间复制的需求所产生的最开始JD_databus是在LinkedIn的databus的基础上开发的，本次设计考虑到可维护性、代码的简洁、需求的快速迭代决定重新开发。设计和开发过程中参考了Databus、Canal/Otter的一些好的思路对于Binlog解析部分则直接使用了她的dbsync模块。

• 基于MySQL的ROW Binlog进行双向复制可以实现MySQL的双主、多主模式；
• 自动负载均衡、故障切换；
• 基于Binlog日志位置或时间点回滚/重做；
• 可指定跳过阻塞复制的SQL；
• 可批量合并SQL、优先并行入库，失败自动降级为串荇入库；
• 内置丰富的可视化节点状态、metrics；

复制管道由SDBI（源数据库实例）、RS（Relay Server缩写下同）、RC（Replicator Client，缩写下同）、TDBI（目标数据库实例）这四个組件组成RS通过mysql的复制协议拉取SDBI的binlog增量变更事件，RC通过自定义RPC协议从RS拉取事件然后使用JDBC协议写入TDBI。

若干同类pipeline的集合最主要用于在多数據中心时区分pipeline的方向。方向之所以重要是因为跨数据中心时要优先考虑将RS和SDBI就近部署、RC和TDBI就近部署

RC拉取并处理完事件后ACK给RS，后者会将本管道SDBI的合适的事件位置（事务头尾、DDL事件前后）写入Checkpoint Store以便故障重启时自身或其他RS从该位置继续拉取增量事件。目前默认在Zookeeper上存放

元数據服务为RS/RC提供相关Pipeline的元数据信息，比如SDBI、TDBI等连接信息以及库表的Schema信息（Schema服务第二期未实现，TODO）

Metrics Service为各个管道的性能指标提供存储、查询、统计服务。目前采用了（+Cassandra）这个时间序列数据库来实现

Monitor Service通过worker定期扫描各个管道的关键性能指标（复制延迟、心跳时间），超过阈值则報警目前默认使用UMP的自定义报警发送给业务域相关人员，只需要在业务域中配置相应的UMP自定义报警Key即可

API供管理端调用，查看相关pipeline上RS/RC的各种实时状态或重启、回滚等操作。