今天 B 站和小红书崩了，面试官问我怎样避免故障导致的影响？？？

大家好，我是鸭鸭！

今天 10 点多就有好多朋友发圈吐槽 B 站又双叒叕蹦啦！但是 B 站这次不孤单，祸不单行，陪伴它的是小红书同学~

根据鸭鸭上网冲浪查到，这次的事故可能是阿里云导致的，啧啧一次瓜出现了三个大厂，鸭鸭吃的可真香！

从时间上来看，阿里云上海网络故障时间和 B 站、小红书故障时间是吻合的，B 站和小红书的总部也刚好在上海，但是说好的异地多活呢？？？

鸭鸭身为一个面试鸭，在吃瓜的同时，也时刻心系面试！万一最近去面试，面试官们拿这次故障事件考验我们同学咋办？

例如：你如何看待这次事故，怎样才能避免故障导致的影响？

不要慌，这不鸭鸭就来了！就下来就请看鸭鸭的表演！它本质上的考点是异地多活。

异地多活

异地多活其实是一种网络架构和数据管理策略，从专业名词的角度来讲，它的目的是在地理上分布的多个数据中心同时运行相同的应用或服务，并保持数据的一致性和可用性。

讲白了把服务器在上海部署一份，深圳也部署一份，多个数据中心之间的数据需要实时或接近实时地同步，确保数据的一致性。

然后在正常情况下，用户可以从任何地理位置访问最近的数据中心。

如果出现今天这种情况，上海的机房出了故障，那么就让北京的用户去访问深圳的机房，这样北京的用户就能正常访问服务啦！

听起来是不是一个很美妙的设计？它可以保证在自然灾害或者其他突发的情况下，数据和服务不会丢失，从而实现快速恢复，减少停机时间和业务损失。

但是，这些好处的背后，其实也带来了非常多的挑战！

首先是数据一致性问题，因为需要保持多个数据中心之间的数据一致性是一个非常复杂的问题！尤其是在网络延迟和分区故障情况下。

并且在一些需要强一致性的场景，例如金额充值，服务之间的强一致性的同步会带来额外的延迟，影响性能。

并且多地的实时数据同步，还需要足够的带宽来支撑，得花一定的成本。

再者，异地多活系统在部署和管理方面，也带来足够的挑战，以前就管理发布一个地方，现在多个地方需要打通部署等等，需要一定的技术能力和管理经验。

虽然异地多活有些挑战，但是对那些需要高可用、高可靠的大型系统来说，是一个针对突然状况的有效解决方案！

好了，对异地多活了解到这个地步就差不多啦~

最后

最近鸭鸭整了一个面试小程序，已经有近 1500 道面试题目啦，欢迎大家来阅读！

我是鸭鸭，我们下期见~