如何成功机房之间的数据同步 同城双活

在业务初期，为了控制投入老本，许多公司通常只经常使用一个机房提供服务。但随着业务的开展和流量的增长，对服务照应速度和可用性的要求逐渐提高，这时就须要思考在不同地域部署服务，以提供更好的用户体验。这也是互联网公司在流量增长阶段的必修之路。

我之前所在的公司延续三年流量不时增长。有一次性，机房的对外网络突然断开，造成线上服务片面离线，网络供应商也无法咨询上。由于没有备用机房，咱们花了三天时间紧急协调，从新拉线路才复原服务。这次意外形成的影响十分大，公司损失达千万元。吸取了这次经验后，咱们将服务迁徙到了更大型的机房，并选择在同一市区树立双机房，以提高服务的可用性。这样，当一个机房出现缺点时，用户可以经过 HttpDNS 接口极速切换到另一个反常的机房。

为了确保在一个机房缺点时，另一个机房能够间接接收流量，咱们对两个机房的设备启动了 1:1 的洽购。但假设让其中一个机房长时期处于冷备形态会形成资源糜费，因此咱们宿愿两个机房能同时对外提供服务，也就是成功同城双活。不过，双活计划的一个关键疑问是如何成功双机房之间的数据库同步。

由于数据库经常使用的是主从架构，因此全网只能有一个主库来启动数据更新。咱们只能在一个机房部署主库，而后由这个机房将数据同步到其他备份机房。虽然两个机房之间有专线衔接，但网络的齐全稳固性无法保障。假设网络出现缺点，咱们须要确保机房之间在网络复原后能够极速复原数据同步。

有人或许会以为间接驳回散布式数据库可以处置这个疑问。但是，扭转现有的服务体系并片面迁徙到散布式数据库不只须要相当长的时期，老本也十分高昂，对大少数公司来说并不实践。因此，咱们须要思考如何变革现有系统，成功同城双活机房的数据库同步。这也正是咱们的指标

外围数据库中心计划是经常出现的成功方式，这种计划只适宜相距不超越 50 公里的机房。

在这个计划中，主库集中部署在一个外围机房，其他机房中的数据库则作为从库。当有数据修正恳求时，外围机房的主库会首先成功修正，而后经过主从同步将更新的数据传输到其他备份机房的从库。

由于用户通常是从缓存中失掉信息，为了降落主从同步的提前，备份机房会将更新后的数据间接写入本地缓存。同时，客户端会在本地记载下数据修正的最后时期戳（若没有，则记载时期）。当客户端向服务端动员恳求时，服务端会智能对比缓存中该数据的更新时期与客户端本地的修正时期。假设缓存中的更新时期早于客户端记载的时期，服务端会触发同步操作，尝试在从库中查找最新数据；若从库中没有最新数据，则从主库中失掉最新数据并更新到该机房的缓存中。

经过这种方式，可以有效防止机房之间的数据更新提前疑问，从而确保用户能更及时地失掉到最新的数据。

此外，客户端还会经过恳求调度接口，经常使用户在短时期内只访问同一个机房，防止用户在多个机房之间来回切换时，因数据在不同机房同时修正而发生更新兼并抵触。总体来看，这种计划设计相对便捷，但也存在一些清楚的缺陷。

例如，假设外围机房出现缺点，其他机房将无法口头数据更新。缺点时期，须要人工切换各个代理（proxy）的主从库性能能力复原服务，缺点复原后也须要手动参与以复原主从同步。此外，由于主从同步存在肯定的提前，刚更新的数据在备用机房中会有持久的无法见时期，这种提前会造成业务逻辑中须要人工处置这种状况，全体操作较为繁琐，参与了成功的复杂性。

这里我给你一个经常出现的网络提前参考：

同机房主机：0.1 ms同城主机（100 公里以内） ：1ms（10 倍 同机房）北京到上海：38ms（380 倍 同机房）北京到广州：53ms（530 倍 同机房）

