双机房部署

• 双活数据中心入口路由算法

1. 静态路由算法：基于IP地址进行选择
2. 动态路由算法：分析链路和数据中心的负载情况，响应时间，优先级等进行路由
3. 系统网关控制：通过网关制定规则实现流量分发

• 双活数据中心需要注意的问题

1. 脑裂现象：网络出现波动，通信终端，无法感知，各自为战，很难判断请求应该分发到哪个数据中心
2. 运维相对复杂：数据同步问题，如何达到同步准实时
3. 非零丢失：一个机房挂掉，另一个机房还没有及时同步最新数据的情况，只是非常少量的数据丢失，所以双活不能保证非零丢失

基于支付场景的双活体系建设

业务是否能够在一个机房完成整体业务的请求链条

如支付业务：入口网关-支付交易-支付服务-支付路由-支付渠道，这5个服务形成了一个完整链条，追龙需要部署在同一个机房内，如果不在同一个机房，每次请求跨级机房，就需要性能损耗，需要进行较大改造

应用程序双活

应用程序双活一般分为三种：1.主机房接收请求；2.双机房同时接收请求，由入口网关做请求路由；3.双机房同时接收请求，由Nginx+Lua做请求路由。

• 主机房接收请求

只是主机房接收请求，备机房只做备份使用，缺点是资源利用率低。

• 双机房同时接收请求，由入口网关做请求路由

最简单的方法是在支付请求的时候包含一个唯一标识，如订单号，通过对订单号进行Hash求值来判断当前请求属于哪个机房，Hash算法和路由分发由入口网关系统承担。

入口网关系统在支付业务中承担权限校验，限流，加密解密等作用，也可以进行请求分发，缺点是每次请求都要进入网关判断，对网关处理并发能力要求较高。

• 双机房同时接收请求，由Nginx+Lua做请求路由

所有请求在Nginx这一层由Lua语言根据标识做路由控制，不用再透传到入口网关进行系统判断。使用OpenRestry比较容易实现Nginx+Lua的整合。也可以参照分库分表使用一致性Hash算法，还可以提前按四个机房或留个机房来 Hash，通过路由分发等扩展方式。

常用第三方组件如何进行双活

zookeeper的数据同步

使用场景配置中心，分布式锁，命名服务（分布式ID），分布式协调/通知，集群服务，注册中心等。

常见数据同步方式有两种：

1.利用Zookeeper Curator的TreeCache来实现

这种方式优点是实现简单，缺点是可能会存在Watcher丢失的情况，通过TreeCacheListener对象可以实现对Zookeeper指定节点进行增加，删除，修改和更新事件的监听，当监听到相应时间后可以将获取的数据同步更新到另一个机房中。

修改Zookeeper源码伪装观察者

2.zookeeper有三种角色，Leader，Follower，Observer

• Leader：作为集群的主节点，负责相应所有对Zookeeper状态变更的请求。它会将每个状态更新请求进行排序和编号，保证整个集群内部消息处理的FIFO。
• Follower：相应服务器上的读请求，还要处理Leader的提议，并在Leader提交该提议时在本地也进行提交。
• Observer：大多数情况下与Followe完全一致，但是他们不参加选举和投票，仅仅接收选举和投票的结果。

Observer角色主要是为了提高负载能力，从而实现zookeeper读取的高吞吐，可以修改源码，伪装Observer角色从Leader上获取最新更新的数据，然后将数据同步到另一个机房的Zookeeper中就可以实现跨机房同步

Redis数据同步

1.主从机制进行数据同步

主机房的redis配置为主，备机房的redis配置为从。

目前官方还没有提供跨机房的主主同步机制。

2.利用数据库的binlog数据进行同步

应用正常写到Mysql数据库汇总

Mysql数据库产生binlog日志

同步组件读取binlog日志

同步组件解析binlog日志后将数据同步到redis中，并同步到另一个机房的redis中。

业务数据一致性

Mysql主主同步方案

使用Canal+Otter做数据同步方案

可以同步不同库之间的异构表

Canal+Otter可以实现一个表一线程，多个表多线程同步，速度更快，同时会压缩简化要传输的binlog，减少网络压力

双A机房同步，目前Myql的M-M部署结构不支持解决数据一致性问题，基于Otter的双向复制+一致性算法，可在一定程度上解决这个问题，实现双A机房。