皮皮网

1.Jedis连接池究竟是码下何物？
2.分析SpringBoot 的Redis源码
3.Spring Boot Redis Cluster 实战干货
4.Spring Data Redis切换底层Jedis 和 Lettuce实现
5.jedis 和 strpin-data-redis 哪一个好
6.Jedis那么低性能，还在用？赶紧换上 lettuce 吧！码下

Jedis连接池究竟是码下何物？

       连接池是管理并回收资源的对象集合，以减少系统资源的码下创建和销毁开销，提升系统吞吐量，码下适用于创建/销毁资源耗时的码下巡检php源码场景。以Jedis为例，码下其底层使用的码下是GenericObjectPool作为连接池实现。业务从空闲连接队列获取连接，码下最长等待时间由maxWaitMillis决定。码下获取后，码下检查是码下否有效，关闭后再次放入空闲队列或销毁。码下连接池的码下参数如配置文件中详细列出，Spring-Data-Redis将参数进行收敛，码下用户主要配置参数较少，关键参数包括验证方法的启用和关闭。Jedis实例通过Spring-Data-Redis封装后，实现对连接池的管理，提供了BorrowObject方法获取连接和ReturnObject方法归还连接。其中BorrowObject方法可能从空闲队列获取或创建新连接，超过最大等待时间则抛出异常。ReturnObject方法负责归还连接并进行有效性验证。连接池还包括定期驱逐/保活机制、检查机制和抛弃机制，aes c++ 源码通过配置参数、源码分析和JMX工具实现连接状态监控和问题排查。了解连接池原理有助于提升资源管理效率，并在实际应用中根据业务需求优化配置。

分析SpringBoot 的Redis源码

       在Spring Boot 2.X版本中，官方简化了项目配置，如无需编写繁琐的web.xml和相关XML文件，只需在pom.xml中引入如spring-boot-starter-data-redis的starter包即可完成大部分工作，这极大地提高了开发效率。

       深入理解其原理，我们研究了spring-boot-autoconfigure和spring-boot-starter-data-redis的源码。首先，配置项在application.properties中的设置会被自动映射到名为RedisProperties的类中，此类由RedisAutoConfiguration类负责扫描和配置。该类会检测是否存在RedisOperations接口的实现，例如官方支持的Jedis或Lettuce，以此来决定使用哪个客户端。

       在RedisAutoConfiguration中，通过@Bean注解，它引入了LettuceConnectionConfiguration和JedisConnectionConfiguration，这两个配置类会创建RedisConnectionFactory实例。在注入RedisTemplate时，实际使用的会是第一个被扫描到的RedisConnectionFactory，这里通常是砸金蛋+ios源码LettuceConnectionFactory，因为它们在@Import注解的导入顺序中位于前面。

       自定义starter时，可以模仿官方starter的结构，首先引入spring-boot-autoconfigure，然后创建自己的配置类（如MyRedisProperties）和操作模板类（如JedisTemplete）。在MyRedisAutoConfiguration中，你需要编写相关配置并确保在spring.factories文件中注册，以便Spring Boot在启动时扫描到你的自定义配置。

       以自定义my-redis-starter为例，项目结构包括引入的依赖，配置类的属性绑定，以及创建连接池和操作方法的实现。测试时，只需在Spring Boot项目中引入自定义starter，配置好相关参数，即可验证自定义starter的正确工作。

Spring Boot Redis Cluster 实战干货

       只需添加3个master节点，3个slave节点无需添加。

       配置完成这些即可，Spring Boot 会自动完成其他配置。

       现在可以像使用单机一样使用集群，Redis 会自动按key分片到不同的集群实例。

       遇到的问题：尝试向Redis写入数据时，出现无法获取连接异常，dj+asp.源码经过长时间代码追踪，发现连接的是.0.0.1，而非配置的..1.8，这令人困惑。继续追踪代码发现是向Redis服务器获取的集群实例列表，真是坑！

       源码：redis.clients.jedis.Jedis#clusterSlots

       就是这里获取返回的集群列表，返回的就是.0.0.1，而非配置的..1.8。

       最后修改各个集群节点的配置文件redis.conf，添加：

       重启集群节点后，读写恢复正常。

       更多 Spring Boot 干货：

       Spring Boot 宣布移除 run 命令，真让我猝不及防！

       Spring Boot 定时任务开启后，如何自动停止符合条件？

       Spring Boot 保护敏感配置的 4 种方法，让你的系统不再裸奔！！

       Spring Boot 集成 Flyway，数据库也能做版本控制，太牛逼了！

        个官方 Spring Boot Starters 出炉！别再重复造轮子了……

       Spring Boot Redis 实现分布式锁，真香！出行app+源码！

       Spring Boot 之配置导入，强大到不行！

       年轻人的第一个自定义 Spring Boot Starter！

       Spring Boot 面试，一个问题就干趴下了！（下）

       Spring Boot 最核心的 个注解，都是干货！

       好了，最后栈长再送你一份Spring Boot 学习笔记，包括底层实现原理及代码实战，非常齐全，助你快速打通 Spring Boot 的各个环节。

       链接: pan.baidu.com/s/wLzA6...

       提取码: ztsj

       版权申明：本文系 "Java技术栈" 原创，原创实属不易，转载、引用本文内容请注明出处，禁止抄袭、洗稿，请自重，尊重他人劳动成果和知识产权。

