苏宁O2O在异地多活架构与存储的深度实践

1. 前言

一般而言，业界的大型互联网公司往往采用分布式系统架构，衡量分布式架构的核心在于高可用（High Availability）。

根据CAP理论，服务分区容错（Partition Tolerance）是不能舍弃的，因此，对于AP系统可用性（Availability）、CP数据一致性（Consistency）的选择，决定了分布式系统的设计思路。

以往简单的系统会部署在单地域单机房，但大型互联网公司，从SLA的角度出发，设计中一般都不采用这样的单点架构，从单机房、同城双活、异地灾备、再到异地多活、单元化，多数互联网公司都是从类似架构过渡过来的，本文着重从架构和存储两方面的角度来讲述。

2. 概念

所谓异地多活，是指在多个不同物理地域之间同时提供业务流量和商业服务，各个地域之间不是主备关系，各个地域有自己独立的基础设施以及数据中心，业务流量可以不均等的分配在某几个地域之间。它与异地冷备相比，不仅具有更高的成本优势，而且更具有可扩展性。

因为异地多活，实际上就是让各个地域同时承担部分业务流量，缓解单一地区的业务压力。另外，与冷备相比，异地多活为业力提供了更快速地的业务恢复能力。当某一地域出现不可用时，业务流量可以随时在不同地域之间进行相互切换，达到了在提供商业可持续性的同时，进行流量动态分配。

3. CAP

提到异地多活，就涉及分布式系统和数据库，就不得不提一下著名的CAP理论，可以简单概括为以下三句话：

C(Consistency)：A read is guaranteed to return the most recent write for a given client.
A(Availability)：A non-failing node will return a reasonable within reasonable amount of time(no error or timeout).
P(Partition Tolerance)：The system will continue to function when network partitions occur.

一般而言，CA是无法兼得的，P是无法放弃的，所以一般而言，所有分布式系统的设计，要么保AP，要么保CP，用一张图说明：

4. 业界概念与方案

4.1 单机房

目前的应用一般部署在公有云平台上，硬件方面，包括网络、电力、散热都是冗余的。服务方面，通过集群模式来减少机器、机架故障造成的影响，对于SLA要求不高的应用基本能满足要求。

但单机房部署在整体组网架构中存在单点隐患，一旦出现机房级故障，服务只能暂停并等待恢复，灾害性事故导致服务长时间中断所引发的资损以及社会效益损失，都是企业无法承担的。所以对于大型互联网公司，例如BAT等，都会考虑服务的冗余，比如“同城双活”或者“同城灾备”。

4.2 同城双活和同城灾备

同城双活和同城灾备的差别在于两个机房是否都跑流量。

单机房遇到机房故障，如断网、断电等便停止服务，同城机房可弥补这个弊端。由于同城机房物理上距离足够近，机房之间通过光纤专线连接，跨机房调度的时延一般可以忽略不计（<3ms），在部署方面和单机房相比并未提高复杂性。

分层方面：

接入层：CDN、4层代理、7层代理、网关，可以选择随机的路由方式，如随机、轮询、权重、一致性哈希等，也可以选择有目的性的路由策略，如主机房优先、同机房优先、自定义路由规则等。
服务层：设计为无状态的，应用之间用SOA框架连通，如Dubbo、Spring Cloud、Istio等，内部可以横向扩展，具备auto scaling能力。

存储层（以一般数据库作例子，高端存储设备不作描述）：一般互联网公司使用MySQL，数据拓扑架构为Master-Slave，采用主从复制（async或semi-sync），在数据中心切换之前，仅在主数据中心进行写操作，同步到非主数据中心的数据库，便于主库故障时候可以手工或自动切换(failover)，减少恢复时间。

但是，这种架构问题主要是伪双活，主故障时数据一致性无法满足。解决这个问题的方式是使用分布式数据库，利用Paxos、Raft分布式一致性协议保证强一致（这部分后文将会介绍）。

4.3 异地多活和异地灾备

同城双活能解决架构上的单点问题，但依然无法摆脱地域性的灾难，如地震、洪水等自然灾害，跨地域部署镜像灾备机房和服务便成为进阶考虑。

但跨地域部署的最大挑战是网络时延，一些网络延时的经验数据如下：

北京-南京 1000公里+ 25ms
南京-广州 1300公里+ 30ms
同地域 30-50公里 2-3ms
同机房 <1ms

