Redis 6.0+ 版本主要性与变化
1、单线程 ---> 多线程处理网络IO
Redis的限制并不在于CPU，限制主要在于IO网络与内存上，所以6.0版本更新主要在于IO网络的多线程处理。
Redis is mostly single threaded, however there are certain threaded operations such as UNLINK, slow I/O accesses and other things that are performed on side threads.
关于线程数的设置，官方有一个建议：4核的机器建议设置为2或3个线程，8核的建议设置为6个线程，线程数一定要小于机器核数。还需要注意的是，线程数并不是越大越好，官方认为超过了8个基本就没什么意义了。
如果开启多线程，至少要4核的机器，且Redis实例已经占用相当大的CPU耗时的时候才建议采用，否则使用多线程没有意义。
开启配置如下：
io-threads-do-reads no //是否开启线程
io-threads 4 //线程数官方配置使用原文：
################################ THREADED I/O #################################
# Now it is also possible to handle Redis clients socket reads and writes
# in different I/O threads. Since especially writing is so slow, normally
# Redis users use pipelining in order to speed up the Redis performances per
# core, and spawn multiple instances in order to scale more. Using I/O
# threads it is possible to easily speedup two times Redis without resorting
# to pipelining nor sharding of the instance.
#
# By default threading is disabled, we suggest enabling it only in machines
# that have at least 4 or more cores, leaving at least one spare core.
# Using more than 8 threads is unlikely to help much. We also recommend using
# threaded I/O only if you actually have performance problems, with Redis
# instances being able to use a quite big percentage of CPU time, otherwise
# there is no point in using this feature.
#
# So for instance if you have a four cores boxes, try to use 2 or 3 I/O
# threads, if you have a 8 cores, try to use 6 threads. In order to
# enable I/O threads use the following configuration directive:
#
# io-threads 4
#
# Setting io-threads to 1 will just use the main thread as usual.
# When I/O threads are enabled, we only use threads for writes, that is
# to thread the write(2) syscall and transfer the client buffers to the
# socket. However it is also possible to enable threading of reads and
# protocol parsing using the following configuration directive, by setting
# it to yes:
#
# io-threads-do-reads no
#
# Usually threading reads doesn't help much.
#
# NOTE 1: This configuration directive cannot be changed at runtime via
# CONFIG SET. Also, this feature currently does not work when SSL is
# enabled.
#
# NOTE 2: If you want to test the Redis speedup using redis-benchmark, make
# sure you also run the benchmark itself in threaded mode, using the
# --threads option to match the number of Redis threads, otherwise you'll not
# be able to notice the improvements.2、客户端缓存 Client-side caching in Redis
2.1 什么是客户端缓存？
客户端缓存是一种用于创建高性能服务的技术。它利用应用程序服务器上可用的内存，与数据库节点相比，服务器通常是不同的计算机，将数据库信息的某些子集直接存储在应用程序端。
通常，当需要数据时，应用服务器会向数据库询问此类信息，如下图所示：
+-------------+ +----------+
| | ------- GET user:1234 -------> | |
| Application | | Database |
| | <---- username = Alice ------- | |
+-------------+ +----------+当使用客户端缓存时，应用程序会将流行查询的回复直接存储在应用程序内存中，以便以后可以重复使用这些回复，而无需再次联系数据库：
+-------------+ +----------+
| | | |
| Application | ( No chat needed ) | Database |
| | | |
+-------------+ +----------+
| Local cache |
| |
| user:1234 = |
| username |
| Alice |
+-------------+虽然用于本地缓存的应用程序内存可能不是很大，但与访问数据库等网络服务相比，访问本地计算机内存所需的时间要小几个数量级。由于经常访问相同比例的小部分数据，这种模式可以大大减少应用程序获取数据的延迟，同时减少数据库端的负载。
此外，有许多数据集的项目变化非常少。例如，社交网络中的大多数用户帖子要么是不可变的，要么很少被用户编辑。除此之外，通常一小部分帖子非常受欢迎，或者因为一小部分用户有很多关注者和/或因为最近的帖子有更多的可见度，很明显为什么这种模式可以很有用。
通常，客户端缓存的两个主要优点是：
数据以非常小的延迟可用。
数据库系统接收的查询更少，允许它以更少的节点为相同的数据集提供服务。
但是也会带来一个问题：
客户端可以缓存服务端返回的数据，业务可以直接快速读取本地缓存数据。既然客户端会缓存数据，那势必会存在多份数据，于是就会产生经典的问题：如何保证客户端和服务器数据的一致性？
2.2 客户端缓存的模式
开启命令
### 开启tracking功能 关闭off
127.0.0.1:6379> client tracking on普通模式
服务端保存客户端读取的所有key，一旦有key失效，服务端给客户端发送 invalidate消息，告知客户端key已失效，客户端就会删除对应的缓存。服务端也会把记录的key记录删除。
广播方式
服务器给客户端广播所有失效的key，这种方式存在的问题是：当多个客户端共用一个redis时，势必导致自己不关心key也会受到invalidate消息，造成了无效的网络开销和处理干扰。
处理方式：客户端可以注册需要跟踪的key，这样服务器只把客户端注册的key的invalidate消息通知给客户端
3、细粒度权限控制ACL
主要内容：
1、接入权限：用户名和密码
2、控制可以执行的命令
3、控制可以操作的key
启用和禁止用户：
on：启用用户：可以作为该用户进行身份验证。
off: 禁止该用户：无法再通过该用户进行身份验证；但是，以前经过身份验证的连接仍然有效。请注意，如果默认用户标记为off，则新连接将以未经过身份验证的方式启动，并且无论默认用户配置如何，都需要用户发送AUTH或HELLO使用 AUTH 选项以某种方式进行身份验证。
允许和禁止命令：
+：将命令添加到用户可以调用的命令列表中。可|用于允许子命令（例如“+config|get”）。
-：将命令删除到用户可以调用的命令列表中。从 Redis 7.0 开始，它可以|用于阻止子命令（例如“-config|set”）。
+@：添加该类别中的所有命令以供用户调用，有效类别为@admin，@set，@sortedset，...等，通过调用ACL CAT命令查看完整列表。特殊类别@all 表示所有命令，包括当前存在于服务器中的命令，以及将来通过模块加载的命令。
-@：喜欢+@但从客户端可以调用的命令列表中删除命令。
+|first-arg：允许其他禁用命令的特定第一个参数。它仅在没有子命令的命令上受支持，并且不允许像 -SELECT|1 这样的否定形式，只能以“+”开头的加法。此功能已弃用，将来可能会被删除。
allcommands: +@all 的别名。请注意，这意味着能够执行通过模块系统加载的所有未来命令。
nocommands: -@all 的别名。
允许和禁止某些密钥和密钥权限：
~：添加可以作为命令的一部分提及的键模式。例如~*允许所有键。该模式是一种全局样式的模式，如KEYS. 可以指定多个模式。
%R~：（Redis 7.0 及更高版本可用）添加指定的读取密钥模式。这与常规键模式的行为类似，但仅授予从与给定模式匹配的键中读取的权限。有关详细信息，请参阅密钥权限。
%W~：（Redis 7.0 及更高版本可用）添加指定的写入键模式。这与常规密钥模式的行为相似，但仅授予写入与给定模式匹配的密钥的权限。有关详细信息，请参阅密钥权限。
%RW~: （在 Redis 7.0 及更高版本中可用）~.
allkeys: 的别名~*。
resetkeys：刷新允许的键模式列表。例如 ACL ~foo:* ~bar:* resetkeys ~objects:*，将只允许客户端访问与模式匹配的键objects:*。
允许和禁止 Pub/Sub 频道：
&：（在 Redis 6.2 及更高版本中可用）添加用户可以访问的 Pub/Sub 通道的 glob 样式模式。可以指定多个通道模式。请注意，模式匹配仅适用于 和 提到的通道PUBLISH，SUBSCRIBE而PSUBSCRIBE需要在其通道模式和用户允许的模式之间进行字面匹配。
allchannels&*：允许用户访问所有 Pub/Sub 频道的别名。
resetchannels：刷新允许的频道模式列表并断开用户的 Pub/Sub 客户端，如果这些客户端不再能够访问其各自的频道和/或频道模式。
为用户配置有效密码：
>：将此密码添加到用户的有效密码列表中。例如>mypass将“mypass”添加到有效密码列表中。该指令清除nopass标志（见下文）。每个用户可以有任意数量的密码。
<：从有效密码列表中删除此密码。如果您尝试删除的密码实际上未设置，则会发出错误。
#：将此 SHA-256 哈希值添加到用户的有效密码列表中。此哈希值将与为 ACL 用户输入的密码的哈希值进行比较。这允许用户将哈希值存储在acl.conf文件中，而不是存储明文密码。仅接受 SHA-256 哈希值，因为密码哈希必须为 64 个字符并且仅包含小写十六进制字符。
!：从有效密码列表中删除此哈希值。当您不知道哈希值指定的密码但想从用户那里删除密码时，这很有用。
nopass：用户设置的所有密码都被删除，用户被标记为不需要密码：这意味着每个密码都对该用户有效。如果此指令用于默认用户，则每个新连接都将立即使用默认用户进行身份验证，而无需任何显式 AUTH 命令。请注意，resetpass指令将清除此情况。
resetpass：刷新允许的密码列表并删除nopass状态。在resetpass之后，用户没有关联的密码，并且如果不添加一些密码（或稍后将其设置为nopass）就无法进行身份验证。
注意：如果用户没有被标记为 nopass 并且没有有效密码列表，则该用户实际上是不可能使用的，因为将无法以该用户身份登录。
为用户配置选择器：
()：（在 Redis 7.0 及更高版本中可用）创建一个新的选择器来匹配规则。选择器在用户权限之后进行评估，并根据它们定义的顺序进行评估。如果命令匹配用户权限或任何选择器，则允许。有关更多信息，请参阅选择器。
clearselectors：（在 Redis 7.0 及更高版本中可用）删除所有附加到用户的选择器。
重置用户：
reset执行以下操作：resetpass、resetkeys、resetchannels、off、-@all。用户在创建后立即返回到相同的状态。 4、使用RESP3协议
RESP 2：客户端和服务器端的通信内容是以字节数组形式进行编码，客户端需要根据操作的命令或是数据类型自行对传输的数据进行解码，增加了客户端开发复杂度。
RESP 3 直接支持多种数据类型的区分编码(直接通过不同的开头字符，区分不同的数据类型)，包括空值、浮点数、布尔值、有序的字典集合、无序的集合等。客户端可以通过判断传递消息的开头字符，来实现数据转换，大大提升效率。
客户端缓存中使用 Redis 6 支持的新版本 Redis 协议 RESP3，可以在同一连接中运行数据查询和接收失效消息。
5、SSL模块
通过增加设置，在传输的时候使用SSL协议，确保传输过程的安全性
当SSL模块开启的时候，不能使用多线程
PS: Redis文档连接：https://redis.io/docs/