Spring Data Redis切换底层Jedis 和 Lettuce实现

       Spring Data Redis提供了对Redis操作的高级抽象，支持Jedis和Lettuce两种连接方式。通过简单的配置即可连接Redis并切换连接方式。具体步骤如下：

       引入Redis依赖使用Spring Boot的spring-boot-starter-data-redis。

       自定义配置类设置Key和Value的序列化。

       修改Redis连接配置，可自由切换单节点、哨兵模式和集群模式。

       注入RedisTemplate后，即可操作Redis。RedisTemplate具有两个泛型。

       源码分析部分，从Redis自动配置类RedisAutoConfiguration开始，它引入了两个连接Redis配置类：LettuceConnectionConfiguration和JedisConnectionConfiguration。这两个配置类通过条件注解控制是否生效，如果生效，则会使用相应的依赖生成RedisConnectionFactory的Bean。引入Lettuce依赖时，能通过io.lettuce.core.RedisClient找到类，说明默认使用Lettuce。若无Jedis相关依赖，则当前配置类无效。

       切换连接方式至Jedis有两种方式：利用@ConditionalOnClass注解排除Lettuce依赖，或利用@ConditionalOnProperty注解修改配置文件中的spring.redis.client-type为jedis。第一种方式优点在于不加载多余的依赖包，推荐使用。第二种方式则可通过配置文件自由切换连接方式。

       本文由OpenWrite平台发布。请按照上述步骤进行Spring Data Redis的使用和连接方式切换。