如果服务调用关系复杂，多次的跨地域调度，加上网络抖动，异地部署的时延往往会比较可观，对业务正常开展也会有负面影响，所以一般异地备份机房只做灾备，采用非对等独立部署（更小规模、各层独立部署）不承载业务流量，存储基于数据库同步机制进行复制。

这种同城双活+异地灾备的架构，一般称为“两地三中心”架构，即两个地域，三个IDC。

同城双活+异地灾备对于中等应用基本足够了，但是对于大型互联网应用，依然不能接受：

流量和数据量极大，BAT这种体量，备份机房不跑流量，对于数据一致性要求很高的场景，有一定风险，后文将会讲到；
对于可用性要求极高，4个9的SLA水平，全年停服不能超过1个小时，恢复时间（RTO）取决于预案的执行情况；
备份全站，资源利用率低，成本高；
扩容困难，伸缩性受限，计算、存储、网络等资源受限於单地域的容量。

异地多活架构下，地域之间不是主备关系，不同物理地域之间同时提供业务服务，不涉及到故障切换failover的工作（流量会有策略调度），而failover的灾备策略往往不是自动化的，而且一般比较复杂，需要测试演练，所以维护成本，切换的风险很高。

异地多活下，各个地域机房独立运行，流量可以按策略调度到各个地域和可用区，与异地灾备相比：

具备更快的业务恢复能力。流量动态分配，一个区域宕机，流量可以自由在各个地域间调度、切换。在某些场景甚至还可以支持就近原则，用户访问更快。
预期和非预期的机房故障可以做容灾演练、机房维护，这些对业务都是透明的。
不用备份全站，成本低。
伸缩性好，服务和数据可以相对平衡负载在各个区域，不受单地域资源限制。

需要说明的是，并不是所有业务都需要做异地多活，一般对主链路业务、SLA要求较高、扩容频繁的业务优先做，否则方案会比较复杂，工作量也比较大。

4.4 单元化

实现了异地多活，也并不代表到达了终点。

异地多活主要的问题在跨地域延时上，业界目前的解决方案主要集中在网络层面（搭建BGP网络、CDN加速等）。在架构层面，阿里在2016年提出的 “单元化”（unit）概念，意思是让特定user的请求和数据收敛和封闭在同一个IDC，单元高内聚，尽量减少跨区域访问，即“单元封闭”。一些流量较小的长尾应用，仍然只在中心部署，配套容灾方案。

单元化的策略是按照某个业务维度拆分用户，例如线上商城和支付APP一般是按照会员id（userid）取模划分单元的，物流一般是按照user所处的地域划分。每个IDC根据URL设定路由策略调度流量，并封闭服务和存储，只承载本单元的请求。

4.5 数据库的高可用

对于传统数据库，需要额外配套HA策略来切换Master和Slave。MySQL在本区域或者跨区域的高可用，可以通过主从复制（replication）+多副本（replica）实现，一个实例做Master，其它实例做Standby，主故障即可切换，其他可以做本区域或者跨区域的复制，只做只读，扩展读能力。

假设有5000对MySQL主备实例，另外又有一套用来切换MySQL主备实例的HA工具，要做到任意一台主库宕机，HA都能够在极短的时间内切换主备，需要做到的包括：

部署监控代理

为了监控各个主库的状态，需要在各台机器上部署Agent以采集实例健康状态。Agent以一定时间，不断的向HA汇报实例的健康状态（Heartbeat）。

Heartbeat与仲裁节点

这些实例的的健康信息如果存放于一个节点上，也存在单点风险。因此需要把这个风险分散到多个节点上，这些节点称为仲裁节点。

数据一致性

接下来就是数据一致性了，下节会介绍。

到这里，HA也已经是一个分布式系统了，一般都会马上想到ZK，因此，对于分布式集群的管理，最终还是绕不过Paxos数据一致性协议，基于这种思路，业界涌现了很多分布式数据库的解决方案，这块后面介绍。

4.6 数据的一致性

对于传统关系型数据库，无论是Oracle还是MySQL，最通用的做法是通过存储共享或者日志同步来保证。

Oracle的存储共享

