本文探讨了多机房多活架构的设计与实施，旨在降低跨机房调用带来的延迟问题。理想状态下的“同机房连接”通过异步数据同步实现全量数据冗余，但在有全局业务数据访问场景下，会存在数据不一致。伪多机房多活架构通过“最小化”跨机房调用来平衡，适合读多写少的业务，提供了一种更易落地的解决方案。
前情提要：
《当年，我们是怎么平滑上云的？》一文中提到了上云的背景，将所有的系统，从一个机房，迁移到另一个机房。
如上图：
迁移之前，系统部署在机房A（M6）内，是单机房架构。
迁移之后，系统部署在机房B（阿里云）内，换了一个机房。
《当年，我们是怎么平滑上云的？》有三结论：
（1）单机房架构的核心是“全连接”；
（2）机房迁移方案的设计目标是：平滑迁移，不停服务；可以分批迁移；随时可以回滚；
（3）想要平滑的实施机房迁移，临时性的多机房架构不可避免；
【4】核心问题四，临时性多机房架构如何实施？
如前文所述，如果将单机房“全连接”架构复制到多机房，
最低0.47元/天 解锁文章
2359
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
