04｜同城双活：如何实现机房之间的数据同步？
该思维导图由 AI 生成，仅供参考
核心数据中心设计
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
跨机房数据同步一直是互联网公司面临的挑战之一。本文介绍了在流量增长阶段构建多机房以提高服务可用性的必要性，并探讨了实现同城双机房双活的数据库同步方案。作者分享了在同城双机房双活中遇到的挑战和解决方案，重点介绍了核心数据库中心设计方案和其局限性。该方案通过主从同步和缓存更新实现数据同步，但存在主从同步延迟、网络故障和人工维护等问题。作者提出了使用数据库同步工具Otter作为另一解决方案，以减少人力投入和维护成本。文章还详细介绍了Otter的工作原理和性能优势，以及在实际应用中的注意事项。总的来说，本文深入探讨了同城双机房双活的数据库同步问题，为读者提供了有益的技术参考。 文章中介绍了Otter作为数据库同步工具的优势，能够快速实现跨机房、跨城市、跨国家的数据同步，并通过性能优化和故障切换功能提高了数据同步的效率和可靠性。此外，文章还提到了Otter对于不同距离的同步性能和延迟参考，以及在实际应用中的注意事项。通过本文的阅读，读者可以了解到Otter在解决跨机房数据同步问题上的重要作用，以及在实际应用中需要注意的细节，对于面临类似挑战的技术人员具有一定的参考价值。
《高并发系统实战课》，新⼈⾸单¥59
全部留言(20)
- 最新
- 精选
张申傲印象中 MySQL 的 binlog 中会记录一个 server id，用于唯一标识一个集群中的 MySQL 实例。做数据同步时，如果解析发现 binlog 中的 server id 和自己相同，说明是当前实例生成的数据变更，就不会再执行同步了。这个机制应该可以打破循环同步。作者回复: 你好，很高兴再次收到你的留言，我理解你这是一个很好的方式，我查相关资料的时候，突然意识到，这个方式也是有瑕疵的，比如，串联同步，级联同步，这会被中转服务覆盖掉
2022-10-31归属地：北京6
WGJ在这个方案中，数据库主库集中在一个机房，其他机房的数据库都是从库。当有数据修改请求时，核心机房的主库先完成修改，然后通过数据库主从同步把修改后的数据传给备份机房的从库。由于用户平时访问的信息都是从缓存中获取的，为了降低主从延迟，备份机房会把修改后的数据先更新到本地缓存。 老师,个人经验比较欠缺,想问问,备份机房会将修改后的数据更新到本地缓存不太理解,备份机房不是主库,怎么会修改到数据,还有这里的本地的缓存是指本机的内存,如果是的话,更新本机的内存怎么就达到降低主从延迟的目的了呢,这里节奏有点快了 [苦涩]作者回复: 你好，WGJ，这里确实我讲的快了一些。这里我按基础顺序理解挨个举个例子，做多机房核心在于解决单个机房损坏无法提供服务问题，一般会做做多机房，当有故障的时候会关闭故障机房让其他机房对外提供服务。但是实际制作的时候发现，大部分业务的数据更新是有一致性要求的。 比如用户账户有100元，如果两个机房同时执行扣款25元而不做互斥的话，会导致两个机房最终用户余额是75而不是50，也就是扣了两次只扣了25元，用户用25元买到两个25元商品。 为了避免这个问题，我给了一个建议就是把用户的这类请求短暂的都调度到一个机房进行处理，这样就不会出现多扣现象，因为同一个机房的很容易用锁去互斥。 这样虽然解决了问题，但是这也带来一个新问题，就是数据如果在一个机房做了修改，需要同步给其他机房，这个同步过程根据距离不同决定了这个同步会很慢，极端情况下用户在用的机房扣款后，其他机房2秒钟后才能同步过去。 而在我们的设计中备份机房只有从库，本地不会修改数据，那么用户扣款后两分钟后才看到主机房的同步后数据刷新是很差的体验，所以，备份机房的服务修改数据后会通知主机房进行更新，同时会刷新备份机房这个用户的账户缓存，用户的查询尽量优先从备份机房的缓存走，等主库更新后再同步过来备份机房的从库后，我们从备份机房的从库才能拿到最新的数据。
2023-04-10归属地：广东22
千锤百炼领悟之极限如果老师可以在每一期的结尾给出上一期思考题的答案就好了。作者回复: 你好，答案后期会公布，前期多看大家留言讨论，多查，多独立思考，会有更好的帮助
2022-11-13归属地：北京22- 黄堃健说到这里，我们再讲一讲 Otter 的故障切换。目前 Otter 提供了简单的主从故障切换功能，在 Manager 中点击“切换”，即可实现 Canal 和数据库的主从同步方式切换。如果是同城双活，那关于数据库操作的原有代码我们不需要做更改，因为这个同步是双向的。 老师，不理解Otter的故障切换时，如果是同城双活，那关于数据库操作的原有代码我们不需要做更改，因为这个同步是双向的。 有相关的资料吗？ 这里有点糊涂？
作者回复: 你好，同城双活其中一个机房故障，我们需要把那部分故障的用户转到正常工作的的机房，转的过程中要尽量保证不会出现两边同时修改同一个数据情况。 并且出故障的机房很可能会和另外机房断开暂时不能同步，恢复后会有一些数据没我同步和正常机房的后续更改冲突。 另外双活不是双向同步，双向同步数据肯定会坏掉，为了减少数据冲突并且不让一个机房闲置多数会让用户按hash分到不同的机房，所以双活多数会一部分主库分片在a机房，另一部分主分片在b机房，故障时实际上转移的是这样的分块谁是主库，谁做修改决策。
2024-03-01归属地：广东2 
IT小村异地多活核心是根据用户进行路由，简单地合并等操作，都存在问题作者回复: 你好，这个问题核心在于：用户数据操作短期内请求都会在一个机房内，所以这种合并 并不复杂和平时开发类似，同一个机房内的数据服务会自动处理这个数据合并。只有在多机房异地同步到一个实例时会有版本问题，但是用户数据只会在一个地方更新互斥，所以这个可能只有在用户切机房或机房故障时会有体现。
2023-12-02归属地：北京
Sam_Deep_Thinking除非是流量很大的中大公司，不然这种问题，一般还是交给云产商去解决的。作者回复: 你好，sam感谢你的分享，对于这个我持不同意见，个人觉得很少有云能够彻底理解微企业用户业务来提供贴心服务
2023-10-11归属地：广东
我爱吃桃子老师有两个问题。 1 互联网大部分业务场景都是 读多写少，是不是读多活 就已经可以 覆盖大部分场景了？ 2 现在的这种写多活，是不是 基本上都是 单元化来实现了，每个用户 只会 被路由到自己的单元，除非他的单元故障，dns才会强行切到其他单元作者回复: 某个角度来说是这样，读多写少多数属于一个功能中比较频繁访问的情况。独立看起来确实感觉简单，但并不是整个系统都是能满足这个场景，因为还有事务一致性要求，其他情况需要搭配各种业务运营思路技巧，很多情况是组合存在的，这里还少说一个很多情况需要搭配CQRS读写分开思路拆分才可能满足业务需要
2023-06-14归属地：江苏
piboye不同机房时钟有差异，毫秒级别的更新冲突会导致数据丢失吧？作者回复: 你好，piboye，会有这个问题，这里需要注意，客户端在一段时间内只在一个机房活跃就可以避免修改冲突
2023-02-15归属地：广东- zmlmagic加一个更新版本标记位用来破环
作者回复: 那么再深入一点，那么如何保证这个标识是唯一的？
2023-02-15归属地：内蒙古 - Geek_d8ddf2双机房 散热系统要独立，不然一个机房热爆 另一个估计也是热爆，参考阿里云香港教训
作者回复: ：）
2023-01-29归属地：北京