比较著名的就是oracle的RAC（Real Application Cluster），基于share everything架构，比如3个节点的RAC系统，在CPU、内存上是做了扩展，但是为了保证数据强一致性，存储做了共享。但这种架构最大的弊端就是各个节点争用热点块而引起的“GC”（Global Cache）等待事件。引起“GC”事件的原因，就是同时只能有一个节点在更新同一个块。Oracle RAC在Fusion Cache层做了内存锁，用以协调各个节点对于同一个Block的Update操作。Block有资源Master概念，只有得到Master的授权，才能对块进行更改。因此在架构设计上，Oracle引入了DRM（Dynamic Resource Management）。

另外，为了解决集群的脑裂（Brain Split），Oracle引入了基于共享存储的Voting Disk，来对Brain Split进行仲裁。

这种架构显而易见的弊端是对硬件依赖非常严重，任何存储介质的异常，都必须进行容灾切换，并且无法做到跨机房部署，也就做不到IDC间的容灾了。而基于Paxos一致性协议的分布式数据库系统，很容易做到这一点，将其中一个副本存放于其它IDC中即可。

日志同步

日志同步，对于性能的损耗比较大。无论是Oracle的Data Guard还是MySQL的Binlog同步，对于Master主库的TPS有明显的损耗。每次事务commit，必须要等到从库ACK，并成功应用后，主库再返回给用户事务提交信息。业界有非常多的优化方案，如日志缓冲区锁优化、异步化、减少不必要的context switch等，但网络开销这块，即使采用万兆网、调优网卡软中断模式，也改善不了多少。

以MySQL为例，如果采用Replication（异步复制），由于其异步特性，若数据未完成同步即产生切换，则数据会产生丢失，PRO>0，此时被提升为新主库的数据自然就与之前的主库不一致，如果在同步时停止服务，这样可用性又受到影响，业务是无法接受的。

为改善Replication带来的数据不一致，MySQL 提供了semi-sync（半同步复制），即主库需要接受从库的ACK（代表同步到Binlog），才返回客户端成功。对于幻读，在5.7之后又可以通过设置AFTER_SYNC或AFTER_COMMIT模式来解决，注意开启semi-sync会影响写性能。

但开启semi-sync，也不一定PRO=0，非高负载select的场景下，MySQL通常开启InnoDB引擎，采用2PC进行提交，在事务Prepare阶段写完Redo log，事务不是commit状态，需要走到Server层面，Binlog写成功，才进行解锁，清理Undo log的commit工作，再返回客户端。

MySQL支持用户自定义在commit时如何将log buffer中的日志刷到log files中，主要方法是通过设置变量innodb_flush_log_at_trx_commit的值来控制Redo Log的刷盘策略：

0：commit时，写入log buffer中，然后每秒写入os buffer并同步fsync刷盘，若进程crash，丢失1秒钟数据。

1：默认模式，commit时，写入os buffer并同步fsync刷盘，安全，但需要等待磁盘IO，性能差。

2：commit时，仅写入os buffer，然后每秒fsync()将os buffer中日志写入到log file disk中，比0安全，比2快，若宕机，丢失1秒数据。

同时，可以通过调整参数innodb_flush_method的值来控制Redo Log的打开、刷写模式，对于这个参数，有4个值：

fdatasync：默认，调用fsync()去刷数据文件与redo log的buffer。
o_dsync：InnoDB会使用o_sync方式打开和刷写redo log，使用fsync()刷写数据文件。当write日志时，数据都write到磁盘，并且元数据也需要更新，才返回成功。
o_direct：InnoDB会使用o_direct打开数据文件，使用fsync()刷写数据文件跟redo log，write操作是从MySQL InnoDB buffer里直接向磁盘上写。
all_o_direct：与o_direct差别在于redo log也直接向磁盘上写。

这4个策略的选择最终影响的是CPU、处理性能和响应时间。

Sync_Binlog控制Server层面Binlog的刷盘策略。

在事务prepare阶段，当MySQL进程Crash或者系统宕机，Binlog是否传输到从库，相应的文件有没有落盘，都会造成客户端、主库、从库的数据不一致。MySQL的主从，再加上刷盘，是不能保证数据强一致的。如果采用semi-sync+强制刷盘的策略，可以做到不丢数据，但是MySQL实例之间的数据一致性是无法保证的。

比如，redo log或者Binlog任意一方丢了，那么客户端会感知失败，主库恢复时会rollback，如果Binlog同步到了从库就生效了，从而出现主从不一致。

为了满足可用性要求，减少数据不一致，有一些策略可以优化，例如，主库宕机恢复后，先禁写，避免新数据写入主库导致不一库，等把gap diff apply到从库上，如果没有冲突，再恢复；否则，采用手工对帐订正数据。

