当前位置：首页 > 编程日记 > 正文

jedis使用_网易架构师心得：Springboot下使用redis踩过的坑

编程日记 2024-05-17 20:20:00

点击?蓝色“ 深入原理”，关注并“设为星标”

技术干货，第一时间推送

首先总结了redis服务端单线程工作模型，redis四种部署方式及使用场景，然后从源码的角度上，分析springboot在jedis和lettuce客户端下使用redis的一些坑~尤其是在集群模式下的一些不兼容问题！

1 Redis服务端单线程模型

redis 内部使用文件事件处理(file event handler)处理客户端的请求，文件事件处理器是单线程的，所以redis才叫做单线程的模型。

文件事件处理器的结构包含4个部分：多个socket、IO 多路复用程序、文件事件分派器、事件处理器(连接应答处理器、命令请求处理器、命令回复处理器)。

文件事件处理器采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进行处理。

Redis客户端通过socket连接reids服务端，多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

redis 单线程模型也能效率高的原因：

纯内存操作
基于非阻塞的 IO 多路复用机制
单线程反而避免了多线程的频繁上下文切换问题

为什么redis采用单线程模型呢？

如果采用多线程模型，cpu需要进行上下文切换，假设1MB的数据由多个线程读取了1000次，那么就有1000次时间上下文的切换，那么就有1500ns * 1000 = 1500us，而单线程的读完1MB数据才250us ，所以完全没必要使用多线程。

什么时候适合采用多线程的方案呢？

对于慢速设备：磁盘，网络，SSD 等等，将请求和处理的线程不绑定，请求的线程将请求放在一个buff里，然后等buff快满了，处理的线程再去处理这个buff。然后由这个buff 统一的去写入磁盘，或者读磁盘，这样效率最高。

Redis线程安全吗？

redis实际上是采用了线程封闭的观念，把任务封闭在一个线程，自然避免了线程安全问题，不过对于需要依赖多个redis操作的复合操作来说，依然需要锁，而且有可能是分布式锁。

2 redis部署方式

2.1 单节点模式

单节点模式只有一个节点，一般用来测试

2.2 主从模式

主从模式包括一个主节点和多个从节点，一般来说，主节点用来读写操作，从节点用户读操作，主节点的数据可以同步到从节点，所以从节点即便支持写操作也没有意义。

2.3 哨兵模式

哨兵模式是基于主从模式的，哨兵模式为了实现主从模式的高可用，监控主从节点的状态，当sentinel发现master节点挂了以后，sentinel就会从slave中重新选举一个master。

一般来说，通过sentinel集群可以管理多个主从redis，sentinel最好不要和Redis部署在同一台机器，不然redis的服务器挂了以后，sentinel也挂了。使用sentinel集群也是为了保证redis的高可用，避免哨兵节点挂了之后影响redis的使用。

当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。

sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。

2.4 集群模式：

cluster的出现是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。

如图所示，部署了三主三从的redis集群，redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot，从而将数据存储至对应的slot上。

3 Springboot使用redis总结

spring-boot-starter-data-redis支持两种redis客户端：jedis和lettuce

Springboot2.0默认使用的客户端是lettuce，下面跟踪源码来分析springboot如何加在lettuce客户端的，首先找到springboot自动加载的jar包下redis相关的加载配置类RedisAutoConfiguration

这里采用@Configuration @bean的方式向容器中注入RedisTemplate和StringRedisTemplate，注入两者的方法中需要传入RedisConnectionFactory，RedisConnectionFactory通过@Import导入的LettuceConnectionConfiguration和JedisConnectionConfiguration生成

可以看到在没有RedisConnectionFactory的情况下，会默认向Spring容器中注入LettuceConnectionFactory，如果要使用jedis客户端，只需要手动配置一个JedisConnectionFactory并注入容器即可。

3.1 jedis和lettuce的区别

Jedis在实现上是直接连接的redis server，如果在多线程环境下是非线程安全的，这个时候只有使用连接池，为每个Jedis实例增加物理连接。
Lettuce的连接是基于Netty的，连接实例(StatefulRedisConnection)可以在多个线程间并发访问， StatefulRedisConnection是线程安全的，所以一个连接实例(StatefulRedisConnection)就可以满足多线程环境下的并发访问，当然这个也是可伸缩的设计，一个连接实例不够的情况也可以按需增加连接实例。

3.2 jedis非线程安全分析：

从源码角度分析jedis客户端执行每个命令的过程

首先借助于Client类的对应方法去执行命令

然后借助于Connection类的sendCommand方法执行