jedis 和 strpin-data-redis 哪一个好

       ä¹‹å‰ä¸€ç›´æ²¡ä»”细看过ShardedJedis的代码，最近遇到了shard后集群扩容后的数据迁移问题。

       ä»Šå¤©åœ¨çœ‹ShardedJedis源码的时候，发现ShardedJedis并没有使用节点的Ip和port做hash，而是用的instance的顺序或者name，太赞了。

       private void initialize(List<S> shards) {

        nodes = new TreeMap<Long, S>();

       for (int i = 0; i != shards.size(); ++i) {

        final S shardInfo = shards.get(i);

        if (shardInfo.getName() == null)

        for (int n = 0; n < * shardInfo.getWeight(); n++) {

        nodes.put(this.algo.hash("SHARD-" + i + "-NODE-" + n),

        shardInfo);

        }

        else

        for (int n = 0; n < * shardInfo.getWeight(); n++) {

        nodes.put(

        this.algo.hash(shardInfo.getName() + "*"

        + shardInfo.getWeight() + n), shardInfo);

        }

        resources.put(shardInfo, shardInfo.createResource());

        }

        }

       é…ç½®çš„时候也非常简单:

       <bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">

        <property name="maxTotal" value=""/>

        <property name="maxIdle" value=""/>

        <property name="minIdle" value="1"/>

        <property name="maxWaitMillis" value=""/>

        <property name="testOnBorrow" value="true"/>

        <property name="testOnReturn" value="true"/>

        <property name="testWhileIdle" value="true"/>

        </bean>

        <bean id="shardedJedisPool" class="redis.clients.jedis.ShardedJedisPool" destroy-method="destroy">

        <constructor-arg ref="jedisPoolConfig"/>

        <constructor-arg>

        <list>

        <bean class="redis.clients.jedis.JedisShardInfo">

        <constructor-arg value=".0.0.1"/>

        <constructor-arg type="int" value=""/>

        <constructor-arg value="instance:"/>

        </bean>

        <bean class="redis.clients.jedis.JedisShardInfo">

        <constructor-arg value=".0.0.1"/>

        <constructor-arg type="int" value=""/>

        <constructor-arg value="instance:"/>

        </bean>

        <bean class="redis.clients.jedis.JedisShardInfo">

        <constructor-arg value=".0.0.1"/>

        <constructor-arg type="int" value=""/>

        <constructor-arg value="instance:"/>

        </bean>

        </list>

        </constructor-arg>

        </bean>

       ä¸€å¼€å§‹ä½ å¯ä»¥è®¾ç½®è¶³å¤Ÿå¤šçš„instance，数据扩容的时候，只需要将几个instance的数据copy到别的机器上。

       ç„¶åŽä¿®æ”¹é…ç½®æ–‡ä»¶çš„ip和端口即可。很方便吧？

       å¦å¤–，Jedis还提供了对jedis sentinel pool的封装，所以发生主从切换的时候，web server都不需要重新配置和deploy。高可用性的极佳体现啊。

       @Autowired private JedisSentinelPool pool;

       public void mymethod() {

        Jedis jedis = null;

        try {

        jedis = pool.getResource();

        jedis.hset(....

        } catch (JedisException je) {

        throw je;

        } finally {

        if (jedis != null) pool.returnResource(jedis);

        }

        }

       spring bean的配置：

       <bean id="redisSentinel" class="redis.clients.jedis.JedisSentinelPool">

        <constructor-arg index="0" value="mymaster" />

        <constructor-arg index="1">

        <set>

        <value>hostofsentinel:</value>

        </set>

        </constructor-arg>

        <constructor-arg index="2" ref="jedisPoolConfig" />

        </bean>

Jedis那么低性能，还在用？赶紧换上 lettuce 吧！

       在大型企业的技术栈中，经常面临着选择Redis客户端工具的决策：Jedis、Redisson还是Lettuce？本文将深入探讨这三者的优缺点，以助你做出明智的选择。

       首先，我们来看一下官方推荐的三款Java客户端：Jedis，老牌的Redis客户端，它提供了全面的Redis命令支持，其官网链接为<a href="tool.oschina.net/upload...">tool.oschina.net/upload...，其优点在于功能全面，但可能在性能上存在短板。

       相比之下，Redisson是一个基于Redis的Java内存网格框架，它简化了Redis的使用，提供了一系列分布式Java对象和服务，如分布式锁和Spring cache等。Redisson官网和Git地址分别为：<a href="redisson.org/">redisson.org/ 和 <a href="github.com/redisson/red...">

       github.com/redisson/red...。Redisson强调关注分离，有助于业务逻辑的处理，但不支持某些高级Redis特性。

       然后是Lettuce，一个可扩展的线程安全Redis客户端，支持异步操作，并在多线程环境中表现出色，特别是对于避免阻塞和事务操作。Lettuce基于Netty，支持高级Redis功能，官网和Git地址是：<a href="lettuce.io/">lettuce.io/ 和 <a href="github.com/lettuce-io/l...">

       github.com/lettuce-io/l...。Lettuce在性能上优于Jedis，特别适合对高级功能需求不高的场景。

       在实际选择中，Jedis和Lettuce适合基础Redis操作，而Redisson则适合需要分布式和扩展性功能的应用。如果考虑使用分布式锁或高级数据结构，Redisson是更好的选择，但需注意其对字符串操作的限制。在Spring Boot 2及更高版本中，lettuce成为了默认连接选择，反映了其在性能上的优势。

       关于链接断裂的问题，Lettuce不提供心跳机制，但可以利用Netty的空闲检测机制来维持连接。这需要对Netty的开发和源码有一定理解，相关资料可以参考《java高并发核心编程卷1加强版》。

       总之，如果你追求性能和基础操作，Lettuce是值得考虑的升级选择。别让技术选择阻碍你的进步，及时更新和学习新的工具，保持技术的前沿性。

lettuce相较于jedis有哪些优缺点?

       在对比Lettuce和Jedis这两个Redis客户端的使用体验时，我们可以通过实际工作中的小插曲来深入了解它们的优缺点。

       Lettuce的稳定性在我们的团队项目中得到验证。一次消息堆积问题的出现，让整个应用陷入困境。在排查中发现，尽管Redis服务器的慢日志没有异常信息，应用却在等待Redis响应时超时，导致消费速度跟不上。通过对应用与Redis之间的数据包进行分析，最终定位到Lettuce内部的CommandHandler队列状态问题导致应用无故超时。通过GitHub问题反馈，我们得以快速定位问题所在，并解决问题。这展示了Lettuce在处理并发和稳定性方面的优势。

       相比之下，Jedis在我们老应用中的使用则暴露出了一些问题。某个应用的线程数出现异常激增，通过线程dump信息分析，发现大量操作在等待Jedis内部的SlotCache读写锁。这表明Jedis内部维护的锁粒度过大，存在导致上层调用方出现短暂超时的风险。通过修改Jedis源代码并解决问题，我们发现Jedis在并发控制和资源管理方面可能需要优化。然而，遗憾的是，对于后续的改进反馈，Jedis项目团队未能给予回复，项目维护情况显示在过去两个多月内几乎处于停滞状态。

       总结而言，Lettuce在稳定性、异常处理和快速响应方面表现出色，而Jedis则在并发控制和资源管理方面存在优化空间。选择合适的客户端取决于具体应用的需求，考虑到稳定性、响应速度和维护活跃度，Lettuce可能在某些场景下更具有优势。