Redis Cluster基于客户端对mget的性能优化

这篇具有很好参考价值的文章主要介绍了Redis Cluster基于客户端对mget的性能优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1 背景

Redis是知名的、应用广泛的NoSQL数据库,在转转也是作为主要的非关系型数据库使用。我们主要使用Codis来管理Redis分布式集群,但随着Codis官方停止更新和Redis Cluster的日益完善,转转也开始尝试使用Redis Cluster,并选择Lettuce作为客户端使用。但是在业务接入过程中发现,使用Lettuce访问Redis Cluster的mget、mset等Multi-Key命令时,性能表现不佳。

2 分析原因

2.1 现象

业务在从Codis迁移到Redis Cluster的过程中,在Redis Cluster和Codis双写了相同的数据。结果Codis在比Redis Cluster多一次连接proxy节点的耗时下,同样是mget获取相同的数据,使用Lettuce访问Redis Cluster还是比使用Jeds访问Codis耗时要高,于是我们开始定位性能差异的原因。

2.2 定位问题

2.2.1 Redis Cluster的架构设计

导致Redis Cluster的mget性能不佳的根本原因,是Redis Cluster在架构上的设计导致的。Redis Cluster基于smart client和无中心的设计,按照槽位将数据存储在不同的节点上

Redis Cluster基于客户端对mget的性能优化,redis,性能优化,数据库

如上图所示,每个主节点管理不同部分的槽位,并且下面挂了多个从节点。槽位是Redis Cluster管理数据的基本单位,集群的伸缩就是槽和数据在节点之间的移动。

通过CRC16(key) % 16384计算key属于哪个槽位和哪个Redis节点。而且Redis Cluster的Multi-Key操作受槽位限制,例如我们执行mget,获取不同槽位的数据,是限制执行的:

Redis Cluster基于客户端对mget的性能优化,redis,性能优化,数据库

2.2.2 Lettuce的mget实现方式

lettuce对Multi-Key进行了支持,当我们调用mget方法,涉及跨槽位时,Lettuce对mget进行了拆分执行和结果合并,代码如下:

public RedisFuture<List<KeyValue<K, V>>> mget(Iterable<K> keys) {
    //将key按照槽位拆分
    Map<Integer, List<K>> partitioned = SlotHash.partition(codec, keys);

    if (partitioned.size() < 2) {
        return super.mget(keys);
    }

    Map<K, Integer> slots = SlotHash.getSlots(partitioned);
    Map<Integer, RedisFuture<List<KeyValue<K, V>>>> executions = new HashMap<>();
	   //对不同槽位的keys分别执行mget
    for (Map.Entry<Integer, List<K>> entry : partitioned.entrySet()) {
        RedisFuture<List<KeyValue<K, V>>> mget = super.mget(entry.getValue());
        executions.put(entry.getKey(), mget);
    }

    // 获取、合并、排序结果
    return new PipelinedRedisFuture<>(executions, objectPipelinedRedisFuture -> {
        List<KeyValue<K, V>> result = new ArrayList<>();
        for (K opKey : keys) {
            int slot = slots.get(opKey);

            int position = partitioned.get(slot).indexOf(opKey);
            RedisFuture<List<KeyValue<K, V>>> listRedisFuture = executions.get(slot);
            result.add(MultiNodeExecution.execute(() -> listRedisFuture.get().get(position)));
        }

        return result;
    });
}

mget涉及多个key的时候,主要有三个步骤:

1、按照槽位 将key进行拆分;

2、分别对相同槽位的key去对应的槽位mget获取数据;

3、将所有执行的结果按照传参的key顺序排序返回。

所以Lettuce客户端,执行mget获取跨槽位的数据,是通过槽位分发执行mget,并合并结果实现的。而Lettuce基于Netty的NIO框架实现,发送命令不会阻塞IO,但是处理请求是单连接串行发送命令:

Redis Cluster基于客户端对mget的性能优化,redis,性能优化,数据库

