mysql 和 redis双活方案

背景：

异地双活是一个预防单机房故障的有效的手段，但是其实真正实施起来困难重重，本文我们就从DBA的角度来看怎么看怎么支持数据库(包括mysql和redis集群)的双活.

技术实现：

mysql双活：

mysql的双活采用的是主从的模式，我们假设有两个机房A和机房B，只有机房A的mysql数据库是主节点，机房B的mysql数据库则是从节点，机房A和机房B的mysql数据库的数据同步采用异步复制的方式来实现，架构图如下所示：
注意事项：这里需要意识到机房B的应用写mysql数据库是跨机房写，每个mysql操作会有几ms的网络延迟，应用需要尽量使用批操作,比如一次insert多条记录，后者一次update多条记录,此外机房B的mysql从库也可以对外提供应用访问，如果应用能接受从数据库的延迟的话(正常没有大事务的话延迟一般是1-5分钟,但是没法保证从库的延迟上限).

redis双活:

redis的双活采用的每个机房部署一套独立的redis cluster集群的形式，每一套redis cluster集群内部有自己的主从节点作高可用设计,两套redis cluster集群之间没有任何交互，以下是redis双活的架构图：

注意事项：为了性能起见，每个机房写Redis的时候都是使用同步写本地Redis机房，异步写异地Redis机房的形式，由于异步写异地机房涉及到多次重试写，所以需要redis的命令是幂等的，比如set/hset等操作，但是比如lpop，lpush等命令就不能使用了，这其实会极大的限制redis的使用场景.

最后，我们再来说说为什么Redis集群的双活没有采用类似Mysql主从复制的方案？

1.redis的主从复制有一个最大的复制缓冲区(默认1M)，当主节点执行大量写命令或者从节点断线后经过较长时间才能连接上主节点时，导致堆积的写命令大于复制缓冲区的大小时，就会导致主从进行全量复制，此时主节点会fork子进程(如果进程比较大，这一步可能造成主节点卡顿)来生成RDB文件,会耗费大量的CPU和IO资源,此外,不同机房之间传输RDB文件会造成网络带宽的极大压力.

2.一个Redis Cluster的主节点可能分布在不同的机房中，某个机房对Redis的读写访问可能都是跨机房的形式，每个读写操作都会有几ms的延迟，这对于使用redis来提高读写访问的性能的来说是很难接受的，毕竟一个redis的命令的正常耗时也就是0.1-0.5ms

3. Redis Cluster集群内部的节点状态变更是通过Gossip协议广播的形式通知其他的节点的，比如有新节点加入，某个master宕机导致的某台slave节点提升为master节点，slot槽位迁移时，这些信息如果由于机房间网络故障的缘故导致很长时间才能同步到，那么应用在此期间访问Redis Cluster节点就会发生比如重定向Move命令过多等错误.