【knime 源码】【kernel 源码阅读工具】【手写框架源码大全】jedis源码查看

时间:2024-12-23 03:22:00 来源:在线金花网站源码 分类:百科

1.到底如何在spring中使用redis
2.分析SpringBoot 的码查Redis源码
3.Spring Boot Redis Cluster 实战干货
4.Jedis那么低性能,还在用?赶紧换上 lettuce 吧!码查
5.Netty 出现 Connection reset by peer 异常的几个原因

jedis源码查看

到底如何在spring中使用redis

       1. Redis使用场景

       Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。

       æˆ‘们都知道,在日常的应用中,数据库瓶颈是最容易出现的。数据量太大和频繁的查询,由于磁盘IO性能的局限性,导致项目的性能越来越低。

       è¿™æ—¶å€™ï¼ŒåŸºäºŽå†…存的缓存框架,就能解决我们很多问题。例如Memcache,Redis等。将一些频繁使用的数据放入缓存读取,大大降低了数据库的负担。提升了系统的性能。

       å…¶å®žï¼Œå¯¹äºŽhibernate的二级缓存,是同样的道理。利用内存高速的读写速度,来解决硬盘的瓶颈。

       2. 配置使用redis

       é¦–先,我们需要引入基本的jar包。maven中的基本引用如下:

       ã€€ã€€ã€€ã€€<dependency>

        <groupId>org.springframework.data</groupId>

        <artifactId>spring-data-redis</artifactId>

        <version>1.4.2.RELEASE</version>

        </dependency>

        <dependency>

        <groupId>redis.clients</groupId>

        <artifactId>jedis</artifactId>

        <version>2.6.2</version>

        </dependency>

       ç„¶åŽï¼Œåœ¨applicationContext中配置如下:

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

        <property name="maxIdle" value="${ redis.maxIdle}" />

        <property name="maxTotal" value="${ redis.maxActive}" />

        <property name="maxWaitMillis" value="${ redis.maxWait}" />

        <property name="testOnBorrow" value="${ redis.testOnBorrow}" />

        </bean>

        <bean id="connectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory" p:host-name="${ redis.host}" p:port="${ redis.port}" p:password="${ redis.pass}"

        p:pool-config-ref="poolConfig" />

        <bean id="stringSerializer" class="org.springframework.data.redis.serializer.StringRedisSerializer"/>

        <!-- 开启事务,可以通过transcational注解控制 -->

        <bean id="redisTemplate" class="org.springframework.data.redis.core.RedisTemplate">

        <property name="connectionFactory" ref="connectionFactory" />

        <property name="keySerializer" ref="stringSerializer" />

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

        </bean>

       å¯¹äºŽhibernate的配置可知,第一个poolconfig是对连接池的配置。包括最大连接数,队列数,存活时间,最大等待时间等等,还有一些额外的配置,请直接点击JedisPoolConfig类源码,进行查看。

       è¿™äº›é…ç½®çš„意思如果不明白的话,一定要去把线程池好好学习下。

       ç¬¬ä¸€ä¸ªé…ç½®æ˜¯è¿žæŽ¥å·¥åŽ‚,顾名思义,最基本的使用一定是对连接的打开和关闭。我们需要为其配置redis服务器的账户密码,端口号。(这里还可以配置数据库的index,但是我使用时候一直使用redis的默认数据库,也就是第0个)

       æœ€åŽä¸€ä¸ªé…ç½®ç‰¹åˆ«é‡è¦ã€‚这个类似于spring提供的HibernateDaoSupport。

       æŽ¥ä¸‹æ¥ï¼Œå…¨éƒ¨è®²è§£éƒ½å°†å›´ç»•è¿™ä¸ªç±»å±•å¼€ã€‚

       3. RedisTemplate的使用

       è¿™ä¸ªç±»ä½œä¸ºä¸€ä¸ªæ¨¡ç‰ˆç±»ï¼Œæä¾›äº†å¾ˆå¤šå¿«é€Ÿä½¿ç”¨redis的api,而不需要自己来维护连接,事务。

       æœ€åˆçš„时候,我创建的BaseRedisDao是继承自这个类的。继承的好处是我的每个Dao中,都可以自由的控制序列化器,自由的控制自己是否需要事务,这个先不需要了解,跟着我目前的这种配置方法来即可。

       template提供了一系列的operation,码查比如valueOperation,HashOperation,ListOperation,SetOperation等,用来操作不同数据类型的Redis。

       å¹¶ä¸”,RedisTemplate还提供了对应的*OperationsEditor,用来通过RedisTemplate直接注入对应的Operation。我们暂时不讲这个。

       å¯¹äºŽä¸‹é¢çš„test1方法,我们暂时不用考虑,先了解通过RedisTemplate来使用connection操作Redis。

       Test代码如下:

       package cn.test.spjedis;

       import javax.annotation.Resource;

       import org.junit.Test;

       import org.junit.runner.RunWith;

       import org.springframework.beans.factory.annotation.Autowired;

       import org.springframework.dao.DataAccessException;

       import org.springframework.data.redis.connection.RedisConnection;

       import org.springframework.data.redis.core.RedisCallback;

       import org.springframework.data.redis.core.RedisTemplate;

       import org.springframework.data.redis.core.ValueOperations;

       import org.springframework.test.context.ContextConfiguration;

       import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

       import com.cn.redis2.dao.IncrDao;

       @RunWith(SpringJUnit4ClassRunner.class)

       @ContextConfiguration(locations = "classpath:applicationContext.xml")

       public class TestRedis {

        @Resource(name = "redisTemplate")

        private RedisTemplate<String, String> template; // inject the template as ListOperations

        //至于这个为什么可以注入。需要参考AbstractBeanFactory doGetBean

        //super.setValue(((RedisOperations) value).opsForValue());就这一行代码 依靠一个editor

        @Resource(name = "redisTemplate")

        private ValueOperations<String, Object> vOps;

        public void testSet(){

        template.execute(new RedisCallback<Boolean>() {

        @Override

        public Boolean doInRedis(RedisConnection connection) throws DataAccessException {

        byte [] key = "tempkey".getBytes();

        byte[] value = "tempvalue".getBytes();

        connection.set(key, value);

        return true;

        }

        });

        }

        public void testSet1(){

        vOps.set("tempkey", "tempvalue");

        }

        @Autowired

        private IncrDao incr;

       @Test

        public void addLink() {

        System.out.println(incr.incr());

        System.out.println(incr.get());

        }

       }

       è¿™ä¸ªæ˜¯å¯¹String类型插入的两个测试。test方法中,使用了模版类提交回调(RedisCallBack)的方法来使用jedis connection操作数据。这一部分,有没有似曾相识呢?

       HibernateTemplate的HibernateCallback,以及Hibernate Session类中的doWork以及doReturningWork方法,都是使用了这样的机制,方便对于连接或者session的统一管理。

       public int excuteHqlUpdate(final String hql,final Object ...params){

        return getHibernateTemplate().executeWithNativeSession(new HibernateCallback<Integer>() {

        @Override

        @SuppressWarnings("unchecked")

        public Integer doInHibernate(Session session) throws HibernateException {

        Query queryObject = session.createQuery(hql);

        if (params != null) {

        for (int i = 0; i < params.length; i++) {

        queryObject.setParameter(i, params[i]);

        }

        }

        return queryObject.executeUpdate();

        }

        });

        }