所以Lettuce的mget的key数量越多,涉及的槽位数量越多,性能就会越差。Codis也是拆分执行mget,不过是并发发送命令,并使用pipeline提高性能,进而减少了网络的开销。

3 解决问题

3.1使用hashtag

我们首先想到的是 客户端分别执行分到不同槽位的请求,导致耗时增加。我们可以将我们需要同时操作到的key,放到同一个槽位里去。我们是可以通过hashtag来实现

hashtag用于Redis Cluster中。hashtag 规定以key里{}里的内容来做hash,比如 user:{a}:zhangsan和user:{a}:lisi就会用a去hash,保证带{a}的key都落到同一个slot里

利用hashtag对key进行规划,使得我们mget的值都在同一个槽位里。

Redis Cluster基于客户端对mget的性能优化,redis,性能优化,数据库

但是这种方式需要业务方感知到Redis Cluster的分片的存在,需要对Redis Cluster的各节点存储做规划,保证数据平均的分布在不同的Redis节点上。对业务方使用上太不友好,所以舍弃了这种方案。

3.2 客户端改造

另一种方案是在客户端做改造,这样做成本较低。不需要业务方感知和维护hashtag。

我们利用pipeline对Redis节点批量发送get命令,相对于Lettuce串行发送mget命令来说,减少了多次跨槽位mget发送命令的网络耗时。具体步骤如下:

1、把所有key按照所在的Redis节点拆分;

2、通过pipeline对每个Redis节点批量发送get命令;

3、获取所有命令执行结果,排序、合并结果,并返回。

这样改造,使用pipeline一次发送批量的命令,减少了串行批量发送命令的网络耗时。

3.2.1 改造JedisCluster

由于Lettuce没有原生支持pipeline批量提交命令,而JedisCluster原生支持pipeline,并且JedisCluster没有对Multi-Key进行支持,我们对JedisCluster的mget进行了改造,代码如下:

public List<String> mget(String... keys) {
        List<Pipeline> pipelineList = new ArrayList<>();
        List<Jedis> jedisList = new ArrayList<>();
        try {
            //按照key的hash计算key位于哪一个redis节点
            Map<JedisPool, List<String>> pooling = new HashMap<>();
            for (String key : keys) {
                JedisPool pool = connectionHandler.getConnectionPoolFromSlot(JedisClusterCRC16.getSlot(key));
                pooling.computeIfAbsent(pool, k -> new ArrayList<>()).add(key);
            }

            //分别对每个redis 执行pipeline get操作
            Map<String, Response<String>> resultMap = new HashMap<>();
            for (Map.Entry<JedisPool, List<String>> entry : pooling.entrySet()) {
                Jedis jedis = entry.getKey().getResource();
                Pipeline pipelined = jedis.pipelined();
                for (String key : entry.getValue()) {
                    Response<String> response = pipelined.get(key);
                    resultMap.put(key, response);
                }
                pipelined.flush();
                //保存所有连接和pipeline 最后进行close
                pipelineList.add(pipelined);
                jedisList.add(jedis);
            }
            //同步所有请求结果
            for (Pipeline pipeline : pipelineList) {
                pipeline.returnAll();
            }
            //合并、排序结果
            List<String> list = new ArrayList<>();
            for (String key : keys) {
                Response<String> response = resultMap.get(key);
                String o = response.get();
                list.add(o);
            }
            return list;
        }finally {
            //关闭所有pipeline和jedis连接
            pipelineList.forEach(Pipeline::close);
            jedisList.forEach(Jedis::close);
        }

    }
3.2.2 处理异常case

上面的代码还不足以覆盖所有场景,我们还需要处理一些异常case

  • Redis Cluster扩缩容导致的数据迁移

数据迁移会造成两种错误

1、MOVED错误

代表数据所在的槽位已经迁移到另一个redis节点上了,服务端会告诉客户端对应的槽的目标节点信息。此时我们需要做的是更新客户端缓存的槽位信息,并尝试重新获取数据。

2、ASKING错误

