《Seckill秒杀系统》第118章：容灾架构设计与落地方案

作者：冰河
星球：http://m6z.cn/6aeFbs (opens new window)
博客：https://binghe.gitcode.host (opens new window)
文章汇总：https://binghe.gitcode.host/md/all/all.html (opens new window)
源码获取地址：https://t.zsxq.com/0dhvFs5oR (opens new window)

沉淀，成长，突破，帮助他人，成就自我。

• 本章难度：★★☆☆☆
• 本章重点：了解系统异地容灾的场景，及其落地实现方案，从整体上理解异地容灾的难点、思路和部署方案，重点掌握同城双活和异地多活两种部署方案，从高可用的角度深度思考异地容灾背后的核心架构与设计原理。

大家好，我是冰河~~

不只是秒杀系统，在某种程度上，只要是比较重要的系统，都需要考虑系统的容灾问题。通过实施容灾方案，将系统部署两套或者多套，并且这套系统或者多套系统可以部署到不同的机房，如果其中一套系统出现故障导致不可用，则可以迅速切换到另一套系统，提供7*24小时不间断服务。

一、前言

同城双活和异地多活都是典型的系统容灾部署方案，对于企业来说，尤其是大型互联网公司，比较重要的系统一般都会做容灾，采用同城双活，甚至异地多活的架构方案进行部署。对于同城双活和异地多活来说，都是容灾的不同方案，它们对技术、部署成本、运维成本、网络带宽、网络稳定性等的要求都不一样。多多少少都会增加部署的复杂度和部署成本，但是，容灾在某套系统出现故障时，能够迅速切换到另一套系统，保证系统的高可用。

二、本章诉求

介绍系统的容灾架构设计与落地部署方案，了解异地容灾的难点、思路和部署方案，重点掌握同城双活和异地多活部署方案，结合自身实际项目思考容灾的使用场景及其背后的核心架构与设计原理。

三、宕机问题

企业的核心系统和比较重要的系统应该也必须考虑容灾问题，这里的容灾主要是通过部署两套或者多套系统实现，这两套或者多套系统一般是部署在不同的机房，避免只部署一套系统或者在同一机房部署多套系统出现宕机事故。

在实际场景中，哪怕我们部署了两套或者多套系统，但是这些系统是部署在同一个机房内，此时系统的可用性是受限于机房的可用性，如果机房出现网络不通或者其他事故，就会影响到系统的可用性，甚至造成系统长时间宕机。这种系统事故不是人为造成的，但是如果不考虑容灾问题，或者容灾问题考虑不充分，将两套或者多套系统部署在同一个机房内就可能出现这种问题。

举个例子，如果已经考虑到容灾的问题，只是将两套或者多套系统部署在同一个机房中，如果这个机房的网络或者服务器出现了故障，机房发生了火灾，甚至机房所在的城市发生了地震、海啸、洪水等不可抗力的灾难时，哪怕部署在同一个机房内的多套系统之间实现的可用性再高，整个系统也是不可用的。

四、跨机房部署

跨机房部署，顾名思义就是将两套或者多套系统部署在多个机房，跨机房部署其实并没有想象中的那么简单和美好，实际上，将两套或者多套系统部署在多个机房是有一定的复杂度和挑战的。以数据库为例，假设目前有两个机房，分别为机房A和机房B，数据库主库A和从库B都在A机房，那么B机房的应用如何读取到数据呢？此时，总体上有两种方案：跨机房读取数据和本机房内读取数据。

4.1 跨机房读取数据

如果是跨机房读取数据的话，B机房中的应用就会跨机房读取A机房的数据，如图118-1所示。

可以看到，此时B机房的应用会跨机房读取A机房的数据。

4.2 本机房内读取数据

如果是本机房内读取数据，则可以在B机房中部署一个从库，B机房中的从库跨机房同步A机房的数据，随后，B机房的应用读取本机房中从库的数据，如图118-2所示。

查看完整文章

加入冰河技术 (opens new window)知识星球，解锁完整技术文章与完整代码