原文地址 https://www.cnblogs.com/zhoujinyi/p/13222464.html 背景 在Redis6.0之前的版本中，登陆Redis Server只需要输入密码（前提配置了密码 requirepass ）即可，不需要输入用户名，而且密码也是明文配置到配置文件中，安全性不高。并且应用连接也使用该密码，导致应用有所有权限处理数据，风险也极高。在Redis6.0有了ACL之后，终于解决了这些不安全的因素，可以按照不同的需求设置相关的用户和权限。本文来介绍下Redis 6.0 ACL相关的配置和使用。具体的说明可以查看官方文档：ACL 说明 ​ Redis ACL 是向后兼容的，即默认情况下用户为default，使用的是requirepass配置的密码。要是不使用ACL功能，对旧版客户端来说完全一样。Redis Auth可以有2种方式进行工作： 1:旧版本的使用方式，默认用户。兼容旧版本Redis的支持 AUTH <password> 2:新方式，还需要验证用户名 AUTH <username> <password> 因为需要验证用户名了，所以客户端的认证方式也多了参数： --user <username> 验证用户名 --pass <password> 验证密码,是参数-a的别名;配合--user使用 --askpass 强制用户输入带有STDIN掩码的密码 现在开始来说明如何在Redis中根据ACL来定制需要的用户权限。首先看ACL的help，了解大致的使用方法：ACL help > ACL help 1) ACL <subcommand> arg arg ... arg. Subcommands are: 2) LOAD -- 从ACL文件中重新载入用户信息. 3) SAVE -- 保存当前的用户配置信息到ACL文件. 4) LIST -- 以配置文件格式显示用户详细信息. 5) USERS -- 列出所有注册的用户名. 6) SETUSER <username> [attribs ...] -- 创建或则修改一个用户.

