Implementação de espelhamento de tráfego Redis

fundo

Reduzir custos e aumentar a eficiência em cenários Redis envolve a migração de algumas instâncias Redis para projetos de armazenamento em disco SSD (Alibaba Cloud Tair) que suportam o protocolo Redis, como o pika da comunidade, para reduzir custos de armazenamento. O processo de migração requer verificação de desempenho.Além da seleção básica e dos testes de estresse, a cobertura completa do desempenho das instruções deve ser realizada para cada cenário de negócios, a fim de garantir o desempenho da migração de negócios e a estabilidade da compatibilidade das instruções. A abordagem convencional é exigir que o desenvolvimento empresarial coopere no projecto para realizar tráfego duplo, ou tráfego em escala de cinzentos numa pequena área.

Independentemente do problema acima, mais mão de obra e tempo precisam ser investidos, o que reduz bastante o ROI em termos de redução de custos e melhoria da eficiência em si. Se for possível reproduzir diretamente todo o tráfego de leitura do Redis original para a instância SSD do Redis de destino, então a migração de todo o evento SRE pode ser 99% concluída e o tempo de migração da instância será bastante reduzido, então o surge a necessidade de espelhamento de tráfego do Redis.

Dicas: Nossa solução de migração de dados usa DTS do Alibaba Cloud. O DTS é implementado com base no princípio de replicação mestre-escravo Redis, para que o desempenho do tráfego de gravação possa ser verificado diretamente durante o processo de sincronização de dados.

Pesquisar

Naveguei no Google e no Github, mas não encontrei nada muito adequado, então finalmente decidi fazer minha própria pesquisa. Algumas informações relevantes encontradas são as seguintes:

Registro de auditoria SLS Redis do Alibaba Cloud

A instância Redis do Alibaba Cloud suporta o envio de logs de execução Redis para SLS (um produto de gravação e consulta de log) para gravação, mas registra apenas o tráfego de gravação, o que não atende aos requisitos de reprodução de tráfego de leitura do Redis.

ferramenta pika redis-copy: https://github.com/OpenAtomFoundation/pika/issues/2044

Esta ferramenta foi descartada pelo projeto pika. Atualmente existem apenas documentos e não existe nenhum código relevante no armazém. No entanto, a implementação deste artigo também se baseia no mesmo princípio de implementação do pika.

istio implementa espelhamento de tráfego Redis: https://github.com/cloudnativeto/cloudnativeto.github.io/issues/76

O tráfego de espelhamento do Redis baseado no istio deve estar conectado ao istio. As limitações são muito grandes e a introdução de um novo componente istio requer muitos testes de estabilidade, portanto, essa rota é diretamente rejeitada.

concluir

Vá diretamente ao tópico e use o comando monitor do Redis para atender a esse requisito.

/**
 * @author kl (http://kailing.pub)
 * @since 2023/9/27
 */
public class RedisMonitorTest {

    static final JedisPool targetRedisPool = new JedisPool("127.0.0.1", 6398);
    static final JedisPool sourceRedisPool = new JedisPool("127.0.0.1", 6379);
    static final Set<String> redisReadCommands = new HashSet<>(Arrays.asList(
            "get", "strlen", "exists", "getbit", "getrange", "substr", "mget", "llen", "lindex",
            "lrange", "sismember", "scard", "srandmember", "sinter", "sunion", "sdiff", "smembers",
            "sscan", "zrange", "zrangebyscore", "zrevrangebyscore", "zrangebylex", "zrevrangebylex",
            "zcount", "zlexcount", "zrevrange", "zcard", "zscore", "zrank", "zrevrank", "zscan", "hget",
            "hmget", "hlen", "hstrlen", "hkeys", "hvals", "hgetall", "hexists", "hscan", "randomkey",
            "keys", "scan", "dbsize", "type", "sync", "psync", "ttl", "touch", "pttl", "dump", "object",
            "memory", "bitcount", "bitpos", "georadius_ro", "georadiusbymember_ro", "geohash",
            "geopos", "geodist", "pfcount", "xrange", "xrevrange", "xlen", "xread", "xpending",
            "xinfo", "lolwut"
    ));
    
    public static void main(String[] args) {
            try (Jedis jedis = sourceRedisPool.getResource()) {
                jedis.monitor(new JedisMonitor() {
                    @Override
                    public void onCommand(String command) {
                        sendCommand(command);
                    }
                });
            }
    }
    