sendCommand方法每次执行都会调用connect方法

从connect方法中可以看到，socket是一个共享变量，假如两个线程公用一个jedis实例，当前还没有建立socket连接，两个线程同时进入建立socket连接

线程1建立socket连接后，开始获取输入输出流，于此同时，线程2重新初始化socket，并且没有执行到建立socket连接，此时线程1获取输入输出流将失败，因为此时的socket并没有连接。

jedis本身不是多线程安全的，这并不是jedis的bug，而是jedis的设计与redis本身就是单线程相关，jedis实例抽象的是发送命令相关，一个jedis实例使用一个线程与使用100个线程去发送命令没有本质上的区别，所以没必要设置为线程安全的。但是如果需要用多线程方式访问redis服务器怎么做呢？那就使用多个jedis实例，每个线程对应一个jedis实例，而不是一个jedis实例多个线程共享。一个jedis关联一个Client，相当于一个客户端，Client继承了Connection，Connection维护了Socket连接，对于Socket这种昂贵的连接，一般都会做池化，jedis提供了JedisPool。

3.3 集群模式下jedis和lettuce使用的一些坑

1. Lettuce在集群模式下主节点宕机，从节点更新为主节点，lettuce如何更新集群拓扑结构

集群中每个节点只负责部分slot， slot可能从一个节点迁移到另一节点，造成客户端有可能会向错误的节点发起请求。因此需要有一种机制来对其进行发现和修正，这就是请求重定向。

集群拓扑刷新是在ClusterTopologyRefreshScheduler中进行，下面进入类中一探究竟

ClusterTopologyRefreshScheduler类实现了ClusterEventListener接口，用来监听redis集群事件，集群事件包括ask重定向，move重定向，以及重新连接等。

在重定向方法中首先调用isEnabled方法判断是否开启刷新集群拓扑，然后调用indicateTopologyRefreshSignal方法刷新集群拓扑

判断集群是否开启刷新拓扑结构，依据ClusterTopologyRefreshOptions中自适应刷新的trigger中是否包含指定的重定向trigger，在默认配置下，这个trigger是什么样的呢？

可以看到默认情况下自适应刷新的trigger是空的，所以在集群模式下，使用默认的lettuce配置，如果主节点宕机，是不会刷新集群拓扑的，也就是会导致redis连接失败。

在enableAllAdaptiveRefreshTriggers方法中可以开启自适应刷新集群拓扑。开启自适应刷新集群拓扑后，又是如何刷新的呢？

在indicateTopologyRefreshSignal方法中提交一个刷新集群拓扑的clusterTopologyRefreshTask

在task中调用RedisClusterClient类的reloadPartitions方法重新加载集群拓扑信息，达到刷新的效果。

除了通过开始自适应刷新集群拓扑之外，还可以通过开启周期刷新的方式刷新集群拓扑

开启周期刷新集群拓扑后，在初始化集群拓扑的时，会调用activateTopologyRefreshIfNeeded开启周期刷新集群拓扑任务

这里会判断是否开启周期刷新，开启后才会提交一个定时任务。

周期刷新和自适应刷新比较：周期刷新和自适应刷新两种方法，最好还是使用自适应刷新，因为周期刷新的周期需要设置，设置太长会导致服务可能一段时间不可用，设置太短对资源是一种浪费，而自适应刷新根据服务端的响应来刷新集群拓扑。

两种刷新方法没必要都开启，都开启对资源也是一种浪费。

2.Jedis客户端执行lua脚本的坑

redis使用lua脚本的好处：

减少网络开销。可以将多个请求通过脚本的形式一次发送，减少网络时延。
原子操作。redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。因此在编写脚本的过程中无需担心会出现竞态条件，无需使用事务。
复用。客户端发送的脚本会永久存在redis中，这样，其他客户端可以复用这一脚本而不需要使用代码完成相同的逻辑。

那Jedis客户端是如何支持lua脚本的呢？

Jedis执行lua脚本是通过ScriptExecutor类的execute方法执行的，在方法中进一步调用eval方法

进一步调用RedisScriptingCommands类的eval方法，因为实在集群模式下使用jedis客户端，所以调用JedisClusterScriptingCommands实现类的eval方法

再看JedisClusterScriptingCommands实现类的eval方法，居然直接抛出异常，集群模式下不支持脚本。

解决方法是使用lettuce客户端，LettuceScriptingCommands类中的eval方法支持脚本

原文：https://juejin.im/post/6871164377236504589?utm_source=gold_browser_extension

-深入原理-

知其然并知其所以然

https://www.dkcj.cn/info/6684.html