原文地址：https://cloud.tencent.com/developer/article/1740907 一、Redis6.0之前为什么采用单线程模型 严格地说，从Redis 4.0之后并不是单线程。除了主线程外，还有一些后台线程处理一些较为缓慢的操作，例如无用连接的释放、大 key 的删除等等。 单线程模型，为何性能那么高？ Redis作者从设计之初，进行了多方面的考虑。最终选择使用单线程模型来处理命令。之所以选择单线程模型，主要有如下几个重要原因： Redis操作基于内存，绝大多数操作的性能瓶颈不在CPU 单线程模型，避免了线程间切换带来的性能开销 使用单线程模型也能并发的处理客户端的请求（多路复用I/O） 使用单线程模型，可维护性更高，开发，调试和维护的成本更低 上述第三个原因是Redis最终采用单线程模型的决定性因素，其他的两个原因都是使用单线程模型额外带来的好处，在这里我们会按顺序介绍上述的几个原因。 性能瓶颈不在CPU 下图是Redis官网对单线程模型的说明。大概意思是：Redis的瓶颈并不在CPU，它的主要瓶颈在于内存和网络。在Linux环境中，Redis每秒甚至可以提交100万次请求。 为什么说Redis的瓶颈不在CPU？ 首先，Redis绝大部分操作是基于内存的，而且是纯kv（key-value）操作，所以命令执行速度非常快。我们可以大概理解成，redis中的数据存储在一张大HashMap中，HashMap的优势就是查找和写入的时间复杂度都是O(1)。Redis内部采用这种结构存储数据，就奠定了Redis高性能的基础。根据Redis官网描述，在理想情况下Redis每秒可以提交一百万次请求，每次请求提交所需的时间在纳秒的时间量级。既然每次的Redis操作都这么快，单线程就可以完全搞定了，那还何必要用多线程呢！ 线程上下文切换问题 另外，多线程场景下会发生线程上下文切换。线程是由CPU调度的，CPU的一个核在一个时间片内只能同时执行一个线程，在CPU由线程A切换到线程B的过程中会发生一系列的操作，主要过程包括保存线程A的执行现场，然后载入线程B的执行现场，这个过程就是“线程上下文切换”。其中涉及线程相关指令的保存和恢复。 频繁的线程上下文切换可能会导致性能急剧下降，这会导致我们不仅没有提升处理请求的速度，反而降低了性能，这也是 Redis 对于多线程技术持谨慎态度的原因之一。 在Linux系统中可以使用vmstat命令来查看上下文切换的次数，下面是vmstat查看上下文切换次数的示例： vmstat 1 表示每秒统计一次, 其中cs列就是指上下文切换的数目. 一般情况下, 空闲系统的上下文切换每秒在1500以下。 并行处理客户端的请求（I/O多路复用） 如上所述：Redis的瓶颈并不在CPU，它的主要瓶颈在于内存和网络。所谓内存瓶颈很好理解，Redis做为缓存使用时很多场景需要缓存大量数据，所以需要大量内存空间，这可以通过集群分片去解决，例如Redis自身的无中心集群分片方案以及Codis这种基于代理的集群分片方案。 对于网络瓶颈，Redis在网络I/O模型上采用了多路复用技术，来减少网络瓶颈带来的影响。很多场景中使用单线程模型并不意味着程序不能并发的处理任务。Redis 虽然使用单线程模型处理用户的请求，但是它却使用 I/O 多路复用技术“并行”处理来自客户端的多个连接，同时等待多个连接发送的请求。使用 I/O多路复用技术能极大地减少系统的开销，系统不再需要为每个连接创建专门的监听线程，避免了由于大量的线程创建带来的巨大性能开销。 下面我们详细解释一下多路复用I/O模型。为了能更充分理解，我们先了解几个基本概念。 Socket（套接字）：Socket可以理解成，在两个应用程序进行网络通信时，分别在两个应用程序中的通信端点。通信时，一个应用程序将数据写入Socket，然后通过网卡把数据发送到另外一个应用程序的Socket中。我们平常所说的HTTP和TCP协议的远程通信，底层都是基于Socket实现的。5种网络IO模型也都要基于Socket实现网络通信。 阻塞与非阻塞：所谓阻塞，就是发出一个请求不能立刻返回响应，要等所有的逻辑全处理完才能返回响应。非阻塞反之，发出一个请求立刻返回应答，不用等处理完所有逻辑。 内核空间与用户空间：在Linux中，应用程序稳定性远远比不上操作系统程序，为了保证操作系统的稳定性，Linux区分了内核空间和用户空间。可以这样理解，内核空间运行操作系统程序和驱动程序，用户空间运行应用程序。Linux以这种方式隔离了操作系统程序和应用程序，避免了应用程序影响到操作系统自身的稳定性。这也是Linux系统超级稳定的主要原因。所有的系统资源操作都在内核空间进行，比如读写磁盘文件，内存分配和回收，网络接口调用等。所以在一次网络IO读取过程中，数据并不是直接从网卡读取到用户空间中的应用程序缓冲区，而是先从网卡拷贝到内核空间缓冲区，然后再从内核拷贝到用户空间中的应用程序缓冲区。对于网络IO写入过程，过程则相反，先将数据从用户空间中的应用程序缓冲区拷贝到内核缓冲区，再从内核缓冲区把数据通过网卡发送出去。 多路复用I/O模型，建立在多路事件分离函数select，poll，epoll之上。以Redis采用的epoll为例，在发起read请求前，先更新epoll的socket监控列表，然后等待epoll函数返回（此过程是阻塞的，所以说多路复用IO本质上也是阻塞IO模型）。当某个socket有数据到达时，epoll函数返回。此时用户线程才正式发起read请求，读取并处理数据。这种模式用一个专门的监视线程去检查多个socket，如果某个socket有数据到达就交给工作线程处理。由于等待Socket数据到达过程非常耗时，所以这种方式解决了阻塞IO模型一个Socket连接就需要一个线程的问题，也不存在非阻塞IO模型忙轮询带来的CPU性能损耗的问题。多路复用IO模型的实际应用场景很多，大家耳熟能详的Redis，Java NIO，以及Dubbo采用的通信框架Netty都采用了这种模型。 下图是基于epoll函数Socket编程的详细流程。 可维护性 我们知道，多线程可以充分利用多核CPU，在高并发场景下，能够减少因I/O等待带来的CPU损耗，带来很好的性能表现。不过多线程却是一把双刃剑，带来好处的同时，还会带来代码维护困难，线上问题难于定位和调试，死锁等问题。多线程模型中代码的执行过程不再是串行的，多个线程同时访问的共享变量如果处理不当也会带来诡异的问题。 我们通过一个例子，看一下多线程场景下发生的诡异现象。看下面的代码： class MemoryReordering { int num = 0; boolean flag = false; public void set() { num = 1; //语句1 flag = true; //语句2 } public int cal() { if( flag == true) { //语句3 return num + num; //语句4 } return -1； } } flag为true时，cal() 方法返回值是多少？很多人会说：这还用问吗！肯定返回2