    public static void sendCommand(String commandStr) {
        String[] parts = commandStr.split("\"");
        if (parts.length < 2) {
            return;
        }
        String cmd = parts[1];
        List<String> args = new ArrayList<>();
        for (int i = 3; i < parts.length; i += 2) {
            args.add(parts[i]);
        }
        if (redisReadCommands.contains(cmd.toLowerCase())) {
            ProtocolCommand command = () -> cmd.getBytes(StandardCharsets.UTF_8);

            try (Jedis jedis = targetRedisPool.getResource()) {
                try {
                    long startTime = System.currentTimeMillis();
                    jedis.sendCommand(command, args.toArray(new String[0]));
                    System.out.println(cmd + ":" + (System.currentTimeMillis() - startTime));
                } catch (Exception e) {
                    System.err.println(cmd + e.getMessage());
                }
            }
        }
    }
}

O texto acima é um pseudocódigo que pode ser executado diretamente para encaminhar todo o tráfego de leitura de sourceRedis para targetRedis para execução.

Implementar análise

O cliente Java Redis jedis usado acima é desenvolvido. Primeiro, o comando monitor é chamado. Este comando é um comando de bloqueio e sempre assinará o registro de execução de comando do servidor Redis. O formato de registro é o seguinte:

1695869359.747056 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869359805247076" "LIMIT" "0" "1"
1695869359.748040 [0 127.0.0.1:64257] "EXISTS" "asynq:{sys}:paused"
1695869359.748259 [0 127.0.0.1:64257] "EXISTS" "asynq:{sync}:paused"
1695869359.748578 [0 127.0.0.1:64257] "EXISTS" "asynq:{default}:paused"
1695869359.748916 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869359869190783" "LIMIT" "0" "1"
1695869359.749154 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869359877625076" "LIMIT" "0" "1"
1695869359.749348 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869359878760313" "LIMIT" "0" "1"
1695869359.749530 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869359882064571" "LIMIT" "0" "1"
1695869359.779048 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869360024586886" "LIMIT" "0" "1"
1695869359.785898 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869360031603858" "LIMIT" "0" "1"
1695869359.786092 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869360031656719" "LIMIT" "0" "1"
1695869359.786923 [0 127.0.0.1:64257] "ZRANGEBYSCORE" "delayed_tasks" "0" "1695869360031666910" "LIMIT" "0" "1"

Portanto, só precisamos analisar as instruções e enviá-las para a instância de destino.

Há também uma questão envolvida aqui: como filtrar registros apenas com instruções de leitura?

Tentei perguntar ao chatGPT, mas não era nada confiável, ou faltava o comando de leitura ou outros comandos de gravação foram usados para compor o número. Então não é confiável. Felizmente, o servidor Redis marca cada instrução para distinguir entre instruções de leitura e instruções de gravação.

Portanto, basta imprimir todas as instruções somente leitura no console e copiá-las para resolver o problema.

Precauções

O comando monitor Redis é um comando que prejudica o desempenho do Redis. O teste oficial reduzirá o desempenho de uma única instância do Redis em cerca de 50%. No meu teste real, quando a carga real do Redis não é alta, esse impacto é insignificante (especialmente com QPS alto). Use exemplos com cautela). Porque o QPS autônomo do Redis pode suportar 10W. Por exemplo, QPS 1W em tempo real on-line, ao usar o monitor, QPS e RT quase não sofrem alterações.

Além disso, deve-se ressaltar que rodar o monitor por muito tempo aumentará o consumo de memória do Redis, portanto, se você estiver fazendo verificação de desempenho, é melhor controlar o tempo e não rodar o tempo todo.

documentação do monitor: https://redis.io/commands/monitor/

Conclusão

Neste blog, discutimos o método de implementação do espelhamento de tráfego Redis e sua importância na redução de custos e aumento de eficiência. Aprendemos que os métodos de verificação tradicionais exigem muito investimento de mão de obra e tempo ao migrar instâncias do Redis, o que reduz o ROI da redução de custos e melhoria da eficiência. Para resolver este problema, foi introduzido o requisito de espelhamento de tráfego Redis.

Ao reproduzir todo o tráfego de leitura do Redis original diretamente para a instância SSD do Redis de destino, podemos concluir com eficiência o processo de migração da instância, reduzir a carga de trabalho do SRE e reduzir significativamente o tempo de migração. Este método não só melhora a eficiência do processo de migração, mas também reduz custos e riscos, tornando o objectivo de redução de custos e melhoria da eficiência mais viável e alcançável. Ao adotar essa abordagem, podemos migrar instâncias do Redis com mais eficiência e manter o desempenho e a estabilidade dos negócios, ao mesmo tempo que reduzimos custos e melhoramos a eficiência.

Obrigado por ler! Se você tiver alguma dúvida ou ideia, fique à vontade para deixar um comentário.