Redis：性能优化之Redis 6.0的新特性

【关于作者】

关于作者，目前在蚂蚁金服搬砖任职，在支付宝营销投放领域工作了多年，目前在专注于内存数据库相关的应用学习，如果你有任何技术交流或大厂内推及面试咨询，都可以从我的个人博客（https://0522-isniceday.top/）联系我
Redis 6.0新增的特性如下：

• 面向网络处理的多IO线程
• 客户端缓存
• 细粒度的权限控制
• RESP 3协议的使用

1.从单线程处理网络请求到多线程处理

具体见文章：

2.实现服务端协助的客户端缓存

Redis 6.0新的了客户端协助的客户端缓存功能，这样能够让客户端读取的数据缓存在本地，应用则可以快速的直接读取本地数据了，称为跟踪（Tracking）功能

面对redis数据的写场景，客户端如何做到数据一致的呢？redis的Tracking提供了两种模式：

（1）普通模式：

实例会记录客户端读取过的key，并监控该key的修改，修改后会发送invalidate消息，通知客户端缓存失效了，清除该缓存。这里只会发送一次invalidate消息，只有当客户端下一次请求key时才会再次监控，监控是一次性的，这样是为了节省服务端有限的内存空间，如果客户端都不使用（读）这个key了，那么监控自然是没有意义的

我们可以通过执行下面的命令，打开或关闭普通模式下的Tracking功能。

CLIENT TRACKING ON|OFF

（2）广播模式

服务端会给客户端广播所有key失效的情况，不过如果key被频繁修改，那么就会频繁通知，浪费网络资源。

实际应用中，我们会让客户端注册希望监听的key前缀，只有当匹配的key发生修改时才会通知，和普通模式不同的是，针对key的注册一次。后续所有的修改都会通知

例：

务端更新了user​：id:1003这个key，那么，客户端就会收到invalidate消息。

CLIENT TRACKING ON BCAST PREFIX user

以上两种模式都是针对RESP 3协议的客户端，针对RESP 2协议的客户端我们有如下的模式：

（3）重定向模式

该模式是使用了订阅命令SUBSCRIBE，专门订阅用于发布失效消息的频道_redis_:invalidate，同时，再使用另外一个客户端，执行CLIENT TRACKING命令，设置服务端将失效消息转发给使用RESP 2协议的客户端

例如RESP 2的客户端B，RESP 3的客户端A，如果B想获取失效消息，则操作如下：

//客户端B执行，客户端B的ID号是303
SUBSCRIBE _redis_:invalidate

//客户端A执行
CLIENT TRACKING ON BCAST REDIRECT 303

3.ACL权限控制

Redis 6.0 从简单的基于密码访问到细粒度的权限控制，

6.0之前，只能给客户端创建一个密码来限制访问，对于高风险的命令Keys、FULSHDB、FLUSHALL等，只能通过rename-command来重命名这些指令，防止客户端调用

6.0之后，

• 支持创建不同用户来使用Redis，使用ACL SETUSER命令创建用户

  ACL SETUSER normaluser on > abc
  

• 支持以用户为粒度设置命令的权限操作的访问权限

  例如：

  置用户normaluser只能调用Hash类型的命令操作，而不能调用String类型的命令操作，我们可以执行如下命令：

  ACL SETUSER normaluser +@hash -@string
  

  

• 支持以用户为粒度设置key的访问权限

  用波浪号“~”和key的前缀来表示控制访问的key，例如：

  设置用户normaluser只能对以“user:”为前缀的key进行命令操作：

  ACL SETUSER normaluser ~user:* +@all
  

4.启用RESP 3协议

Redis 6.0实现了RESP 3通信协议，而之前都是使用的RESP 2。在RESP 2中，客户端和服务器端的通信内容都是以字节数组形式进行编码的，客户端需要根据操作的命令或是数据类型自行对传输的数据进行解码，增加了客户端开发复杂度。

而RESP 3直接支持多种数据类型的区分编码，包括空值、浮点数、布尔值、有序的字典集合、无序的集合等。

所谓区分编码，就是指直接通过不同的开头字符，区分不同的数据类型，这样一来，客户端就可以直接通过判断传递消息的开头字符，来实现数据转换操作了，提升了客户端的效率。除此之外，RESP 3协议还可以支持客户端以普通模式和广播模式实现客户端缓存。