原文地址 https://developpaper.com/redis-6-0-multithreading-performance-test-results-and-analysis/ Redis 6.0 多线程性能测试和分析 因为做的主要是低延迟的内存操作，CPU不是内存操作的瓶颈，最可能的瓶颈是网络IO操作。Redis6.0支持多线程，只是套接字层面的多线程，主要的内存读写仍是多线程模式。 测试环境 测试配置：CENTOS 7, 16核CPU 32G内存 Redis version: 6.0.6 分别配置 1线程、2线程、4线程、6线程、8线程和10线程，200并发链接处理1亿请求。为避免网络延迟，redis-benchmark进行本地测试。 redis-benchmark -d 128 -c 200 -n 1000000 -t set -q --threads 8 坑 坑1 CENTOS7 默认的GCC版本是 4.* ， Redis6.0不能直接编译，因此需要升级GCC，因为机器不支持Yum 安装，所以需要用源码编译，又因为需要一些其他依赖，所以扁蓄用了一些时间。 坑2 要测试多线程IO，redis-benchmark也必须加 --threads来使用多线程模式测试。 测试结果及分析 不同线程数下100Wget/set请求的QPS结果 可以看出： 2个线程的QPS为18W/s，大约于单线程的9W/s的两倍。4线程相对于2线程，有约30%的提升。 对于set操作，4线程、6线程、8线程的QPS没太大差别，约为23W~24W。8线程相对于4到6线程，有约10%的提升。 6线程或10线程，与最高效的8线程相比，性能开始下降，效果与4线程或6线程等同。 因此，本地环境，I/O线程数设置2个或4个就可以，最大不要超过8个，否则性能会降级。但是要注意，要么不开，要开线程数最低也得设置为1个。 下面是不同线程数下GET/SET的QPS比较。 io-threads-do-reads 测试 io-threads-do-reads参数用于设置读取套接字操作是否使用多线程操作。Redis套接字读取使用多路复用技术，本身不回成为瓶颈。现在测下配置这个参数是否会对性能有所改善。 从下图可以看出，io-threads-do-reads开不开对性能影响不大。 开启多线程且开启多线程读取套接字，线程数设置为2: 开启多线程关闭多线程套读取套接字，线程数设置为2：