分析SpringBoot 的Redis源码

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

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

       在RedisAutoConfiguration中,kernel 源码阅读工具通过@Bean注解,它引入了LettuceConnectionConfiguration和JedisConnectionConfiguration,这两个配置类会创建RedisConnectionFactory实例。在注入RedisTemplate时,实际使用的会是第一个被扫描到的RedisConnectionFactory,这里通常是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写入数据时,出现无法获取连接异常,网页实际作品源码经过长时间代码追踪,发现连接的是.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 实现分布式锁,真香!!

       Spring Boot 之配置导入,强大到不行!

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

       Spring Boot 面试,一个问题就干趴下了!(下)

       Spring Boot 最核心的 个注解,都是干货!

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

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

       提取码: ztsj

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

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是值得考虑的升级选择。别让技术选择阻碍你的进步,及时更新和学习新的工具,保持技术的前沿性。

Netty 出现 Connection reset by peer 异常的几个原因

       æœ€è¿‘使用 netty 过程中发现了几个比较细节的 Connection reset by peer 异常,做个笔记。

        这个场景出现在用 Jedis ping 检测的场景,用完直接 close,服务端稳定出现 Connection reset by peer。

        tcpdump 一下就很容易定位到问题所在,客户端收到 PONG 响应后直接发了一个 RST 包给服务端:

        查看 Jedis 的源码发现 socket 有个比较特殊的配置 socket.setSoLinger(true, 0) 。

        先看一下 man7/socket.7 的解释:

        坦白说不是很明白啥意思。。。

        最终在 stackoverflow 上找到一个比较容易理解的解释:

        简而言之,设置 SO_LINGER(0) 可以不进行四次挥手直接关闭 TCP 连接,在协议交互上就是直接发 RST 包,这样的好处是可以避免长时间处于 TIME_WAIT 状态,当然 TIME_WAIT 存在也是有原因的,大部分评论都不建议这样配置。

        这个场景有点儿微妙,首先得理解一下 tcp 的两个队列。

        这篇文章讲得比较清楚: SYN packet handling in the wild

        accept 队列满通常是由于 netty boss 线程处理慢,特别是在容器化之后,服务刚启动的时候很容易出现 CPU 受限。

        为了模拟这个现象,我写了个示例程序 shichaoyuan/netty-backlog-test ,设置 SO_BACKLOG 为 1,并且在 accept 第一个连接后设置 autoRead 为 false,也就是让 boss 线程不再继续 accept 连接。

        启动第一个 Client,可以正常连接,发送 PING,接收 PONG。

        启动第二个 Client,也可以正常连接,但是没有收到 PONG:

        可见这个连接创建成功了,已经在 Accept Queue 里了,但是进程没有 accept,所以没有与进程绑定。

        启动第三个 Client,也可以正常连接,也没有收到 PONG:

        与第二个连接一样。

        启动第四个 Client,也可以正常连接,但是在发送 PING 后出现 Connection reset by peer:

        这个连接在服务端并没有进入 accept queue,处于 SYN_RECV 状态,并且很快就消失了(因为 accept queue 已经满了,无法转入 ESTABLISHED 状态)。

        抓包看一下:

        从客户端视角来看连接确实是建成功了,有一个比较特殊的地方在三次握手之后,服务端又向客户端发送了一个 [S.],客户端回复了一个 [.],这个交互看起来不影响连接。

        服务端后来销毁了连接,而客户端还认为连接是 ESTABLISHED 的,发送 PING 消息,服务端自然得回复一个 RST。

        PS:我在 Windows 的 WSL2 中实验这种场景是建连接超时,可能不同的操作系统或 linux 版本对这个交互的过程处理不同,在此不进行进一步测试了。

        以上,这个故事告诉我们判断连接是否可用,建成功之后应该发个心跳包测试一下。