Spring boot redis 客户端 lettuce 与 jedis 区别整理

spring boot框架中已经集成了redis，在1.x.x的版本时默认使用的jedis客户端，现在是2.x.x版本默认使用的lettuce客户端，两种客户端的区别如下

# Jedis和Lettuce都是Redis Client
# Jedis 是直连模式，在多个线程间共享一个 Jedis 实例时是线程不安全的，
# 如果想要在多线程环境下使用 Jedis，需要使用连接池，
# 每个线程都去拿自己的 Jedis 实例，当连接数量增多时，物理连接成本就较高了。

# Lettuce的连接是基于Netty的，连接实例可以在多个线程间共享，
# 所以，一个多线程的应用可以使用同一个连接实例，而不用担心并发线程的数量。
# 当然这个也是可伸缩的设计，一个连接实例不够的情况也可以按需增加连接实例。

# 通过异步的方式可以让我们更好的利用系统资源，而不用浪费线程等待网络或磁盘I/O。
# Lettuce 是基于 netty 的，netty 是一个多线程、事件驱动的 I/O 框架，
# 所以 Lettuce 可以帮助我们充分利用异步的优势。

序列化选择

1.spring-data-redis中序列化类有以下几个：

• GenericToStringSerializer：可以将任何对象泛化为字符创并序列化
• Jackson2JsonRedisSerializer：序列化Object对象为json字符创（与JacksonJsonRedisSerializer相同）
• JdkSerializationRedisSerializer：序列化java对象
• StringRedisSerializer：简单的字符串序列化

2.JdkSerializationRedisSerializer序列化

被序列化对象必须实现Serializable接口，被序列化除属性内容还有其他内容，长度长且不易阅读

存储内容如下：

"\xac\xed\x00\x05sr\x00!com.oreilly.springdata.redis.User\xb1\x1c \n\xcd\xed%\xd8\x02\x00\x02I\x00\x03ageL\x00\buserNamet\x00\x12Ljava/lang/String;xp\x00\x00\x00\x14t\x00\x05user1"

JacksonJsonRedisSerializer序列化

被序列化对象不需要实现Serializable接口，被序列化的结果清晰，容易阅读，而且存储字节少，速度快

存储内容如下：

"{\"userName\":\"user1\",\"age\":20}"

3.StringRedisSerializer序列化

一般如果key、value都是string字符串的话，就是用这个就可以了

文章来源https://www.cnblogs.com/taiyonghai/p/9454764.html

 

针对redis连接池获取连接出现长时间等待问题虽然现在通过调整线程池大小和去掉调用是否联通号码逻辑暂时起到了一些作用，但是

 却是治标不治本的方案。因此秉着事情必须要有闭环的宗旨。今天花了一天时间做了如下的压力测测试。

           知识储备：

           jedis客户端连接方式是基于tcp的阻塞式连接方式。

           lettuce客户端连接方式是基于netty的多路复用异步非阻塞的连接方案。（目前业界解决高并发大数据的问题的思路）

        

           在场景一：

           最大线程数：10   最大空闲线程10   最小空闲线程5   并发数 100/s    时间  120s

 

           jedis客户端连接

           

          lettuce客户端连接

       

 

 

         在场景二：

           最大线程数：10   最大空闲线程10   最小空闲线程5   并发数 200/s    时间  120s

 

           jedis客户端连接

           

          lettuce客户端连接

          

 

 

                 在场景三：

           最大线程数：50   最大空闲线程50   最小空闲线程50   并发数 200/s    时间  120s

 

            jedis客户端连接

           

 

              lettuce客户端连接

         

 

 

              在场景四：

           最大线程数：70   最大空闲线程50   最小空闲线程20   并发数 200/s    时间  120s

 

            jedis客户端连接

                      

 

 

               lettuce客户端连接

              

 

             

              结论1：

             所有场景：

              jedis表现的吞吐量优于lettuce连接方案。

              lettuce表现的响应时间和稳定性优于jedis连接方案。

             

             结论2：

              场景一  vs  场景二

             通过增大并发量

             jedis吞吐量增大，超时错误开始出现，最大响应时间增大。

             原因分析：连接数达到最大值，出现连接超时拒绝，连接等待出现  。所以最大耗时增加。 

             lettuce表现都是毫秒级别，但是平均耗时和最大耗时开始增加。

             原因分析：lettuce采用多路复用原理，因此真正工作的连接受制于CPU核数因此增大连接数反而增加了线程上下文切换时间。因此建议调整为  CPU核实+1.

 

              场景二   vs 场景三、四

              通过调大线程池数量

              jedis吞吐量增大，超时错误开始出现，最大响应时间增大。

             原因分析：连接数达到最大值，出现连接超时拒绝，连接等待出现  。所以最大耗时增加。 

             lettuce表现都是毫秒级别，但是平均耗时和最大耗时开始增加。

             原因分析：lettuce采用多路复用原理，因此真正工作的连接受制于CPU核数因此增大连接数反而增加了线程上下文切换时间。因此建议调整为  CPU核数+1.

 

 

              最终结论：

              调大连接池大小能够提高jedis的吞吐量，但是不能避免出现超时错误和长时间等待。

              jedis连接方式最大连接数和最小、最大空闲连接数设置为一样有利于减少上下文切换时间，提升效率。

              letturce调大连接池大小反而会影响性能，最佳个数= CPU核数+1.

              letturce整体稳定性和性能由于jedis方式。

转载 https://blog.csdn.net/honger_hua/article/details/106529643