行业案例：OPPO缓存层6次版本迭代的异地多活实践 .pdfVIP

OPPO缓存层6次版本迭代的异地多活实践

前言

互联网后台服务的常用经典架构中，整个后台服务框架一般可以分四层：

接入层，一般用于请求的安全校验、频率和流量控制

逻辑层，用于用户数据的请求和返回逻辑控制

缓存层，为了加快访问性能，cache用户数据，常见的redis、memcache等

存储层，落地了用户各种数据，比如mysql、leveldb等

关于异地多活考虑这样一个常见问题，假设某当地机房的服务全部宕机（机房掉电或光纤挖断）了，这

个时候怎么挽救？比如上海登陆服务宕机了，总不能让上海的用户无法登陆。很显然我们要把后台的请

求流量切换到别的机房，当然后台的4层架构每一层的切换场景都不太一样。

缓存层的作用是为了加速访问性能，减轻对存储的访问压力。如果直接把流量切换到别的机房可能会由

于缓存命中率太低，把处于底层的存储层打爆，严重影响机房的服务。如何解决这些问题，这个就是本

篇文章要讨论的话题。

本篇主要围绕数据的一致性和数据的安全性等2个主要挑战，通过版本迭代的方式来阐述缓存层的多机

房异地多活会遇到的一些问题。

1）一致性

在多机房中，机房之间的网络延时不确定性大；各个机房物理条件可能也不一样；多机房服务运行的状

态也会不一样。如何保障在各种异常和不确定性的情况下还能保障数据的一致性是本篇重点要讨论的话

题。

2）安全性

Google在GFS的论文开篇也说过类似的前提：“服务异常或者硬件故障有可能是常态”，如何保障已经写

入的数据在异常的常态下还能恢复也是本篇的另外一个重点。

起源版本

基于本篇要讨论的是缓存层异地多活问题，而redis目前比较常用，所以我们这里以redis作为缓存层的

例子来说明问题。

内存数据是个断电易失的，我们很容易想到的第一个版本：我们先把写入数据（修改和删除统称为写

入）写到磁盘，然后用另外一个进程读取磁盘数据发送到其它机房，如下图：

如此，我们的第一个起源版本就做好了，要在生产环境运行还需要解决几个问题。

第一个问题“同步进程”有可能被重启(代码bug或者其它多方面的原因)，重启后“同步进程”进程从

哪里开始重新同步呢？

第二个问题是数据可能不完整，比如像redis会有aofrewrite，删除原来的aof生成新的aof文件，

老的aof文件会被删除而只保留新的aof，这样老aof的offset在新aof文件就无效了。

版本一

针对上面起源版本问题我们做一些解决办法。

可靠的DB

我们引入一个DB，把同步进程每次同步的位置写入到DB里面去，同步进程重启的时候首先从DB找到自

己的offset，然后从offset后面开始数据同步就可以了。

流水记录

参考mysql的方式，把所有的写入数据按照时间的先后用流水日志的方式记录下来不能被修改，在没有

同步到别的机房前也不能被删除。

经过上面的修改后我们得到修改版本一。

把修改版本一放到生产环境跑了几天后，又会发现一些问题：

性能低下

同步进程每次同步一条数据都要修改Mysql同步offset，导致同步进程性能低下

单机磁盘空间不够

因为物理机器上会混部多个服务，每个服务都在往磁盘写入数据

跨机房同步本身又比较慢

可能导致单机磁盘空间被打爆，磁盘被打爆后数据再也无法写入了。

数据回环

ServerA的数据被同步进程A同步到B机房以后，被写入到数据流水B，然后同步进程B又把这个流水同

步给了A机房，就这样形成了一个循环回路浪费了网络带宽和资源。

如上图，A机房写入的数据同步到B机房后又回流到了A机房。

版本二

1、解决流水问题

针对版本一的2个问题，我们做一些方法来解决。

同步offset定时