可用性不强求覆盖100%的用户，原则上满足大部分用户才是关键。

面对跨地域的高时延和网络抖动，远距离同步Binlog有很多局限性。所以，存储层面的数据同步在业界会采用DRC中间件解决，比较常用的是Otter和DRC（Data Replication Center），DRC对比Otter，其更关注业务的划分，可以实现单元内封闭，而Otter只是在纯数据库层打通的技术。

这类中间件的原理为：从数据库同步Binlog，异步的将数据进行解析、过滤、标准格式化（DRC Message）、复制远程传输，中间件本身可以做持久化，便于实现一次订阅，多点分发。可以在事务一致性的前提下提供秒级的DB同步，这种方式注重AP，牺牲了异地一致性。

在单元化异地多活的架构里，DRC可以承担单元和中心之间的数据复制功能：可以采用写中心、读单元的模式：中间数据广播到各单元，单元通过中心做数据同步。也可以各单元部分写，相互同步。这样请求可以做单元封闭，单元内的数据可以是全量的，支持了区域故障时候的机房切换。

4.7 分布式数据库

分布式数据库，比较熟悉的比如开源的TiDB、阿里云的RDS，Google的Spanner等。它们基于Paxos协议或者Paxos简化变种Raft来实现分布式系统的数据最终一致性。

Paxos有两种实现思路，一种是将Paxos与实际的数据节点独立出来，如zk，这种架构比较简单，但是因为增加了Leader和Follower的通信而带来了更大的时延。另一种是直接将Paxos实现到各数据节点的组件中，好处是时延低、但技术难度高，比如蚂蚁的OceanBase、Google的Spanner等。

分布式数据库对数据的每次修改都看作一次增量log，通过在存储上套一层Raft协议。例如，三个节点的集群，Raft的Leader负责写，Leader的事务日志同步到follower，超过多数派（majority quorum）落盘后，再commit。虽然延迟明显高了，但小幅延时却可以保证数据一致性，而吞吐可以靠集群和拆分解决。

可以存在很多的Raft Group，数据按照Range进行分区，还可以做二级分区，这种sharding效果等同于分库分表，而扩展性、灵活性和容灾能力更好。传统的数据库强调ACID，而分布式数据库可以实现双A，即加上Availability，只要有半数以上的节点正常就能保证分布式数据库正常工作，当Leader节点故障时发起Leader election自行恢复，无需人工switch over或者failover。

而阿里云的RDS，其原理也是在MySQL内核上套用一个Raft状态机控制事务，保证了数据的一致性，由于分布式数据库依赖Paxos或者Raft，所以延迟更是问题，一般部署在同地域，依赖DRC（DTS）做异地复制。

分布式数据库单Group至少3个节点，更加可靠的方案可以采用5个节点，以三地五中心架构举例，Zone1和Zone2同城双机房，Zone3和Zone4同城双机房，一个距离稍远的可以设计为仅做日志副本，节省空间，同时减少高延时带来的吞吐量下降，可做到PRO=0，RTO几十秒，强一致，可抵御个别硬件故障、机房级灾难和区域级灾难。

5. 苏宁O2O的异地多活

以上内容全部基于线上2C业务，但O2O的异地多活有所不同。

首先，苏宁O2O以线下业态为主，包括苏宁易购、苏宁小店、苏鲜生、苏宁极物等。但接入方式多种多样，比如设备，既包含Pos机、收银一体机等终端设备，也包含自助收银机、机器人、电子称等智能设备，同时包含各种APP，如店+。APP走LocalDNS+CDN的方式接入，而终端设备在接入层面以专线+VPN为主，无法通过CDN进行流量调度，每家门店都建立多条专线的成本也无法承受。即使采用中心交换汇聚，也会面对各种单点问题。

其次，由于DB层面缺少双向同步能力，目前在DB层面依赖MySQL自带的异步数据同步（Replication）和半同步（semi-sync），根据之前的描述，数据一致性无法得到保障，增加网络延时与抖动的风险。

最后，O2O有两层数据维度，一层是门店维度，另一层是用户维度，这也区别于一般的2C业务，复杂度增加。

根据上述的情况，需要在架构和数据层面进行整体性考虑，见O2O的未来架构：

5.1 接入层

1、网络方面：

苏宁小店\迪亚店\大润发\店+ 等，原先通过VPN接入数据中心，后在门店中部署无线AP对接Wi-Fi或直连网线。