须要留意的是，上述设计只是一次性 RTT 恳求，而机房间的同步触及屡次顺序叠加的恳求操作。假设要大规模更新数据，主从库的同步提前将更为清楚。因此，这种双活机房计划的数据量不能过大，且业务更新数据的频率也不能太高。另外，假设服务对强分歧性有要求，即一切操作都肯定在主库“远程口头”，这也会放大主从同步的提前。

除了以上疑问，双机房之间的专线偶然也会出现缺点。我曾遇到过一次性专线断开继续了两小时，时期只能暂时经过公网来坚持同步，但公网同步不稳固，提前在 10ms～500ms 之间动摇，造成主从提前超越 1 分钟。幸运的是，由于用户中心服务关键依赖常年缓存的数据，业务关键流程没有遭到太大影响，只是用户修正信息的速度变得很慢。

双机房同步还或许偶发主从同步终止的状况，因此倡导设置告警处置机制。一旦出现此状况，应立刻向缺点警报群发送通知，由 DBA 人员启动人工修复。此外，我还遇到过在主从不同步时期，用户注册时自增 ID 出现重复，造成主键抵触。为此，我倡导将自增 ID 交流为基于 SnowFlake 算法生成的 ID，以缩小主键抵触的危险。

总的来说，虽然这种外围数据库的中心化计划成功了同城双活，但人力投入老本十分高。DBA 须要手动保养同步，一旦主从同步终止，复原起来相当耗时耗力，且研发人员也须要时辰关注主从不同步的状况。因此，我介绍经常使用另一种计划：数据库同步工具 Otter。

Otter 是阿里开发的数据库同步工具，它可以极速成功跨机房、跨市区、跨国度的数据同步。如下图所示，其外围成功是经过 Canal 监控主库 MySQL 的 Row binlog，将数据更新并行同步给其他机房的 MySQL。

由于咱们要成功同城双机房双活，所以这里咱们用 Otter 来成功同城双主（留意：双主不通用，不介绍分歧要求高的业务经常使用），这样双活机房可以双向同步：

如上图所示，每个机房内都有自己的主库和从库，缓存可以跨机房主从同步，也可以是本地的主从同步，这取决于详细的业务需求。Otter 经常使用 Canal 将机房内主库的数据变卦同步到 Otter Node 中，而后经过 Otter 的 SETL（Select, Extract, Transform, Load）机制整顿后，再将数据同步到对方机房的 Node 节点，从而成功双机房之间的数据同步。

在这里须要提到 Otter 处置数据抵触的方式，以处置双机房同时修正同一条数据的疑问。Otter 中的数据抵触分为两类：行抵触和字段抵触。行抵触可以经过对比数据的修正时期来处置，或许在出现抵触时启动回源查问来笼罩指标库。而关于字段抵触，可以依据修正时期笼罩，也可以兼并多个修正操作。例如，假设 a 机房和 b 机房区分对某字段启动了 -1 的操作，兼并后该字段的最终修正值为 -2，以此成功数据的最终分歧性。

但须要留意的是，这种兼并战略并不实用于库存类的数据治理，由于或许会造成超卖现象。假设有相似的需求，倡导经常使用常年缓存来处置，以防止并发修正造成的数据不分歧疑问。

机房之间的数据同步不时是行业中的难题，由于其高昂的成功老本，假设无法成功双活，那么肯定会有一个机房以 1:1 的机器数量在空跑。并且在出现缺点时，也无法保障冷备机房能够立刻对外提供服务。但是，双活形式的保养老本也不低，机房之间的数据同步经常会因网络提前或数据抵触而终止，最终造成两个机房数据不分歧。

好在 Otter 在数据同步方面采取了多种措施，能够在大少数状况下保障数据的完整性，并降落同城双活的成功难度。即使如此，在业务运行中，咱们仍需人工梳理业务流程，以尽量防止多个机房同时修正同一条数据。为此，咱们可以经过 HttpDNS 调度，让用户在一段时期内只在一个机房内生动，缩小数据抵触的或许性。关于频繁修正、资源争抢较高的服务，通常在机房本地口头完整事务操作，防止跨机房同时修正带来的同步失误。