redis集群客户端总结篇

傷城~ 2022-01-16 07:57 326阅读 0赞

转载：[https://blog.csdn.net/qq\_32749557/article/details/86491103][https_blog.csdn.net_qq_32749557_article_details_86491103]

[https://www.cnblogs.com/liyan492/p/9858548.html][https_www.cnblogs.com_liyan492_p_9858548.html]

[https://www.cnblogs.com/runnerjack/p/10269277.html][https_www.cnblogs.com_runnerjack_p_10269277.html]

概念：

Jedis：是Redis的Java实现客户端，提供了比较全面的Redis命令的支持，

Redisson：实现了分布式和可扩展的Java数据结构。

*　　Lettuce：高级Redis客户端，用于线程安全同步，异步和响应使用，支持集群，Sentinel，管道和编码器。*

*优点：*

*　　Jedis：比较全面的提供了Redis的操作特性*

*　　Redisson：促使使用者对Redis的关注分离，提供很多分布式相关操作服务，例如，分布式锁，分布式集合，可通过Redis支持延迟队列*

*　　Lettuce：主要在一些分布式缓存框架上使用比较多*

*可伸缩：*

Jedis：使用阻塞的I/O，且其方法调用都是同步的，程序流需要等到sockets处理完I/O才能执行，不支持异步。Jedis客户端实例不是线程安全的，所以需要通过连接池来使用Jedis。

Redisson：基于Netty框架的事件驱动的通信层，其方法调用是异步的。Redisson的API是线程安全的，所以可以操作单个Redisson连接来完成各种操作

*Lettuce：基于Netty框架的事件驱动的通信层，其方法调用是异步的。Lettuce的API是线程安全的，所以可以操作单个Lettuce连接来完成各种操作*

结论：

*建议使用：Jedis + Redisson*

最近开发的项目需要接入redis,在网上查了一下redis的客户端分别有jedis和Lettuce  
网上说jedis和Lettuce的主要区别是，jedis在多线程环境下，线程是不安全的。而  
Lettuce在多线程环境下线程是安全的。  
那为什么jedis在多线程环境下是不安全的呢？  
1.jedis是基于redis设计的，redis本身就是单线程的，所以jedis就没有做多线程的处理。  
jedis实例抽象的是发送命令相关，一个jedis实例使用一个线程与使用100个线程去发送命令  
没有本质上的区别，所以没有必要设置为线程安全的。  
但是redis的性能瓶颈主要在网络通讯，网络通讯速度比redis处理初度要慢很多。  
单客户端会导致网络通讯的时间里，redis处于闲暇，无法发挥其的处理能力。  
所以就需要用多线程方式访问redis服务器。那就使用多个jedis实例，每个线程对应一个jedis  
实例，而不是一个jedis实例多个线程共享。一个jedis关联一个client，相当于一个客户端，client  
继承了connection,connection维护了socket连接，对于socket这种昂贵的连接，一半都会做池化，所以jedis提供了jedispool.

会出现的问题：从异常信息来看，首先是在'zadd'操作时出现"Socket读取超时异常"，具体异常信息"JedisConnectionException: java.net.SocketTimeoutException: Read timed out"。  
出现异常后，会销毁这个阻塞的Jedis连接池对象（CustomShardedJedisPool.returnBrokenResource(CustomShardedJedisPool.java:121)），但在请求Redis服务端关闭连接时，出现"强制类型转换异常"，  
具体异常信息"ClassCastException: java.lang.Long cannot be cast to \[B"  
这个问题已经有前辈遇到过了，其解释：  
查看 Jedis 源码发现它的Connection中对网络输出流做了一个封装（RedisInputStream），其中自建了一个buffer。当发生异常的时候，  
这个buffer里还残存着上次没有发送或者发送不完整的命令。这个时候没有做处理，直接将该连接返回到连接池，那么重用该连接执行下次命令的时候，就会将上次没有发送的命令一起发送过去，所以才会出现上面的错误“返回值类型不对”。  
所以，正确的写法应该是：在发送异常的时候，销毁这个连接，不能再重用！

Jedis是Redis官方推荐的面向Java的操作Redis的客户端，而RedisTemplate是SpringDataRedis中对JedisApi的高度封装。  
RedisTemplate

redis有三种集群方式：主从复制，哨兵模式和集群。

**1.主从复制**

**主从复制原理：**

*  从服务器连接主服务器，发送SYNC命令； 
 *  主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 
 *  主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 
 *  从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 
 *  主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 
 *  从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（**从服务器初始化完成**）
 *  主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（**从服务器初始化完成后的操作**）

**主从复制优缺点：**

**优点：**

*  支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
 *  为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成
 *  Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。
 *  Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
 *  Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

**缺点：**

*  Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
 *  主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
 *  Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

**2.哨兵模式**

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

（1）监控主服务器和从服务器是否正常运行。   
    （2）主服务器出现故障时自动将从服务器转换为主服务器。

**哨兵的工作方式：**

*  每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
 *  如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
 *  如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
 *  当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）
 *  在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
 *  当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
 *  若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

**哨兵模式的优缺点**

**优点：**

*  哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
 *  主从可以自动切换，系统更健壮，可用性更高。

**缺点：**

*  Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

**3.Redis-Cluster集群**

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。

Redis-Cluster采用无中心结构,它的特点如下：

*  所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
 *  节点的fail是通过集群中超过半数的节点检测失效时才生效。
 *  客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

**工作方式：**

在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

[https_blog.csdn.net_qq_32749557_article_details_86491103]: https://blog.csdn.net/qq_32749557/article/details/86491103
[https_www.cnblogs.com_liyan492_p_9858548.html]: https://www.cnblogs.com/liyan492/p/9858548.html
[https_www.cnblogs.com_runnerjack_p_10269277.html]: https://www.cnblogs.com/runnerjack/p/10269277.html