电器门店的收银机,原先通过SDH Line或ADSL（IPsec）设备，走专线和VPN接入，先到达分公司核心交换机，再通过大区核心交换机进行转发。后也通过无线AP接入或有线连接的方式。

2、流量层面：

业务请求域名指向为CDN，终端请求流量经DNS解析后，就近接入CDN，由CDN根据一定规则（shopid或userid取模）调度不同数据中心。

在数据中心，流量先经由WAF进行安全清洗，对于Https请求则卸载SSL，并调度到后端集群Gateway VIP，由网关负责将Http协议转为RSF协议（RPC）调用后端服务

3、安全层面：

前端与后端的请求经由Https进行加密，终端设备接入需要进行安全认证。

5.2 服务间调用

服务的划分

苏宁O2O也采用了类似单元化的概念，将所有数据与服务在单元内封闭，称为Unit。Unit由一组包含服务+数据的业务集群组成，称为Cell。请求的数据按照Cookie中的MA字段进行切分，关于Cell和MA，后面有介绍。

根据服务性质的不同，将服务区分为共享、独占和竞争服务。

1）共享服务：

每个数据中心部署一套Cell，所有Cell拥有相同的数据，相互共享。该类数据在所有Cell内都是一致的，对于每个Cell都是全量，才能支持本Cell完成业务。例如商品、价格、档口等数据。

2）独占服务：

每个数据中心部署一到多套Cell，对应的服务和数据仅在某个Cell存在，不与其它Cell交叉或共享。其它Cell不需要本Cell的数据即可完成内部业务，如会员、订单、购物车。

3）竞争服务：

只在主数据中心部署一套Cell，该类型数据存在各个Cell相互竞争，为保证数据的一致性，需要在一个数据中心统一控制读写，例如库存、领劵、时效控量、唯一编码、用户注册的用户名唯一性等。

服务间调用方式

1）RPC调用

苏宁内部提供RSF框架（类似于Dubbo），服务之间通过ZK集群注册和发现，接口间通过RPC协议相互访问。RSF在不同DC部署不同注册中心实例，多个注册中心组成一个集群，内部进行数据同步，两个机房的生产者实例分别向对应的注册中心注册RSF服务，并且可以指定该服务的调用是路由到相同机房或主机房。

对于独占服务，由于数据被封闭DC内部，因此调用独占服务的RSF接口一般采用路由同机房策略。有一些涉及不同维度结合的场景，可能会涉及多DC数据汇聚的场景，由将索引维度及汇聚下沉到中台。

对于共享服务，写操作的RSF服务路由主机房，读操作RSF服务路由同机房。

对于竞争服务，只在主机房部署，因此全部路由主机房。

2）MQ

苏宁内部提供WindQ（类似于ActiveMQ），仅限于异步业务，业务需要支持消息的幂等操作。有二种模式，分别是Queue模式（一对一）和Topic模式（一对多），生产环境主要采用Topic模式。

目前在WindQ的消息队列管理系统上，Topic模式的路由策略由消费者定义，支持三种路由类型：同机房、主机房和全路由。

服务类型	说明	路由策略
独占服务	独占型服务的数据封闭在LDC内，主要采用同机房路由，消费者只能接收到来自同机房生产者发送的数据	同机房路由
共享服务	对于写操作，采用主机房路由，主机房的消费者可以接收来自所有机房生产者发送的数据；对于读操作，采用同机房路由，消费者接收到来自同机房生产者发送的数据	写：路由主机房读：路由同机房
竞争服务	竞争服务只在主机房部署，因此全部路由主机房	路由主机房

Topic模式还有种全路由方式，类似于一种广播模式，全路由模式下，所有消费者可以接收到所有机房生产者发送的数据，类似于全网刷新广播。

3）Kafka

业务需要在各个机房生产数据，然后每个机房的数据需要汇总到某一个机房来进行消费统计，目前主要采用主机房汇聚。

4）定时任务

服务类型	DUTS运行模式	说明	备注
独占服务	单机运行或分片运行	LDC选择所有机房执行或定义2个任务，分别选择主机房和指定机房	正常情况采用单机运行，若任务数较多，可设置分片数，将不同任务分片分发到不同机器上去运行
竞争服务	单机运行或分片运行	LDC选择主机房执行
共享服务	单机运行或分片运行	LDC选择主机房执行	底层通过数据库进行同步

