Redis如何实现异地多活?（redis异地灾备）

背景

业务在多数据中心下经常需要做到双活，例如账号信息、认证信息等读多写少的场景。但是分布式场景下做到双活必然会面对下面的几个核心问题：

延迟：异地多活面临的主要挑战是网络延迟，以北京到上海 1468 公里，即使是光速传输，一个来回也需要接近10ms，在实际测试的过程中，发现上海到北京的网络延迟，一般是 30 ms。

一致性：用户在任何一个机房写入的数据，是否能在任何一个机房读取的时候返回的值是一致性的。

行业架构方案

方案1

此方案很直观，让业务进行写入MQ, 通过DTS同步组件进行多地域数据同步, 再基于MQ进行数据的分发。

缺点：业务方需要自行实现数据分发功能，写入到MQ，对业务有较大侵入。

方案2

此方案架构是通过Reader对Redis进行两地的数据同步（读取slave，写入master）, 每个需要同步的地域都需要有一个对应的Reader来接收数据。

缺点：可扩展性差, 压力随着同步地域数增加而线性增加。

方案3

此方案是Netflix开源实现的dynomite，通过代理层接受数据后写入各个需要同步的节点。

优势：上层业务无感知，底层redis数据自动同步；

劣势：客户端需要优化添加Dyno Client(例如基于hash切分的redis集群方案就需要接入)、服务端每个节点需要部署Dyno Node、数据存在冗余同步(无需同步的数据会被纳入同步)、如果不冗余就需要接入方标准不一致，运维不统一(有些部署Dynomite ，有些不部署)、read/write性能较原生差异较大，主要体现在write上，之间的差异随着node节点数越多越严重。

优化架构方案

所有的数据写入到redis，数据同步对业务层透明，主要包括redis事件监听及写入服务、MQ及消息同步组件。

Redis监听服务

Redis的监听服务主要实现对redis的更新、删除、添加及过期时间和消息的监听，我们以spring整合redisTemplate针对消息删除操作进行举例：

import org.springframework.context.ApplicationEventPublisher;
import org.springframework.context.ApplicationEventPublisherAware;
import org.springframework.data.redis.connection.Message;
import org.springframework.data.redis.core.RedisKeyExpiredEvent;
import org.springframework.data.redis.listener.KeyspaceEventMessageListener;
import org.springframework.data.redis.listener.PatternTopic;
import org.springframework.data.redis.listener.RedisMessageListenerContainer;
import org.springframework.data.redis.listener.Topic;
import org.springframework.lang.Nullable;


public class KeyDeleteEventMessageListener extends KeyspaceEventMessageListener implements ApplicationEventPublisherAware {
    //采用PatternTopic对del事件进行监听
    private static final Topic KEYEVENT_DELETE_TOPIC = new PatternTopic("__keyevent@*__:del");
    @Nullable
    private ApplicationEventPublisher publisher;


    public KeyDeleteEventMessageListener(RedisMessageListenerContainer listenerContainer) {
        super(listenerContainer);
    }


    protected void doRegister(RedisMessageListenerContainer listenerContainer) {
        listenerContainer.addMessageListener(this, KEYEVENT_DELETE_TOPIC);
    }


    protected void doHandleMessage(Message message) {
        this.publishEvent(new RedisKeyExpiredEvent(message.getBody()));
    }


    protected void publishEvent(RedisKeyExpiredEvent event) {
        if (this.publisher != null) {
            this.publisher.publishEvent(event);
        }


    }


    public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
        this.publisher = applicationEventPublisher;
    }
}

Redis的通知事件分为键空间和键事件：

键空间通知，所有通知以 keyspace@ 为前缀；

键事件通知，所有通知以 keyevent@ 为前缀；

所有命令都只在键真的被改动了之后，才会产生通知，比如删除foo会产生：

键空间通知

“pmessage”,"__ key*__ : * “,”__ keyspace@0__:foo",“set”

和键事件通知

“pmessage”,"__ key*__ : *","__ keyevent@0__:set",“foo”

由于我们这边关注的是key，获取到key后可以依据key查询到value，进而获取全部数据实现同步，所以是keyevent@ 为前缀，接下来是对KeyDeleteEventMessageListener 重写其onMessage方法以获取key，如下：

public class RedisKeyDeleteListener extends KeyDeleteEventMessageListener {


    public RedisKeyDeleteListener(RedisMessageListenerContainer listenerContainer) {
        super(listenerContainer);
    }


    /**
     * 针对redis数据删除事件，进行数据处理
     * @param message message.toString()获取失效的key
     * @param pattern
     */
    @Override
    public void onMessage(Message message, byte[] pattern) {
        String deleteKey = message.toString();
        // ......
        }
    }
}

MQ及数据同步组件

我们采取的是kafka及其同步组件MirrorMaker，redis监听到的数据只需要写入到对应的同步topic即可，接下来MirrorMaker会针对多机房的topic同步策略进行数据同步。

数据如何保障不重复？

例如数据为了保障可用，出现故障会进行重试，如何保障幂等？

对于kafka可以开启enable.idempotence=true，相当于是开启生产者的幂等生产，同时ack可选择-1，同时为了提升吞吐量可将max.in.flight.requests.per.connection设置为大于1。

数据如何提升同步时延？

例如业务场景需要数据在1分钟之内进行同步完成。

这种场景方案1：可对key设置一个时间戳，当请求发生时，获取value，并解析出时间戳，如果time=当前时间戳 - 时间戳 大于1分钟，那么依据key直接请求到对应机房主动加载。

方案2：定时主动刷新，将所有待同步的数据key刷入到一个db，定时依据key是否跨机房存储，从指定机房主动加载过来（适合较小key的范围）。

数据同步如何实现防环？

数据的防环主要是指，当从A机房redis读取的数据，通过MQ同步到B机房写入后，B机房的监听服务又获取到，再次同步到A机房，导致数据循环复制问题。

解决这个问题可以采取数据添加数据源标记，例如source字段，通过该字段标记为是从哪个机房同步过来，如果是发现数据从远端同步过来的，即使redis监听服务获取到该事件的key也会丢弃，不做同步处理。

转载https://mp.weixin.qq.com/s?__biz=MzI5NzkzOTMwNQ==&mid=2247483771&idx=1&sn=d7459fd3fcc6166c2bf45a0024029281&chksm=ecac397ddbdbb06b000676cad774036439dd621ef24feb130af3d21b56f85651a8dead968573&scene=21#wechat_redirect