https://mp.weixin.qq.com/s/ecilhMZE6ZK9G_icybnEdQ Redis6.0新特性-Thread/IO多线程 一、背景 目前快手有70w+的Redis实例，在线上的Redis集群，我们经常会碰到以下的一些情况： （1） 由于键值设计不合理或者业务特性导致的热点问题（集群整体QPS不高，但是集群内某个实例的请求特别高），严重影响业务侧请求的返回时间 （2） 集群内某个实例直连集群连接数过多，单线程模型处理缓慢，影响其他的请求 （3） 集群内某个实例网络不稳定后者pipeline个数较多，导致协议解析频繁调用，导致cpu时间占用过长，影响其他的客户端请求 以上这些问题，相信大家也都碰到过，那么这些问题与Redis的单线程模型又有什么关系？ 1. 为什么Redis6之前是单线程设计？ 首先，我们明确一点，Redis6之前的Redis4，Redis5并不是单线程程序。通常我们说的Redis的单线程，是指Redis接受链接，接收数据并解析协议，发送结果等命令的执行，都是在主线程中执行的。 Redis之前之所以将这些都放在主线程中执行，主要有以下几方面的原因： Redis的主要瓶颈不在cpu，而在内存和网络IO 使用单线程设计，可以简化数据库结构的设计 可以减少多线程锁带来的性能损耗 2. 什么是IO多线程？ 既然Redis的主要瓶颈不在CPU，为什么又要引入IO多线程？Redis的整体处理流程如下图： 结合上图可知，当 socket 中有数据时，Redis 会通过系统调用将数据从内核态拷贝到用户态，供 Redis 解析用。这个拷贝过程是阻塞的，术语称作 “同步阻塞IO”，数据量越大拷贝的延迟越高，解析协议时间消耗也越大，糟糕的是这些操作都是在主线程中处理的，特别是链接数特别多的情况下，这种情况更加明显。基于以上原因，Redis作者提出了Thread/IO线程，既将接收与发送数据来使用多线程并行处理，从而降低主线程的等待时间。 二、Thread/IO整体流程及程序实现设计 1.Thread/IO整体实现思路 (1).创建一组大小为io线程个数的等待队列，用来存储客户端的网络套接字。 (2).分均分配客户端网络套接字到等待队列中 (3).等待线程组接收解协议完毕或者发送数据完毕 (4).执行后续操作，然后跳转到第2步继续执行 2.Thread/IO涉及到的代码文件 关于IO多线程部分的代码，在src/network.c中。 3.Thread/IO整体流程图 三、关键代码流程详解 1.io线程的初始化 Redis多线程相关线程的初始化顺序 初始化相关流程图及代码创建线程流程图 创建线程代码具体位置 src/network.c: initThreadIO(void) src/network.c: IOThreadMain(void *) 2.readQueryFromClient部分 代码具体位置：src/network.c: readQueryFromClient(connection *) void readQueryFromClient(connection *conn) { client *c = connGetPrivateData(conn); int nread, readlen; size_t qblen; /* Check if we want to read from the client later when exiting from * the event loop.

源文地址：https://www.zeekling.cn/articles/2021/08/01/1627817134014.html Redis 6实现了通道加密，提高了redis的安全性。Redis作为缓存数据库，里面很有可能缓存重要的敏感信息，所以支持tls通道加密还是很有必要的，当然敏感信息还是建议加密保存。 创建证书 mkdir -p tests/tls openssl genrsa -out tests/tls/ca.key 2048 openssl req \ -x509 -new -nodes -sha256 \ -key tests/tls/ca.key \ -days 3650 \ -subj '/O=Redis Test/CN=Certificate Authority' \ -out tests/tls/ca.crt openssl genrsa -out tests/tls/redis.key 2048 openssl req \ -new -sha256 \ -key tests/tls/redis.key \ -subj '/O=Redis Test/CN=Server' | \ openssl x509 \ -req -sha256 \ -CA tests/tls/ca.

