Redis 6 新特性探索 ~ （新技术的迭代潮流中，我们怎能缺席？）

唠唠嗑

博主深深坚信，当下程序员不能只搬砖，要勇于站在技术潮流的前沿，踩别人没踩过的坑，抗别人没扛过的雷，这样才能成为一名优秀的，有理想，有追求，有抱负的社会主义接班人(๑•̀ㅂ•́)و✧

闲来无事，刷刷技术推文，发现Redis 6 已经发行正式版本，而且已经发行两个月了，那么我们怎么能不去了解一下它又怎么更牛逼了呢?而且现实中，我们难免会技术支持帮忙维护一些已完成的项目，所以了解各个版本之间的差异还是很有必要的( ﹁ ﹁ ) ~→

ps（有理解不到位的情况欢迎探讨）

如：

• redis3.0之后才有 高可用集群 cluster（据官方文档称可以线性扩展到上万个节点） ，而在3.0之前要实现都是用哨兵。
• redis4.0之前，持久化都是AOF或者RDB，但在4.0之后提供了混合持久化。
• redis4.0 之前只实现了6种内存淘汰策略，在4.0之后实现了8种。
• …

正文

一起看看 redis 6

先附上 github 地址
https://github.com/lettuce-io/lettuce-core/releases
再附上 文档地址
https://lettuce.io/core/6.0.0.RELEASE/reference/

github上有对新的更新做一点描述，如下：

改动还是蛮多的，但是文档会更清晰：

对于其中的一些如：

• Lua 脚本编写可以用字节[]或字符串。
• 编译方式的改动。
• 删除一些超时方法。
• 移除spring的支持，改为 Spring Data Redis 。
• …

这边就不详细讲解，主要讲解以下三大新特性。

Redis 支持多线程了？？？（多线程）

都知道，redis 好用，快，是因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。

但是它严格意义上来说也并非是单线程的，因为Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

之所以说它单线程，是指执行用户命令的请求时单线程。

而现在，redis 6.0 提供了多线程的读写IO, 不过最终执行用户命令的线程依然是单线程的，这样，就没有多线程数据的竞争关系。

redis 6.0 以前线程执行模式 大致如下。

在单线程里面不断的读命令，解析命令，执行命令，写命令 的过程，在6.0里面，我们只需要设置两个参数就能使他变成多线程，参数如下：

io-threads 4 

ps(数配置多线程模型)

io-threads-do-reads yes

ps（将支持IO线程执行 读写任务。）

配置之后，执行模型大致如下：

它的多线程，是在读命令和分析命令的时候多线程执行，但是在具体操作的时候，还是使用了单线程的模式。所以，启用了多线程是在读取命令和分析命令的时候性能提升。

但是！！！Redis6.0的多线程有一个地方非常有趣！！！！

我在文档中看到这么一段描述

Usually threading reads doesn't help much.

翻译过来的意思是：通常情况下，开启读多线程不会有太大的性能提升！！

缓存缓存 （Client Side Cache）

啥都不说，先上描述

官方描述的非常清晰，开发人员认为数据缓存在客户端性能会更高，比如数据没有发生什么变化的时候，是没有必要再去redis去拿的，因为访问redis需要一些请求操作，没有直接从客户端获取来的快速。所以官方推出了客户端缓存这一新特性。

文档上认为，客户端缓存有两个关键优势

• 数据的可用性具有非常小的延迟。
• 数据库系统接收的查询更少，允许用更少的节点来服务相同的数据集。

还举了网络中社交帖子的例子，证明这一新特性是很有必要的。

执行步骤大致如下：当客户端访问某个key时，服务端将记录key 和 client ，客户端拿到数据后，进行客户端缓存，这时，当key再次被访问时，key将被直接返回，避免了与redis 服务器的再次交互，节省服务端资源，当数据被其他请求修改时，服务端将主动通知客户端失效的key，客户端进行本地失效，下次请求时，重新获取最新数据。

不过有一点最坑的就是，这一功能暂时不支持集群，只支持单机！！￣へ￣

洒家也要有权限（Acls）

在Redis6.0以前，只要你有用户名密码，你登入成功之后就可以对redis进行任何操作，其实这是不太友好的，所以在Redis6.0之后，增加了用户权限（用户名密码）这一功能，可以使得没有赋值权限的操作无法执行。

这边的详细操作，官方文档也是描述的比较详细的，我把链接附上。

https://redis.io/topics/acl

所有权限相关操作都有，这边稍微讲解一下。

ACL设置有两种方式

• 命令行：ACL SETUSER + 具体的权限规则， 通过 ACL SAVE 进行持久化。
• 配置文件：对 ACL 配置文件进行编写，并且执行 ACL LOAD 进行加载。

我们可以使用ACL LIST命令来检查当前激活的ACL，并验证新启动的默认配置的Redis实例的配置是什么。

使用 ACL SETUSER 进行用户的添加，添加完后我们可以查看添加的数据

添加数据成功，后面的 off 表示状态是禁用的意思。代表这个用户啥事都不能做，只有 成为 on 才行。

现在我们尝试定义用户，使其处于活动状态，具有密码，并且只能使用GET命令访问以字符串“cached:”开头的键名。

ACL SETUSER alice on >p1pp0 ~cached:* +get

用户名为 alice 密码为 p1pp0

现在我们切换为刚才设置的用户：

AUTH alice p1pp0

并且对数据执行操作：

这时候，我们发现对用户进行了权限以外的操作会失败，只有权限以内的权限才能成功。

不过如果所有权限都这样添加肯定会很累，所以官方提供了类别的概念。

瞧瞧人家程序员，playing ，这对待代码的态度就不一样，哪像 -> 我 （＃￣～￣＃）

上面的意思是，授予了所有权限，除了 dangerous 操作的权限。

要看具体的类别可以用以下命令：ACL CAT

如果想看 dangerous 类别下有哪些命令，可以通过

ACL CAT dangerous  

进行查看。

注意点

我们所添加的用户是没有被持久化的，需要手动执行。

CONFIG REWRITE 

执行完后数据被写入了配置文件 redis.conf ,所以我们也可以直接在配置文件进行写用户，启动的时候，系统就能自动加载了。

具体更复杂的操作可以查看官方文档。