5.3 数据层面

由于缺少DB层面的双向同步能力，为降低数据不一致的风险，需要考虑合理的数据切分规则，减少数据之间的同步，收敛跨机房请求。

1、数据划分

如果将每个Cell作为一套包含服务+数据的业务集群。那么每个Cell的数据库单独作为一个物理数据库存在，不允许Cell之间的交叉访问，即同一个库内不允许有不同Cell的数据。

由于目前数据库备份方式采用交叉互备，并且需要保证同一Cell的数据要能够收敛在同一个LDC中，因此，需要对于独占型数据定义分布规则。

Cell之间可以交叉互备，最小的互备单元为两个Cell集合（cellId，cellId+4）。独占型数据的分布方式参考Ma的切片规则：

MA类别	计算方式
tradeMA	memberUID % 256
shopMA	acsII(shopUID)% 256

分库分表策略：每个应用的分表数为256N，分库个数为8M+1。M和N代表自然数。

类型	分表策略（独占）	分库策略（独占）	多活单元划分（CellId, CellId+4）
tradeMA	tableId= memberUID % (256*N)	dbId = tradeMA %(8M),其中，tradeMA=255单独分配到库8M	(dbId,dbId+4)作为一个最小子单元，子单元两两递归组成更大子单元，cell255单独做一个单元
shopMA	tableId= acsII(shopUID) % (256*N)	dbId = shopMA %(8M),其中，shopMA=255单独分配到库8M	(dbId,dbId+4)作为一个最小子单元，子单元两两递归组成更大子单元，cell255单独做一个单元

2、数据一致性

对于不同的服务，有不同的一致性策略。

对于共享服务（多DC数据一致）：每个DC都部署一套集群，该集群包含全量数据，共享服务数据的变更请求只能通过主DC操作，类似于master-slave模式，若请求流量是非主DC发起，则通过跨中心RSF或MQ方式进行处理。主DC数据变更后，底层通过MySQL Replication实现数据同步。

对于独占服务（根据不同数据分片独立存储）：在多个DC根据数据分片策略部署多套集群，每个集群封闭自身的操作和数据，但在本DC和跨DC通过其它Cell实现数据备份，当某LDC数据变更后，通过MySQL Replication实现数据同步。

对于竞争服务（控制资源，如权益、余额等），只在主数据中心进行CRUD，其它DC部署镜像服务和数据，但只同步，不调度流量。

正常情况下，数据同步的时延是毫秒级，但DB数据备份在网络中的传输受到距离、网络抖动等因素影响，可能存在一致性风险，考虑有以下策略：

减少数据同步：只同步重要数据，减少不重要数据及同步后没用的数据的同步。比如待支付清单，丢失后重新查询生成支付列表即可。
保证最终一致性：在业务逻辑中，尽量减少对数据同步实时性的依赖，只要数据能最终一致即可。比如当某件商品新增了折扣，在数据同步完成之前，查询了商品价格，对于这种情况，只要保证最终扣款和打印发票时，折扣已经被计算入内即可。

3、数据备份

不同集群结对，数据交叉互备。

4、缓存

对于独占服务，Redis需要跨机房备份，备份思路参考MySQL备份策略，机房A-master-node -> 机房A-slave-node -> 机房B-slave-node，同步策略为准实时同步，当主机房宕机时请求引流到备份机房时，组件根据tradeMA或是shopMA路由到对应的Redis服务。当主机房恢复时，需要将备份机房中主机房对应的备份Redis中的数据全量复制（RDB）到主机房对应的Redis，然后再恢复主机房进行引流。

对于共享服务，采用主机房读写，副机房只读的主从单向备份。

缓存加载首先通过懒加载方式加载数据到缓存中，由于更新或删除无法通过懒加载加载到缓存的，通过canal读取MySQL Binlog捕获对应的变更信号，并更新到缓存中。

缓存预热通过数据库复制方式同步到各个数据中心，然后通过canal读取MySQL Binlog来触发缓存加载（推荐），或通过业务变更数据库时，同步变更缓存（视情况采用该方案）。

6. 参考文档

1、《High-Avaliability at Massive Scale:Building Google`s Data Infrastructure for Ads》

作者介绍：

荣多君，苏宁科技集团O2O平台研发中心副总监，在苏宁从事负责O2O新零售业务及平台建设，目前负责中心系统多活及互联网化改造工作。