大白话讲异地多活方案

徐良永

目录

① 为什么要做异地多活

② 有状态系统与系统sharding

③ 跨机房数据库主备

④ 总结

为什么要做异地多活？

如果我们只在一个机房部署项目，机房断电或断网，那么我们所有的客户是不是都无法访问了呢？ 大家想一想是不是这样？

而如果有两个以上的机房同时提供服务，就会避免这种情况了

那异地多活应该怎么做呢？

话不多说 先看图

下图是异地多活的示意图，我们要实现的目标是：

一个机房挂了，另外两个机房都能接管挂掉机房的服务

那应该怎么设计呢？

有状态系统与系统sharding

关于软件系统的状态

一个软件系统如果不需要登陆认证，就可以读写，那么我们认为这个系统是无状态的

如果需要登陆认证，才能读写，我们认为是有状态的

很显然很多系统是徘徊在两者之间的，不登陆时只提供浏览服务，登陆能才可以写

我们下面讨论的都是有状态系统

如果系统是有状态的，那么我们的异地多活就可以按照状态的某个属性sharding，我们还是用一张图来表示吧

下图中我们按照用户名维度 sharing到三个机房

那么这三个机房的数据库将会分别存储一部分用户数据

三个机房的数据库合并在一起才是所有数据

这样的话如果一个机房挂掉，那么存储在这个机房的所有用户都不能访问系统了，大家想一下是不是这个道理。

那怎么办呢？ 

很简单 夸机房数据备份 这个问题我们下一节讲

我们还是看上面的图

先看‘系统服务层’，如果把系统服务层看做一个独立系统的话，其实系统服务层是无状态的，系统的状态都保存在db中，它只是作为计算资源而存在的

我们再看系统web层，系统web层是有状态的，保存了用户session数据，但是这些数据与保存在db中的数据还不太一样，多数是一些缓存数据或者临时数据，换句话说这是数据丢了后果也是可控的，我们把系统web层称为准无状态的

如果把无状态的服务层和准无状态的web层拿掉我么的系统架构图会简化为下图

这样的话，异地多活 最核心要解决的问题就是数据库的问题

跨机房数据库主备

异地多活的底层原理类似于分布式系统

了解分布式系统的小伙伴都知道，为了保证高可用，每份数据都存在一到多个副本

同理，异地多活在数据库sharding的基础上也在加上副本就满足了CAP理论的AP 即  可用性和分区容错性

我们来看新的带数据库副本的架构图

上图可以看到每个机房有两个数据库，上面的是主库，下面的是其他机房的备库

主备保持同步，主库所在机房挂掉后，备库会提升为主库

如下图

北京机房挂掉后，会把北京数据库副本提升为主数据库，这要上海 广州两个机房对外仍然能够提供完整的服务，不会出现数据无法访问的情况

总结

异地多活是个复杂的工程，我们这里只是讲了点基础原理，真正实践是会遇到很多问题

比如同步延时导致读不到数据等

对于实时性比较强的读可能要强制路由到主库读

正是因为异地多活的复杂性，我们在选择部署业务系统是要排优先级，最核心的业务优先，对于非核心业务搞个热备，甚至冷备都可以

ok 打完收工！

扫码关注公众号!