原文地址：https://www.kawabangga.com/posts/3590 Redis客户端缓存设计（In-Process caching） 今天看 antirez 写了一篇有关客户端缓存设计的想法：《Client side caching in Redis 6》（文章比较难懂，如果先看 Ben 演讲，理解起来 antirez 这篇博客会轻松一些）。antirez 认为，redis 接下来的一个重点是配合客户端，因为客户端缓存显而易见的可以减轻 redis 的压力，速度也快很多。大公司或多或少都有实现这种应用端缓存的机制，antirez 想通过 server 端的一些设计来减少客户端缓存实现的复杂度和成本，甚至不惜在 redis 协议上做修改。 antirez 的博客对细节介绍的比较清楚，我这篇文章算是拾人牙慧了，一来理清一下自己的思路，二来我认为除了缓存，这个机制还可以用在实时控制应用程序的某些配置上面。跟大家分享一下。 一、缓存的数据一致性问题 通常我们谈论缓存一致性的时候，一般在谈的都是这种架构：应用有一个数据库和缓存，数据库中的常用数据会被放到缓存中，在这种场景下如何保证数据库的数据和缓存中的数据是一致的？这种其实比较好解决，Cache-aside 模式已经是比较成熟和通用的了，实现上也比较简单和可靠。 Remember kids: you either have a single source of truth, or multiple sources of lies. 但 Redis 这种缓存从某种意义上还是一种远程的缓存，每次缓存读取会增加一次 TCP RTT（这个影响个人认为随着技术发展会逐渐减少），数据的序列化和反序列化也需要资源。如果对效率有更高的要求，就要考虑进程内缓存了。 进程内缓存的数据一致性比分布式的缓存面临更大的挑战。一个进程更新的时候，如何通知其他进程也更新自己的缓存呢？如果按照分布式缓存的思路，我们可以缩短缓存过期时间，进程内缓存如果过期了就去分布式缓存获取数据。这样不必实现复杂的通知机制，但是不同进程内的数据依然会面临不一致的问题，并且不同进程缓存过期时间不统一，用户体验也不好，同一个请求到了不同的进程，可能出现反复幻读的情况。另外也会对分布式进行大量不必要的更新，浪费网络资源。 进程内缓存面临2个主要的问题是： 保证数据的一致性，包括各个进程缓存的数据要是一致的，进程缓存和 Redis 缓存要是一致的； 尽可能减小网络压力； 为了实现所有进程的缓存的一致性，显而易见的实现是，当一个 key value 被修改了，广播被修改的键值对。所有客户端收到广播的时候更新自己的 kv。这种实现的缺点是1）有可能一个进程收到两个冲突的广播，无法解决。2）广播键值对，这样修改缓存的代价太大了。基于这两点，可以想到优化方案是我们只广播更新的 key，Redis 的缓存最为 Source of Truth，客户端收到了 key 更新的消息，就去 Redis 获得最新的键值对。这样就解决了冲突的问题，对资源的消耗也少了。

