2018数据库直播大讲堂峰会Redis专场，来自阿里云技术专家夏周为大家介绍了阿里云Redis容灾体系。本文主要分单机房主备容灾、同城双机房容灾和异地多机房容灾&多活三部分进行讲解，其中包括它们的产品定位、架构介绍以及同步优化和内核优化等。
直播视频：https://yq.aliyun.com/video/play/1312
PDF下载：https://yq.aliyun.com/download/2447
以下为精彩视频内容整理：
单机房主备容灾
阿里云Redis双副本容灾形态
阿里云Redis推出了4.0版本，架构上有集群版、标准版和读写分离版。标准版是主备版本，提供最好的Redis命令兼容性，当主节点出现宕机时，HA高可用切换模块会去做故障迁移，将Slave提升为Master，原来的Master恢复后作为新的Slave；集群版架构相对复杂，后端有多个DB节点，每个DB节点架构类似于标准版主备形态，多个DB节点数据需要做路由，就需要多个Proxy节点，集群版还增加一个Configserver，该角色保存了集群间元素信息。当某一个DB节点出现宕机，都会有一个独立的切换模块，并更新Configserver和Proxy的信息；读写分离版只有一个DB节点，一个Master上挂了多个只读节点，当读流量进来时，会根据Proxy判断后端只读节点数量做自动负载均衡，当Master出现宕机时，只读节点需要挂载到新的Master上。
高可用(HA)架构
HA本质上是在做Master故障时、Slave自动提升为主，解决关键问题是判断是否要做切换。HA本身多机房部署，保证自身是高可用的，每个机房会有多个HA模块，每个HA模块负责一部分节点HA切换，当某一个工作HA节点宕机后，另外一些HA节点会做争抢式调度。我们优先同机房HA节点做探测，对于后端Redis的探活逻辑也是有很多种策略的，比如从DNS VIP层面探测后端服务的可用性，也会探测本身DB节点是否存活，以及主机、磁盘是否完好。
独立HA线程优化
阿里云Redis在运营过程中进行了优化，Redis本身是单线程的，当做keys、hgetall等时，Redis很容易出现假死情况，HA可能会误切换。主线程仍然可以做任何操作，我们的优化是专门启动了一个状态线程监测主线程是否存活，也会响应HA模块的探活请求，并探测磁盘可用性。另外，状态线程也会吐出状态信息，保证监控采集不会因为主线程hang住而采集不到信息。
同城双机房容灾
同城双机房容灾的产品定位是：对于业务单元化部署或本身就是单一地域的业务，对容灾有需求，主机房故障时，流量能迅速切换到备机房，主机房恢复时，流量可以切回。
目前Redis同城容灾架构如图。下半部分是Redis本身的架构情况，上半部分是底层传输网络情况。购买Redis后，我们可以取得域名和端口，经过DNS解析走到骨干网，流量再通过LVS集群流到Proxy，最后到后端Master节点。当主机房出现掉电或网络不通时，Redis会有一键切换程序，备机房Slave提升为Master，并调用Configserver接口为Proxy推新的路由信息，也会更新MetaDB的一些信息；底层网络走大小段路由方式，优先选择更为细致的路由，当主机房出现故障时，就不会向主机房上传路由明细信息，骨干网只有备机房大段路由信息，这时就会自动把请求路由到备机房。
同步优化——Log Based Replication
当主机房出现故障时流量切换到备机房，当主机房恢复时都会从备机房做同步。Redis最早提供全量同步机制，整机房全量同步会带来灾难性后果，如果所有的Slave都做全量同步，子进程CPU会跑满，还要疯狂的向恢复的主机房传输的RDB写流量，由于流量太大可能导致备机房服务不可用。
我们目前提供的同步机制对Redis持久化机制做了改造，会有slipshot对应日志位点，AOFbinlog不断做最佳写，当AOFbinlog堆积到一定程度，需要重新做slipshot对其进行清理。AOFbinlog每一个操作写命令会增加一些元数据信息Opid，我们给每一个操作增加一个全局唯一的ID，当Slave出现同步中断时，会通知Master同步Opid位点信息，此时位点已经不是offset信息，Master会判断此Opid是否在AOFbinlog中保存，如果在即异步发送AOFbinlog给Slave，Slave不断从Master本地磁盘读缺失增量，当追上Master同步时，再去内存中把一部分增量拿过来。
总结来看，同步位点借鉴了MySQL GTID，实现全局Opid；性能保证上，查找Opid位点信息是后台线程操作，做到无锁，发送AOFbinlog是异步同步，可以去做限流；同时，我们做到向前、向后兼容，可以做平滑升级、回滚。
Slave和Master的具体通信情况如图，当Slave和Master出现同步中断时，Slave给Master发送PSYNC、runnid、offset和Opid信息，Master根据offset判断backlog是否能满足需求，如果可以满足需求，直接从backlog复制数据发给Slave即可，如果不能满足需求，就会通知Slave开始AOF Psync，Master首先会通过Opid找AOFbinlog中同步位点，然后无锁通知主线程，主线程异步发送AOFbinlog，当Slave追上AOFbinlog后，Master还要同步aof_buf&repl_offset 给Slave。
异地多机房容灾&多活
异地多机房容灾&多活的产品定位是：业务对可用性要求极高，如金融类、部分民生类业务等；允许N-1机房断电，任一机房均能承担所有流量。
异地多活架构如图，上海中心和深圳中心都会有两个Redis集群，可以做到互相同步。底层链路有BLS Manager，上海中心生产一些增量数据，通过Collector写入BLS Tunnel，深圳中心Receiver会从BLS Tunnel中消费增量数据，并写入深圳Master集群，这样，上海中心数据就同步到深圳中心了。同理，深圳中心数据同步到上海中心也是如此。BLS Manager会去做一些调度，比如Collector和Receiver挂掉时，BLS Manager负责拉起或创建新的Collector和Receiver，BLS Manager也会对BLS Tunnel做管理。
内核优化
增量生产
获取增量接口是内核以命令方式原生支持的，是一个标准化get接口，支持现有开源SDK，支持增量过滤，包括库级过滤和key模式匹配过滤。Collector消费增量时，会发送opget opid信息，明确从哪一点开始获取oplog，Redis主线程会创建任务通知后台线程，后台线程基于Opid查找增量位点，无锁通知主线程可以从哪开始读，Redis异步读取AOFbinlog并做解析和封装操作，同时缓存客户端状态，然后回复Collector，Collector下次发送opget opid命令时，就不再需要走上述流程了。
增量消费
增量格式本身兼容Redis协议，目的端接收并且执行就可以了。其中，timestamp做时间点恢复。增量消费要避免两个问题：一是复制回源，不能让A复制给B的再从B复制回A，我们会标识标识oplog来源实例（server_id)，如果复制回源，直接丢弃即可；一是环形复制，如何避免C通过B复制的数据再次返回A，我们记录了每一个src_server_id，以及src_server_id在C上max_opid情况，通过判断是否发生环形复制。
本文由云栖志愿小组毛鹤整理，编辑百见
