在日常开发过程中，如果想要构建一个高并发高吞吐量的系统，redis基本是成了标配。回想下现在比较常用的客户端也就是jedis、redission、lettuce这几种，jedis算是比较老牌的redis client了，redission底层基于netty并以其各种丰富的数据结构和特性而广受欢迎，lettuce则属于后起之秀，底层集成了Project Reactor提供天然的反应式编程，通信框架集成了Netty使用了非阻塞IO，5.x版本之后融合了JDK1.8的异步编程特性，在保证高性能的同时提供了十分丰富易用的API。Jedis客户端实例不是线程安全的，所以需要通过连接池来使用Jedis，Redisson的API是线程安全的，所以可以操作单个Redisson连接来完成各种操作，Lettuce的API也是线程安全的，所以可以操作单个Lettuce连接来完成各种操作。在跑完不同客户端的benchmark后，我选择了使用lettuce来作为整个平台的redis client。
一次技术讨论会上，大家说起 Redis 的 Java 客户端哪家强，我第一时间毫不犹豫地喊出 "Jedis, YES！"
最近，私信还有留言中，网友提到 spring-data-redis 和 lettuce 一起使用，pipeline 通过抓包一看，并没有生效，这个如何配置才能生效呢？
2020年4月30日，Redis 6.0.0正式发布，标志着redis从此告别单线程。在此之前，在大数据生产环境中使用的是一个30个节点的Codis集群，SparkStreaming以此作为缓存，QPS高峰大概在2000w/s。
最近线上发现一个现象，应用实例刚刚启动的时候，开始接收请求之后发生了一小段时间的请求阻塞，从 HTTP Servlet 请求队列监控上可以看出（基于 spring-web 的普通阻塞的 HTTP 服务器是有 HTTP 线程池的，当线程是满了之后，请求在阻塞队列中等待处理。基于 spring-webflux 的没有这个现象，但是考虑的背压问题其实和这个场景类似）：
我们先来了解下在spring-data-redis中是如何包装lettuce的连接的，然后会根据这些信息得到上一篇文章中留下的那个问题的解。
摘要： 引言 了解Jedis的童鞋可能清楚，Jedis中JedisCluster是不支持pipeline操作的，如果使用了redis集群，在spring-boot-starter-data-redis中又正好用到的pipeline，那么会接收到Pipeline is currently not supported for JedisClusterConnection.这样的报错。
最近线上又出事儿了，新上线了一个微服务系统，上线之后就开始报各种发往这个系统的请求超时，这是咋回事呢？
Lettuce 和 Jedis 的定位都是 Redis 的 client，所以它们可以直接连接redis server。
Lettuce是一个Redis的Java驱动包，初识她的时候是使用RedisTemplate的时候遇到点问题Debug到底层的一些源码，发现spring-data-redis的驱动包在某个版本之后替换为Lettuce。Lettuce翻译为生菜，没错，就是吃的那种生菜，所以它的Logo长这样：
大家好，我们最近业务量暴涨，导致我最近一直 TM 人傻了。前几天晚上，发现由于业务压力激增，某个核心微服务新扩容起来的几个实例，在不同程度上，出现了 Redis 连接失败的异常：
Redis ，全称为 “Remote Dictionary Server ”，即：远程字典服务器。一款完全开源免费，基于 C 语言编写，遵守 BSD 协议，高性能的 ( Key/Value ) 分布式内存数据库。其基于内存运行并支持持久化的 NoSQL 数据库， 是当前最热门的 NoSQL 数据库之一，通常也被称之为“数据结构服务器”。Redis 为典型的 C/S 架构，基于 Java 语言平台，其使用 Socket、Redis 的 RESP（Redis Serialization Protocol 即 Redis 序列化协议）协议进行业务处理。作为一款备受欢迎的组件，其主要应用于如下场景中：缓存、计数器、购物车、点赞/打卡、分布式锁等等。
作为分布式缓存系统之一，Redis 应用场景较为广泛，落地于不同的行业领域以及业务场景，因此，在整个架构拓扑中起着重要的作用。
在与 知识星球 的球友交流中，最近有很多小伙伴在面大厂， 经常遇到下面的问题：3大redis客户端：Jedis、Redisson、Lettuce ，如何选型？
最近在开发一个使用Redis协议包装HBase的Proxy服务器，一路写的很顺，客户端使用redis-py提供的execute_command方法也轻松搞定。但是在编写Java客户端的时候却遇到了难题，我们常用的Jedis不提供自定义指令，连反射这条路子都给堵死了，感觉陷入了僵局。难道需要自己改造Jedis的源代码么，代价有点大。
背景：最近在对一新开发Springboot系统做压测，发现刚开始压测时，可以正常对redis集群进行数据存取，但是暂停几分钟后，接着继续用jmeter进行压测时，发现redis就开始突然疯狂爆出异常提示：Command timed out after 6 second(s)......
在使用lettuce作为redis连接池时，在上一节中我们知道，lettuce中维护连接有两种使用连接池的方式，目前一种已经废弃，另一种大家正在使用的版本是apache commons pool。咱们来回顾下。
在快速入门 Spring Boot 整合 Redis 之前，我们先来做个简单的了解。在 Spring 的生态中，我们使用 Spring Data Redis 来实现对 Redis 的数据访问。
前几日，Redis 创始人 Antirez 在他的个人博客上宣布将结束自己的 Redis 之旅！
本地缓存，就是使用应用内使用本地内存将数据暂缓存储，一般数据库的查询如果不怎么改动，可以用本地缓存暂存。
在多年的SparkStreaming的大数据流处理开发中，除了Kafka，Redis是用的最多的组件。目前生产有多个redis集群，最大的32节点的codis集群的key已经达到40亿个，峰值2000万的QPS。
就在今天Spring Boot 2.0.0.RELEASE正式发布，今天早上在发布Spring Boot2.0的时候还出现一个小插曲，将Spring Boot2.0同步到Maven仓库的时候出现了错误，然后Spring Boot官方又赶紧把 GitHub 上发布的 v2.0.0.RELEASE 版本进行了撤回。到了下午将问题修复后，又重新进行了上传，至此Spring Boot2.0正式推出！ 要知道这是Spring Boot1.0发布4年之后第一次重大修订，因此有多的新功能和特性值得大家期待！在Spring
就在昨天Spring Boot2.0.0.RELEASE正式发布，今天早上在发布Spring Boot2.0的时候还出现一个小插曲，将Spring Boot2.0同步到Maven仓库的时候出现了错误，然后Spring Boot官方又赶紧把 GitHub 上发布的 v2.0.0.RELEASE 版本进行了撤回。到了下午将问题修复后，又重新进行了上传，至此Spring Boot2.0正式推出！
本文将模拟一个用户服务，并使用Redis作为数据存储服务器。 本文涉及两个java bean，用户与权益
就在本月的1号，Spring Boot 2.0.0.RELEASE正式发布，1号在发布Spring Boot2.0的时候还出现一个小插曲，将Spring Boot2.0同步到Maven仓库的时候出现了错误，然后Spring Boot官方又赶紧把 GitHub 上发布的 v2.0.0.RELEASE 版本进行了撤回。到了下午将问题修复后，又重新进行了上传，至此Spring Boot2.0正式推出！
摘要: 原创出处 http://www.iocoder.cn/Spring-Boot/Redis/ 「芋道源码」欢迎转载，保留摘要，谢谢！
这部分内容比较简单，没啥难度，因此我不打算进行具体代码实践演示，只是给出完整的解决思路和其中的注意事项
Redis 监听默认 6379 的端口号，可以通过 TCP 方式建立连接。 服务端约定了一种特殊的消息格式，叫做 Redis Serialization Protocol（RESP，Redis 序列化协议），发消息或者响应消息需要按这种格式编码，接收消息需要按这种格式解码。 Redis 设计这种格式的原因∶ 容易实现、解析快、可读性强。 Redis6.0新特性里面说的RESP协议升级到了3.0 版本，其实就是对于服务端和客户端可以接收的消息进行了升级扩展，比如客户端缓存的功能就是在这个版本里面实现的。
skywalking-6.6.0/apm-sniffer/optional-plugins/lettuce-5.x-plugin/src/main/resources/skywalking-plugin.def
1. 前言 Spring Boot 2.0中 Redis 客户端驱动现在由 Jedis变为了 Lettuce，这是随意的根据喜好的决定，还是有技术上的原因呢？ Lettuce 的确有很多优秀的特性，例如： 基于 netty，支持事件模型 支持 同步、异步、响应式 的方式 可以方便的连接 Redis Sentinel 完全支持 Redis Cluster SSL 连接 Streaming API CDI 和 Spring 的集成 兼容 Java 8 和 9 2. 重要特性 （1）多线程共享 Jedis 是直连
Lettuce 是一个可伸缩的线程安全的 Redis 客户端，支持同步、异步和响应式模式。多个线程可以共享一个连接实例，而不必担心多线程并发问题。它基于优秀 netty NIO 框架构建，支持 Redis 的高级功能，如 Sentinel，集群，流水线，自动重新连接和 Redis 数据模型。
多线程环境下，使用池化技术，提高性能。对Jedis来说更是必须，否则还会出现数据错误。
项目中场景需要get一批key的value，因为redis的get操作(不单单是get命令)是阻塞的，如果循环取值的话，就算是内网，耗时也是巨大的。所以想到了redis的pipeline命令。
相对于其他的分布式中间件，Redis 支持的客户端种类非常繁多，涵盖更加全面，除了支持比较流行的 c、c++、java、C#、php、Python 等语言以外，还支持 Objective-C、Swift、Node.js 等等，以下是来自于 Redis 支持的按语言分类的客户端截图。
因为没有指定ReturnType，所以默认使用ReturnType.STATUS，返回值就是io.lettuce.core.output.StatusOutput，这个类并没有重写CommandOutput中的方法。所以抛出异常IllegalStateException
Spring Data Redis是 Spring Data 系列的一部分，它提供了Spring应用程序对Redis的轻松配置和使用。它不仅提供了对Redis操作的高级抽象，还支持Jedis和Lettuce两种连接方式。
作为知名互联网公司都在用的技术，Spring Boot 2.0 的更新引起了很大的关注，本文将分为三部分解读 2.0 的更新：
岁月流转，时光飞逝，转眼2021年已经画上句号。过去一年，vivo 互联网技术共推送了107篇文章，涉及服务器、前端、数据库等技术。
redis-cluster是近年来redis架构不断改进中的相对较好的redis高可用方案。本文涉及到近年来redis多实例架构的演变过程，包括普通主从架构（Master、slave可进行写读分离）、哨兵模式下的主从架构、redis-cluster高可用架构（redis官方默认cluster下不进行读写分离）的简介。同时还介绍使用Java的两大redis客户端：Jedis与Lettuce用于读写redis-cluster的数据的一般方法。再通过官方文档以及互联网的相关技术文档，给出redis-cluster架构下的读写能力的优化方案，包括官方的推荐的扩展redis-cluster下的Master数量以及非官方默认的redis-cluster的读写分离方案，案例中使用Lettuce的特定方法进行redis-cluster架构下的数据读写分离。
Lettuce 是一个 Redis 连接池，和 Jedis 不一样的是，Lettuce 是主要基于 Netty 以及 ProjectReactor 实现的异步连接池。由于基于 ProjectReactor，所以可以直接用于 spring-webflux 的异步项目，当然，也提供了同步接口。
Lettuce是一个高性能的redis客户端，底层基于netty框架来管理连接，天然是非阻塞和线程安全的。比起jedis需要为每个实例创建物理连接来保证线程安全，lettuce确实很优秀。本文主要介绍springboot使用lettuce整合redis客户端。说明一下，本文的源代码是使用springboot2.1.6，对应lettuce版本是5.1.7.RELEASE。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
在一个Spring boot项目中，需要使用redis作为缓存，于是将使用spring-boot-starter-data-redis，具体依赖如下：
【L1】 内存缓存（如 Caffeine、Ehcache） —— 速度快，进程内可用，但重启缓存丢失，出现缓存雪崩的问题。
redis使用过程中，很多情况都是读多写少，而不管是主从、哨兵、集群，从节点都只是用来备份，为了最大化节约用户成本，我们需要利用从节点来进行读，分担主节点压力，这里我们继续上一章的jedis的读写分离，由于springboot现在redis集群默认用的是lettuce，所以介绍下lettuce读写分离
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