代表槽位正在迁移中,且数据不在源节点中,我们需要先向目标Redis节点执行ASKING命令,才能获取迁移的槽位的数据。

List<String> list = new ArrayList<>();
for (String key : keys) {
    Response<String> response = resultMap.get(key);
    String o;
    try {
        o = response.get();
        list.add(o);
    } catch (JedisRedirectionException jre) {
        if (jre instanceof JedisMovedDataException) {
            //此槽位已经迁移 更新客户端的槽位信息
            this.connectionHandler.renewSlotCache(null);
        }
        boolean asking = false;
        if (jre instanceof JedisAskDataException) {
            //获取槽位目标redis节点的连接 设置asking标识,以便在重试前执行asking命令
            asking = true;
 askConnection.set(this.connectionHandler.getConnectionFromNode(jre.getTargetNode()));
        } else {
            throw new JedisClusterException(jre);
        }
        //重试获取这个key的结果
        o = runWithRetries(this.maxAttempts, asking, true, key);
        list.add(o);
    }
}

数据迁移导致的两种异常,会进行重试。重试会导致耗时增加,并且如果达到最大重试次数,还没有获取到数据,则抛出异常。

  • pipeline的某个命令执行失败

不捕获执行失败的异常,抛出异常让业务服务感知到异常发生。

4 效果展示

4.1 性能测试

在改造完客户端之后,我们对客户端的mget进行了性能测试,测试了下面三种类型的耗时

1、使用Jedis访问Codis

2、使用改造的JedisCluster访问Redis Cluster

3、使用Lettuce同步方式访问Redis Cluster

4.1.1 mget 100key
Codis JedisCluster(改造) Lettuce
avg 0.411ms 0.224ms 0.61ms
tp99 0.528ms 0.35ms 1.53ms
tp999 0.745ms 1.58ms 3.87ms
4.1.2 mget 500key
Codis JedisCluster(改造) Lettuce
avg 0.96ms 0.511ms 2.14ms
tp99 1.15ms 0.723ms 3.99ms
tp999 1.81ms 1.86ms 6.88ms
4.1.3 mget 1000key
Codis JedisCluster(改造) Lettuce
avg 1.56ms 0.92ms 5.04ms
tp99 1.83ms 1.22ms 8.91ms
tp999 3.15ms 3.88ms 32ms

4.2 结论

  • 使用改造的客户端访问Redis Cluster,比使用Lettuce访问Redis Cluster要快1倍以上;
  • 改造的客户端比使用codis稍微快一点,tp999不如codis性能好。

但是改造的客户端相对于Lettuce也有缺点,JedisCluster是基于复杂的连接池实现,连接池的配置会影响客户端的性能。而Lettuce是基于Netty的NIO框架实现,对于大多数的Redis操作,只需要维持单一的连接即可高效支持并发请求,不需要业务考虑连接池的配置。

5 总结

Redis Cluster在架构设计上对Multi-Key进行的限制,导致无法跨槽位执行mget等命令。我们对客户端JedisCluster的Multi-Key命令进行改造,通过分别对Redis节点执行pipeline操作,提升了mget命令的性能。

关于作者

赵浩,转转架构部后台开发工程师

转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」(综合性)、「大转转FE」(专注于FE)、「转转QA」(专注于QA),更多干货实践,欢迎交流分享~文章来源地址https://www.toymoban.com/news/detail-827402.html