原文地址：https://www.cnblogs.com/binecy/p/15399578.html 本文探究Redis最新特性–客户端缓存在SpringBoot上的应用实战。 Redis Tracking Redis客户端缓存机制基于Redis Tracking机制实现的。我们先了解一下Redis Tracking机制。 为什么需要Redis Tracking Redis由于速度快、性能高，常常作为MySQL等传统数据库的缓存数据库。但由于Redis是远程服务，查询Redis需要通过网络请求，在高并发查询情景中难免造成性能损耗。所以，高并发应用通常引入本地缓存，在查询Redis前先检查本地缓存是否存在数据。 假如使用MySQL存储数据，那么数据查询流程下图所示。 引入多端缓存后，修改数据时，各数据缓存端如何保证数据一致是一个难题。通常的做法是修改MySQL数据，并删除Redis缓存、本地缓存。当用户发现缓存不存在时，会重新查询MySQL数据，并设置Redis缓存、本地缓存。 在分布式系统中，某个节点修改数据后不仅要删除当前节点的本地缓存，还需要发送请求给集群中的其他节点，要求它们删除该数据的本地缓存，如下图所示。如果分布式系统中节点很多，那么该操作会造成不少性能损耗。 为此，Redis 6提供了Redis Tracking机制，对该缓存方案进行了优化。开启Redis Tracking后，Redis服务器会记录客户端查询的所有键，并在这些键发生变更后，发送失效消息通知客户端这些键已变更，这时客户端需要将这些键的本地缓存删除。基于Redis Tracking机制，某个节点修改数据后，不需要再在集群广播“删除本地缓存”的请求，从而降低了系统复杂度，并提高了性能。 Redis Tracking的应用 下表展示了Redis Tracking的基本使用 （1）为了支持Redis服务器推送消息，Redis在RESP2协议上进行了扩展，实现了RESP3协议。HELLO 3命令表示客户端与Redis服务器之间使用RESP3协议通信。 注意：Redis 6.0提供了Redis Tracking机制，但该版本的redis-cli并不支持RESP3协议，所以这里需要使用Redis 6.2版本的redis-cli进行演示。 （2）CLIENT TRACKING on命令的作用是开启Redis Tracking机制，此后Redis服务器会记录客户端查询的键，并在这些键变更后推送失效消息通知客户端。失效消息以invalidate开头，后面是失效键数组。 上表中的客户端 client1 查询了键 score 后，客户端 client2 修改了该键，这时 Redis 服务器会马上推送失效消息给客户端 client1，但 redis-cli 不会直接展示它收到的推送消息，而是在下一个请求返回后再展示该消息，所以 client1 重新发送了一个 PING请求。 上面使用的非广播模式，另外，Redis Tracking还支持广播模式。在广播模式下，当变更的键以客户端关注的前缀开头时，Redis服务器会给所有关注了该前缀的客户端发送失效消息，不管客户端之前是否查询过这些键。 下表展示了如何使用Redis Tracking的广播模式。 说明一下CLIENT TRACKING命令中的两个参数： BCAST参数：启用广播模式。 PREFIX参数：声明客户端关注的前缀，即客户端只关注cache开头的键。 强调一下非广播模式与广播模式的区别： 非广播模式：Redis服务器记录客户查询过的键，当这些键发生变化时，Redis发送失效消息给客户端。 广播模式：Redis服务器不记录客户查询过的键，当变更的键以客户端关注的前缀开头时，Redis就会发送失效消息给客户端。 关于Redis Tracking的更多内容，我已经在新书《Redis核心原理与实践》中详细分析，这里不再赘述。 Redis客户端缓存 既然Redis提供了Tracking机制，那么客户端就可以基于该机制实现客户端缓存了。 Lettuce实现 Lettuce（6.

原文地址：https://ost.51cto.com/posts/12719 作者 |Dr Hydra 来源 | 码农参上（ID：CODER_SANJYOU） 哈喽大家好啊，我是Hydra。 在前面的文章中，我们介绍了Redis6.0中的新特性客户端缓存client-side caching，通过telnet连接模拟客户端，测试了三种客户端缓存的工作模式，这篇文章我们就来点硬核实战，看看客户端缓存在java项目中应该如何落地。 铺垫 首先介绍一下今天要使用到的工具Lettuce，它是一个可伸缩线程安全的redis客户端。多个线程可以共享同一个RedisConnection，利用nio框架Netty来高效地管理多个连接。 放眼望向现在常用的redis客户端开发工具包，虽然能用的不少，但是目前率先拥抱redis6.0，支持客户端缓存功能的却不多，而lettuce就是其中的领跑者。 我们先在项目中引入最新版本的依赖，下面正式开始实战环节： <dependency> <groupId>io.lettuce</groupId> <artifactId>lettuce-core</artifactId> <version>6.1.8.RELEASE</version> </dependency> 实战 在项目中应用lettuce，开启并使用客户端缓存功能，只需要下面这一段代码： public static void main(String[] args) throws InterruptedException { // 创建 RedisClient 连接信息 RedisURI redisURI= RedisURI.builder() .withHost("127.0.0.1") .withPort(6379) .build(); RedisClient client = RedisClient.create(redisURI); StatefulRedisConnection<String, String> connect = client.connect(); Map<String, String> map = new HashMap<>(); CacheFrontend<String,String> frontend=ClientSideCaching.enable(CacheAccessor.forMap(map), connect, TrackingArgs.Builder.enabled().noloop()); String key="user"; while (true){ String value = frontend.get(key); System.out.println(value); TimeUnit.SECONDS.sleep(10); } } 上面的代码主要完成了几项工作：