一、redis 6 新特性¶

1、多线程IO

2、重新设计了客户端缓存功能

3、RESP3协议

4、支持SSL

5、ACL权限控制

6、提升了RDB日志加载速度

7、发布官方的Redis集群代理模块 Redis Cluster proxy。

8、提供了众多的新模块（modules）API

视频补充：其中几个新特性的理解

RESP3 是 Redis 在 RESP2 之后的新协议版本，能够更好地表达复杂返回类型。
Redis Cluster proxy 可以理解为官方提供的集群代理层，客户端通过代理访问集群时，不需要感知具体节点数量、主从角色和转发细节。
客户端缓存功能的重新设计，本质上是为了降低重复读取压力，进一步提升热点数据场景下的访问效率。

1.1 线程模型¶

redis的IO模型 Redis将一次命令执行拆分为三个阶段：

read I/O 从网络缓冲区读取命令
命令执行
write I/O 将执行结果写入到网络缓冲区

为什么要引入多线程模型？

随着硬件性能提升，Redis 的性能瓶颈可能出现网络 IO 的读写。
读写网络的 read/write 系统调用占用了Redis 执行期间大部分CPU 时间；
Redis 采用多个 IO 线程来处理网络请求，提高网络请求处理的并行度。

视频补充：Redis 6 多线程模型的关键边界

多线程主要用于 read I/O、write I/O 和协议解析，命令执行本身仍然由主线程串行完成。
这样设计的目的是把耗时的网络读写从主线程中剥离出去，但避免多线程同时执行命令带来的锁竞争和实现复杂度。
可以把一次请求理解为三个阶段：主线程接收事件 -> I/O 线程处理读写 -> 主线程执行命令并回写结果。
因此 Redis 6 以后不再是“纯单线程”，但核心的数据读写命令语义仍然是单线程串行执行。

如何开启？

Redis 6.0 的多线程默认是禁用的，只使用主线程。如需开启需要修改 redis.conf 配置文件： io-threads-do-reads yes

io-threads 4

建议：4 核的机器建议设置为 2 或 3 个线程，8核的建议设置为 6 个线程，线程数一定要小于机器核数。超过8个无意义

I/O 线程数并不是越多越好，通常只需要小于 CPU 核数即可，线程过多反而会带来调度开销。

二、redis 7 新特性¶

新增Function自定义函数库，函数库支持持久化与可复制。
Lua脚本（脚本本身代码）不再支持持久化和复制，仅对命令执行结果进行持久化和复制。
ACL v2 支持。
支持Multi-Part AOF。
支持Client-Eviction。
支持Sharded-Pub/Sub。
支持命令执行耗时直方图。
支持子命令级别的性能统计。
Ziplist编码替换为Listpack编码。
支持Global Replication Buffer。

2.1 Redis Functions¶

Functions 被设计为redis DB的一部门，可以通过持久化和主从复制保证可用用，不用依赖于客户端。

服务端维护functions脚本（只要更新了，客户就一致了，业务的一致性得到保证）
服务端持久化functions脚本（脚本不会丢失，事务的失败率降低）会通过主从同步到从库
functions内可以调用其他functions

2.2 ACL v2支持¶

Redis 7.0 中， ACL v2 正式支持粒度至 KEY 的权限访问控制，可以轻松实现账户对不同 KEY 有不同的权限访问控制。

2.3 多AOF支持（Multi-Part AOF）¶

redis 7.0中将原来的单个AOF文件拆分成多个AOF文件。在Multi-Part AOF 中，将AOF分为三种类型：

BASE: 表示基础AOF，它一般由子进程通过重写产生，该文件最多只有一个。
INCR: 表示增量AOF, 它一般会在重写开始执行时被创建，该文件可能存在多个。
HISTORY：表示历史AOF，它由BASE和INCR变化而来，每次重写完成时，本次重写之前的BASE和 INCR都将变为HISTORY ，该类型的AOF会被redis自动删除

appenddirname "appendonlydir"
aof-timestamp-enabled
appendonly.aof.1.base.rdb
appendonly.aof.1.incr.aof
appendonly.aof.2.incr.aof
appendonly.aof.manifest

2.4 Client-Eviction（客户端回收）¶

Redis 内存占用主要分为三个部分：

data 是用户数据的内存占用；
metadata 是元数据的内存占用；
client buffer 是连接内存占用

在 redis 7.0 中，可以通过 maxmemory-clients 对客户端连接占用的总内存进行控制。如果连接内存超过配置上限，会优先回收内存占用较大的连接，从而在一定程度上实现连接内存与数据内存的隔离。

视频补充：Client-Eviction 的价值

早期更容易把注意力放在 data 上，但在连接数很多、输出缓冲区很大的场景下，client buffer 也可能成为显著的内存消耗来源。
Client-Eviction 的重点不是淘汰业务数据，而是优先治理“占内存很多的客户端连接”，避免连接内存把实例整体内存挤爆。

Redis 6 与 Redis 7 新特性速览