到了这里,关于Redis Cluster基于客户端对mget的性能优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Redis客户端介绍

    redis安装完成后有自带的命令行客户端,即redis-cli,使用方式如下 options ——参数 -h 127.0.0.1 :指定要连接的redis节点的ip地址,默认值127.0.0.1 -p 6379 :指定要连接的redis节点的端口,默认值6379 -a xxxxxx :指定redis的访问密码 … commonds ——redis的操作命令 ping :心跳测试,服务器

    2024年02月06日
    浏览(45)
  • Redis客户端 - RedisSerializer

    原文首更地址,阅读效果更佳! Redis客户端 - RedisSerializer | CoderMast编程桅杆 https://www.codermast.com/database/redis/redistemplate-redis-serializer.html 前景回顾 在上一篇中,我们实现了一个简单的案例,操作一个 String 类型的数据,插入了一个 name = codermast 的数据到Redis。 使用redis-cli客户端

    2024年02月09日
    浏览(54)
  • redis 登录客户端命令

    Redis 命令用于在 redis 服务上执行操作。 要在 redis 服务上执行命令需要一个 redis 客户端。Redis 客户端在我们之前下载的的 redis 的安装包中。 语法 Redis 客户端的基本语法为: $ redis-cli 实例 以下实例讲解了如何启动 redis 客户端: 启动 redis 客户端,打开终端并输入命令 redis

    2023年04月08日
    浏览(51)
  • Redis的Java客户端-Java客户端以及SpringDataRedis的介绍与使用

    Spring Data Redis底层支持同时兼容Jedis和Lettuce两种不同的Redis客户端,可以根据需要任意选择使用其中的一种。这样既可以保留现有代码使用的Jedis方式,也可以通过使用基于Netty的高性能Lettuce客户端,提升应用的性能和吞吐量。 Jedis是一个传统的Java Redis客户端,使用BIO进行So

    2024年02月08日
    浏览(61)
  • Redis的Java客户端

    以下是redis.io官网所推荐使用前五的Java客户端 Java客户端 特点 Jedis 以Redis命令作为方法名称,学习成本低,简单实用,但是Jedis实例是线程不安全的,多线程环境下需要基于连接池来使用 lettuce Lettuce是基于Netty实现的,支持同步、异步和响应式编程方式,并且是线程安全的。

    2024年02月13日
    浏览(42)
  • Redis中的Java客户端

    Jedis是一个Java实现的Redis客户端连接工具。 Jedis使用非常简单,直接引入依赖。基于默认参数的Jedis连接池,初始化连接池类(使用默认连接池参数)JedisPool,获取一个Jedis连接Jedis jedis=jp.getResource()。 Jedis是线程不安全的,多线程使用同一个Jedis实例,会出现并发问题,原因是

    2024年01月17日
    浏览(46)
  • 【Redis入门篇】| Redis的Java客户端

    目录 一: Redis的Java客户端 1. Jedis快速入门 2. Jedis连接池 3. SpringDataRedis快速入门 4. RedisSerializer配置 5. StringRedisTemplate 图书推荐 在Redis官网中提供了各种语言的客户端,地址: https://redis.io/resources/clients/ Jedis: 以 Redis 命令作为方法名称,学习成本低,简单实用。但是 Jedis 实

    2024年02月03日
    浏览(98)
  • redis教程 二 redis客户端Jedis使用

    在Redis官网中提供了各种语言的客户端,地址:https://redis.io/docs/clients/ 其中Java客户端也包含很多但在开发中用的最多的还是Jedis,接下来就让我们以Jedis开始我们的快速实战。 入门案例详细步骤 案例分析: 创建工程: 创建一个maven管理的java项目 引入依赖: 在pom.xml文件下添

    2024年02月05日
    浏览(48)
  • Redis系列之客户端Redisson

    官方推荐的客户端,支持Redis单实例、Redis哨兵、Redis Cluster、Redis master-slave等各种部署架构。 GitHub, 功能: 分布式锁 使用Redisson提供的分布式锁的一个最常见场景,应用部署为多个节点,然后使用Spring提供的原生@Scheduled任务调度功能;而没有使用xxl-job等轻量级分布式任务调

    2024年02月09日
    浏览(47)
  • Redis客户端Redisson使用示例

    Redisson作为Java连接Redis的客户端,提供了连接、操作Redis的方法,还提供分布式锁、红锁等并发工具。Redisson除了提供同步接口外,还提供了异步(Async)、反射式(Reactive)和RxJava2标准的接口。Redisson会序列化Java对象然后保存到redis,所以通过redis命令行设置的值,Redisson来获

    2024年02月06日
    浏览(58)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包