Redis6.0新特性
Redis6.0新特性
从单线程处理网络请求到多线程处理
在之前Redis 一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF 重写），但是，从网络 IO 处理到实际的读写命令处理，都是由单个线程完成的。
但是后来硬件的发展，单个主线程处理网络请求的速度跟不上底层网络硬件的速度。
Redis6.0为了解决这个问题，采用了多个 IO 线程来处理网络请求，提高网络请求处理的并行度的方案。但是，Redis 的多 IO 线程只是用来处理网络请求的，对于读写命令，Redis 仍然使用单线程来处理。
具体多个IO线程的使用是在解析请求以及写会响应的阶段（利用并行提高速度）：
相关设置：
- 开启多线程：
io-threads-do-reads yes - 设置多线程数量：
io-threads 6（一般来说，线程个数要小于 Redis 实例所在机器的 CPU 核个数，例如，对于一个 8 核的机器来说，Redis 官方建议配置 6 个 IO 线程。）
实现服务端协助的客户端缓存
和之前的版本相比，Redis 6.0 新增了一个重要的特性，就是实现了服务端协助的客户端缓存功能，也称为跟踪（Tracking）功能。有了这个功能，业务应用中的 Redis 客户端就可以把读取的数据缓存在业务应用本地了，应用就可以直接在本地快速读取数据了。
Redis为了解决客户端本地与服务端数据不一致的问题，有两种模式：
普通模式
在这个模式下，实例会在服务端记录客户端读取过的 key，并监测 key 是否有修改。一旦 key 的值发生变化，服务端会给客户端发送 invalidate 消息，通知客户端缓存失效了。但是服务端只会通知一次，如果再次被修改不会进行通知。只有当客户端再次执行读命令时，服务端才会再次监测被读取的 key，并在 key 修改时发送 invalidate 消息。
打开或关闭普通模式下的 Tracking 功能：
CLIENT TRACKING ON|OFF广播模式
在这个模式下，服务端会给客户端广播所有 key 的失效情况，不过，这样做了之后，如果 key 被频繁修改，服务端会发送大量的失效广播消息，这就会消耗大量的网络带宽资源。
所以，在实际应用时，我们会让客户端注册希望跟踪的 key 的前缀，当带有注册前缀的 key 被修改时，服务端会把失效消息广播给所有注册的客户端。
例子：如果服务端更新了
user:id:1003这个 key，那么，客户端就会收到 invalidate 消息：CLIENT TRACKING ON BCAST PREFIX user
从简单的基于密码访问到细粒度的权限控制
Redis 6.0 提供了更加细粒度的访问权限控制。
支持创建不同用户来使用 Redis：
在 6.0 版本前，所有客户端可以使用同一个密码进行登录使用，但是没有用户的概念，而在 6.0 中，我们可以使用 ACL SETUSER 命令创建用户。
例如：
ACL SETUSER normaluser on > abc来创建并启用一个用户 normaluser，把它的密码设置为“abc”支持以用户为粒度设置命令操作的访问权限
具体操作列在了下表中
操作：
ACL SETUSER normaluser +@hash -@string(设置用户 normaluser 只能调用 Hash 类型的命令操作，而不能调用 String 类型的命令操作)还支持以 key 为粒度设置访问权限：
例如，我们执行下面命令，就可以设置用户 normaluser 只能对以“user:”为前缀的 key 进行命令操作：
ACL SETUSER normaluser ~user:* +@all
启用 RESP 3 协议
与之前使用的 RESP 2的区别：
- 之前使用的是字节数组形式进行编码的，现在用支持多种数据类型的区分编码（指直接通过不同的开头字符，区分不同的数据类型）
- 还可以支持客户端以普通模式和广播模式实现客户端缓存
总结
