Redis版本发行计划
2021-02-25 10:03:35 
阿炯
本文是从Redis的产品主页分离出来的，专门用于该发行版本的更新记录，截止到2030年之前。
最新版本：3.2
该版本改进包括：
* 修复了无磁盘的复制问题(Oran Agra)
* 在角色变化后对 BLPOP 复制进行测试(Salvatore Sanfilippo)
* prepareClientToWrite() 错误处理方法的改进(Salvatore Sanfilippo)
* 移除 dict.c 中不再使用的函数(Salvatore Sanfilippo
3.0 版本与 2.8 版本比较，主要新特性包括如下几个方面：
* Redis Cluster —— 一个分布式的 Redis 实现
* 全新的 "embedded string" 对象编码结果，更少的缓存丢失，在特定的工作负载下速度的大幅提升
* AOF child -> parent 最终数据传输最小化延迟，通过在 AOF 重写过程中的 "last write"
* 大幅提升 LRU 近似算法用于键的擦除
* WAIT 命令堵塞等待写操作传输到指定数量的从节点
* MIGRATE 连接缓存，大幅提升键移植的速度
* MIGARTE 新的参数 COPY 和 REPLACE
* CLIENT PAUSE 命令：在指定时间内停止处理客户端请求
* BITCOUNT 性能提升
* CONFIG SET 接受不同单位的内存值，例如 "CONFIG SET maxmemory 1gb".
* Redis 日志格式小调整用于反应实例的角色 (master/slave)
* INCR 性能提升
3.2版本中增加的最大功能就是对GEO(地理位置)的支持，说起redis的GEO特性，最大的贡献还是中国人。redis作者在对3.2引进新特性的博客中介绍了为什么支持GEO。GEO hashing的api是在Ardb实现的，Ardb是github用户yinqiwen实现的基于redis协议实现的nosql系统，Ardb支持除了redis、还有LevelDB、RocksDB 、LMDB等kv引擎。其中Ardb实现了GEO hashing功能。从Ardb作者的用户名和标识的位置在深圳可以看出Ardb作者应该是中国人，Ardb是用C++写的。redis另一个开发者Matt Stancliff从Ardb提取GEO库，用C语言改写，整合进redis的一个自己的分支，并被redis作者接受，合并进了3.2版本。GEO目前提供以下6个命令。
1、geoadd：增加某个地理位置的坐标。
2、geopos：获取某个地理位置的坐标。
3、geodist：获取两个地理位置的距离。
4、georadius：根据给定地理位置坐标获取指定范围内的地理位置集合。
5、georadiusbymember：根据给定地理位置获取指定范围内的地理位置集合。
6、geohash：获取某个地理位置的geohash值。
地理位置的坐标是以WGS84为标准，WGS84，全称World Geodetic System 1984，是为GPS全球定位系统使用而建立的坐标系统。
-------------------------------
GEO命令
下面来看看具体每个命令的用法。
geoadd
geoadd用来增加地理位置的坐标，可以批量添加地理位置，命令格式为：
GEOADD key longitude latitude member [longitude latitude member ...]
key标识一个地理位置的集合。longitude latitude member标识了一个地理位置的坐标。longitude是地理位置的经度，latitude是地理位置的纬度。member是该地理位置的名称。GEOADD可以批量给集合添加一批地理位置。
geopos
geopos可以获取地理位置的坐标，可以批量获取多个地理位置的坐标，命令格式为：
GEOPOS key member [member ...]
geodist
geodist用来获取两个地理位置的距离，命令格式为：
GEODIST key member1 member2 [m|km|ft|mi]
单位可以指定为以下四种类型：
m：米，距离单位默认为米，不传递该参数则单位为米。
km：公里。
mi：英里。
ft：英尺。
georadius
georadius可以根据给定地理位置坐标获取指定范围内的地理位置集合，命令格式为：
GEORADIUS key longitude latitude radius [m|km|ft|mi] [WITHCOORD] [WITHDIST] [ASC|DESC] [WITHHASH] [COUNT count]
longitude latitude标识了地理位置的坐标，radius表示范围距离，距离单位可以为m|km|ft|mi，还有一些可选参数：
WITHCOORD：传入WITHCOORD参数，则返回结果会带上匹配位置的经纬度。
WITHDIST：传入WITHDIST参数，则返回结果会带上匹配位置与给定地理位置的距离。
ASC|DESC：默认结果是未排序的，传入ASC为从近到远排序，传入DESC为从远到近排序。
WITHHASH：传入WITHHASH参数，则返回结果会带上匹配位置的hash值。
COUNT count：传入COUNT参数，可以返回指定数量的结果。
georadiusbymember
georadiusbymember可以根据给定地理位置获取指定范围内的地理位置集合。georadius命令传递的是坐标，georadiusbymember传递的是地理位置。georadius更为灵活，可以获取任何坐标点范围内的地理位置。但是大多数时候，只是想获取某个地理位置附近的其他地理位置，使用georadiusbymember则更为方便。georadiusbymember命令格式为(命令可选参数与georadius含义一样)：
GEORADIUSBYMEMBER key member radius [m|km|ft|mi] [WITHCOORD] [WITHDIST] [ASC|DESC] [WITHHASH] [COUNT count]
geohash
geohash可以获取某个地理位置的geohash值。geohash是将二维的经纬度转换成字符串hash值的算法，后面会具体介绍geohash原理。可以批量获取多个地理位置的geohash值。命令格式为：
GEOHASH key member [member ...]
-------------------------------
Redis GEO实现
GEO实现主要包含了以下两项技术：
1.使用geohash保存地理位置的坐标。
2.使用有序集合(zset)保存地理位置的集合。
geohash
geohash的思想是将二维的经纬度转换成一维的字符串，geohash有以下三个特点：
1.字符串越长，表示的范围越精确。编码长度为8时，精度在19米左右，而当编码长度为9时，精度在2米左右。
2.字符串相似的表示距离相近，利用字符串的前缀匹配，可以查询附近的地理位置。这样就实现了快速查询某个坐标附近的地理位置。
3.geohash计算的字符串，可以反向解码出原来的经纬度。
这三个特性让geohash特别适合表示二维hash值。这篇文章：GeoHash核心原理解析详细的介绍了geohash的原理，想要了解geohash实现的朋友可以参考这篇文章。
GEO命令实现
知道了redis使用有序集合(zset)保存地理位置数据(想了解redis有序集合的，可以参看这篇文章《有序集合对象》)，以及geohash的特性，就很容易理解redis是如何实现redis GEO命令了。细心的读者可能发现，redis没有实现地理位置的删除命令。不过由于GEO数据保存在zset中，可以用zrem来删除某个地理位置。
geoadd命令增加地理位置的时候，会先计算地理位置坐标的geohash值，然后地理位置作为有序集合的member，geohash作为该member的score。然后使用zadd命令插入到有序集合。
geopos命令则先根据地理位置获取geohash值，然后decode得到地理位置的坐标。
geodist命令先根据两个地理位置各自得到坐标，然后计算两个坐标的距离。
georadius和georadiusbymember使用相同的实现，georadiusbymember多了一步把地理位置转换成对应的坐标。然后查找该坐标和周围对应8个坐标符合距离要求的地理位置。因为geohash得到的值其实是个格子，并不是点，这样通过计算周围对应8个坐标就能解决边缘问题。由于使用有序集合保存地理位置，在对地列位置基于范围查询，就相当于实现了zrange命令，内部的实现确实与zrange命令一致，只是geo有些特别的处理，比如获得的某个地理位置，还需要计算该地理位置是否符合给定的距离访问。
geohash则直接返回了地理位置的geohash值。
redis关于geohash使用了Ardb的geohash库geohash-int，redis使用的geohash编码长度为26位。可以精确到0.59m的精度。
通过开GEO的相关信息，可以看出redis借助了有序集合(zset)和geohash，加上redis本身实现的命令框架，可以很容易的实现地理位置相关的命令。
最新版本：4.0
Redis v4.0.0 正式发布，这是 Redis v4.0 系列的首个稳定版，包含以下的一些重大改进：模块化的系统、更好的复制 (PSYNC2)、对 eviction policies, threaded DEL/FLUSH 的改进、混合 RDB+AOF 格式、对 Raspberry Pi 的支持作为主要平台、新的 MEMORY 命令行、Redis Cluster 对 Nat/Docker 的支持、更快的 Redis Cluster 键创建，以及许多其他较小的功能和一些行为修复等。与之前的 RC 相比，有一些错误修复和改进，主要是：
针对新的复制引擎 PSYNC2 的修复
引入了模块线程安全上下文(Modules thread safe contexts)，现在还是一个实验性的 API，但是当需要时，该 API 被认为是稳定和可用的
SLOWLOG 现在会记录 offending 的客户端名字和地址。要注意的是，这是对于向后兼容性的破坏，以防旧代码会判断 slowlog 条目由三个条目组成。
模块原生数据类型 RDB 格式已更改
AOF 检查程序现在可以处理 RDB preambles
添加了不支持 STORE 选项的 GEORADIUS_RO 和 GEORADIUSBYMEMBER_RO 变体，为了允许这种查询的只读扩容
HSET 现在是可变的，HMSET 被认为是弃用的(但将来会支持)。新的代码中请使用 HSET
添加 DEBUG DIGEST 模块 API
HyperLogLog 命令不再在某些输入的字符串中(非 HLL)崩溃
修复在 MULTI/EXEC blocks 中的 SLAVEOF
修复了重要的安全问题、SCAN 命令系列错误、PSYNC2 边界案件到期。与 Sentinel 相关的修复。
其他许多小的 bug 修复和改进
更多详情请参阅发行说明。
最新版本：5.0
1. 新的流数据类型(Stream data type)
2. 新的 Redis 模块 API：定时器、集群和字典 API(Timers, Cluster and Dictionary APIs)
3. RDB 现在可存储 LFU 和 LRU 信息
4. redis-cli 中的集群管理器从 Ruby (redis-trib.rb) 移植到了 C 语言代码。执行 `redis-cli --cluster help` 命令以了解更多信息
5. 新的有序集合(sorted set)命令：ZPOPMIN/MAX 和阻塞变体(blocking variants)
6. 升级 Active defragmentation 至 v2 版本
7. 增强 HyperLogLog 的实现
8. 更好的内存统计报告
9. 许多包含子命令的命令现在都有一个 HELP 子命令
10. 客户端频繁连接和断开连接时，性能表现更好
11. 许多错误修复和其他方面的改进
12. 升级 Jemalloc 至 5.1 版本
13. 引入 CLIENT UNBLOCK 和 CLIENT ID
14. 新增 LOLWUT 命令
15. 在不存在需要保持向后兼容性的地方，弃用 "slave" 术语
16. 网络层中的差异优化
17. Lua 相关的改进：
- 将 Lua 脚本更好地传播到 replicas / AOF
- Lua 脚本现在可以超时并在副本中进入 -BUSY 状态
18. 引入动态的 HZ(Dynamic HZ) 以平衡空闲 CPU 使用率和响应性
19. 对 Redis 核心代码进行了重构并在许多方面进行了改进
Redis 5 是 Redis 引入流数据类型(Stream data type)的第一个版本。按照官方的说法，不使用该特性的用户在生产环境中使用 Redis 5 会有更好的体验 -- 虽然开发团队尚未发现关于这项特性的关键错误。此外，因为许多内部结构与 Redis 4 共享，因此在内部工作方式方面，变化不会很大。修复了两个关于 Streams 消费者的问题 -- 可以在访问历史记录时由 XREADGROUP 复制项目的组，以及 XREADGROUP 可以报告某些历史记录的另一个错误，即使待添加的消费者列表为空。目前已解决了这两个问题，并进行了单元测试以避免出现回归错误。此外，该版本还修复了集群模式下 redis-cli 的一些问题。最后关于 FreeBSD 和 DragonFly 的一些构建问题现在也已经解决。详细更新内容请查看发行说明。
2021年2月下旬，Redis 同时发布了 5.0.11、6.0.11 和 6.2 版本。对于使用 32 位 Redis 的用户来说，此次更新解决了一个重要的安全问题，即 32 位系统上的整数溢出(CVE-2021-21309：Redis 4.0 或更新版本对批量输入的最大值使用了一个可配置的限制。默认情况下，它是 512MB，对所有平台来说都是一个安全值。如果大幅增加限制，从客户端接收到一个大的请求可能会触发整数溢出的情况，这将导致缓冲区溢出和堆损坏。主要更新内容如下：
5.0.11
修复分叉进程删除父进程 pid 文件的问题
修复 flock 群集配置可能导致 kill -9 后重启失败的问题
避免在 redis-sentinel 中读取越界
最新版本：6.0
Redis v6.0.6 已发布，此版本修复了一些 bug，其中主要内容包括：
修复启用带前缀的 CLIENT TRACKING 时崩溃的问题
EXEC 始终会因 EXECABORT 而失败，并且已清除多状态
RESTORE ABSTTL 不会将过期的密钥存储到数据库中
redis-cli 能够更好地处理非优先键名
TLS：关闭 tls-auth-clients 时忽略客户端证书
Tracking：修复刷新时的无效消息
在 Sentinel 启动时通知 systemd
修复因滥用 STRALGO 而导致的崩溃
module API 中的一些修复
修复一些罕见的泄漏(STRALGO 错误滥用，Sentinel)
修复了脚本碎片整理中可能的无效访问
一些新的特性
LPOS 命令，用于在列表中搜索
在集群模式下的 redis-cli 和 redis-benchmark 中使用 user+pass 进行迁移
redis-cli 支持 --pipe、-rdb 和 --replica 选项的 TLS
TLS：支持会话缓存配置
更多更新说明请查看这里。
常说 Redis 是单线程模型，是指 Redis 采用单线程的事件驱动模型，只有并且只会在一个主线程中执行 Redis 命令操作，这意味着它在处理请求时不使用复杂的上下文切换或锁机制。尽管只是单线程的架构，但 Redis 通过非阻塞的 I/O 操作和高效的事件循环来处理大量的并发连接，性能仍然非常高。然而在 Redis4.0 开始也引入了一些后台线程执行异步淘汰、异步删除过期 key、异步执行大 key 删除等任务，然后，在 Redis6.0 中引入了多线程 IO 特性，将 Redis 单节点访问请求从 10W 提升到 20W。
而在 Valkey 社区首个发布的 Valkey v8.0 版本，在 I/O 线程系统上进行了重大升级，特别是异步 I/O 线程的引入，使主线程和 I/O 线程能够并行工作，可实现最大化服务吞吐量并减少瓶颈，使得 Valkey 单节点访问请求可以提升到 100W。那么在 Redis6.0 和 Valkey8.0 中多线程 IO 是怎么回事呢，是否改变了 Redis 原有单线程模型？
1.2024 年，Redis 商业支持公司 Redis Labs 宣布 Redis 核心代码的许可证从 BSD 变更为 RSALv2，明确禁止云厂商提供 Redis 托管服务，这一决定直接导致社区分裂。
2.为维护开源自由，Linux 基金会联合多家科技公司（包括 AWS、Google、Cloud、Oracle 等）宣布支持 Valkey，作为 Redis 的替代分支。
3.新近在 Redis 项目创始人 antirez 今年加入 Redis 商业公司 5 个月后，Redis 宣传从 Redis8 开始，Redis 项目重新开源。
本节主要介绍 Redis v6.0 多线程 IO 特性。
多线程 IO 概述
Redis v6.0 引入多线程 IO，但多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。默认是不开启的，需要进程启动前开启配置，并且在运行期间无法通过 config set 命令动态修改。
参数与配置
多线程 IO 涉及下面两个配置参数：
# io-threads 4 IO 线程数量
# io-threads-do-reads no 读数据及数据解析是否也用 IO 线程
1.io-threads 表示 IO 线程数量， io-threads 设置为 1 时（代码中默认值），表示只使用主线程，不开启多线程 IO。因此，若要配置开启多线程 IO，需要设置 io-threads 大于 1，但不可以超过最大值 128。
2.但在默认情况下，Redis 只将多线程 IO 用于向客户端写数据，因为作者认为通常使用多线程执行读数据的操作帮助不是很大。如果需要使用多线程用于读数据和解析数据，则需要将参数 io-threads-do-reads 设置为 yes 。
3.此两项配置参数在 Redis 运行期间无法通过 config set 命令修改，并且开启 SSL 时，不支持多线程 IO 特性。
4.若机器 CPU 将至少超过 4 核时，则建议开启，并且至少保留一个备用 CPU 核，使用超过 8 个线程可能并不会有多少帮助。
执行流程概述
Redis v6.0 引入多线程 IO 后，读写数据执行流程如下所示：
流程简述
主线程负责接收建立连接请求，获取 socket 放入全局等待读处理队列。
主线程处理完读事件之后，通过 RR（Round Robin）将这些连接分配给这些 IO 线程，也会分配给主线程自己。
主线程先读取分配给自己的客户端数据，然后阻塞等待其他 IO 线程读取 socket 完毕。
IO 线程将请求数据读取并解析完成（这里只是读数据和解析、并不执行）。
主线程通过单线程的方式执行请求命令。
主线程通过 RR（Round Robin）将回写客户端事件分配给这些 IO 线程，也会分配给主线程自己。
主线程同样执行部分写数据到客户端，然后阻塞等待 IO 线程将数据回写 socket 完毕。
设计特点
1.IO 线程要么同时在读 socket，要么同时在写，不会同时读和写。
2.IO 线程只负责读写 socket 解析命令，不负责命令执行。
3.主线程也会参与数据的读写。
使用 redis-benchmark 做 Redis6 单线程和多线程简单 SET/GET 命令性能测试：
1.GET/SET 命令在设置 4 个 IO 线程时，QPS 相比于大部分情况下的单线程，性能几乎是翻倍了。
2.连接数越多，多线程优势越明显；value 值越小，多线程优势越明显。
3.使用多线程读命令比写命令优势更加明显，当 value 越大，写命令越发没有明显的优势。
4.参数 io-threads-do-reads 为 yes，性能有微弱的优势，不是很明显。
总体来说，以上结果基本符合预期，结果仅作参考。尽管引入多线程 IO 大幅提升了 Redis 性能，但是 Redis v6.0 的多线程 IO 仍然存在一些不足：
1.CPU 核心利用率不足：当前主线程仍负责大部分的 IO 相关任务，并且当主线程处理客户端的命令时，IO 线程会空闲相当长的时间，同时值得注意的是，主线程在执行 IO 相关任务期间，性能受到最慢 IO 线程速度的限制。
2.IO 线程执行的任务有限：目前，由于主线程同步等待 IO 线程，线程仅执行读取解析和写入操作。如果线程可以异步工作，我们可以将更多工作卸载到 IO 线程上，从而减少主线程的负载。
3.不支持带有 TLS 的 IO 线程。
最新的 Valkey v8.0 版本中，通过引入异步 IO 线程，将更多的工作转移到 IO 线程执行，同时通过批量预读取内存数据减少内存访问延迟，大幅提高 Valkey 单节点访问 QPS，单个实例每秒可处理 100 万个请求。后续再详细介绍 Valkey8.0 异步 IO 特性。
Redis v6.0 引入多线程 IO，但多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。通过开启多线程 IO，并设置合适的 CPU 数量，可以提升访问请求一倍以上。多线程 IO 仍然存在一些不足，没有充分利用 CPU 核心，在最新的 Valkey v8.0 版本中，引入异步 IO 将进一步大幅提升 Valkey 性能。
2020年9月，v6.0.7 发布，修复了一些中等程度的 bug 并添加了新特性。更新内容如下：
在 RDB/ROF 加载期间到达时，CONFIG SET 可能会挂起客户端(当处理完另一条同样以 -LOADING error 被拒绝的命令后)。
stream 类型密钥的 UNLINK/Lazyfree 永远不会进行异步释放。
PERSIST 应该使 WATCH 无效(就像 EXPIRE 一样)
只有 read 命令的 EXEC 可能在 OOM 时被拒绝。
TLS：放宽对 CONFIG SET 的验证(如果设置了某些配置并且未启用 tls，则不会出错)
TLS：支持 cluster/replication，无需 tls-port
网络联机后系统启动
Redis 基准改进及各种小错误修复
添加 oom-score-adj 配置选项以控制 Linux OOM killer
在 INFO 输出中显示 IO 线程统计信息和状态
添加可选的 tls 验证模式
Module API
添加 RedisModule_HoldString 与 loaded keyspace event
修复 RedisModuleEvent_LoadingProgress
修复 successful psync 时 RedisModuleEvent_MasterLinkChange hook missing 的问题
修复丢失的 RM_CLIENTINFO_FLAG_SSL
重构 redismodule.h 以与 -fno-common/extern 一起使用
官方表示，除非有意外情况，否则此版本应当是最后的一个 6.0.x 系列版本，Redis 团队更专注于 Redis 6.2 的开发。通过 CONFIG SET 设置 oom-score-adj-value 或从配置文件加载 oom-score-adj-value 后，CONFIG REWRITE 将生成损坏的配置文件，这会导致 Redis 无法启动
修复 MacOS 上的 redis-cli --pipe 问题；修复 HKEYS/HVALS 在不存在的密钥上的 RESP3 响应
各种小的 bug 修复以及如下的新特性
设为 madvise 时，删除 THP 警告；允许 EXEC 在集群中的只读副本上使用读取命令；将主/副本选项添加到 redis-cli --cluster 调用命令
更多详情见发行公告。
最新版本：6.2
Redis 6.2.2 现已于2021年4月发布，该版本升级迫切性程度为高，尤其对于那些使用 ACL 和 pub/sub，CONFIG REWRITE，或遭受性能下降影响的用户来说，详见下文：
修复了 Redis 6.2 之前版本中的回归问题：
修复 BGSAVE、AOFRW 和复制速度因 child reporting CoW 而变慢的问题
修复定时器事件即将触发时的 short busy loop
修复 default user、overwritten 和 reset users 失去 Pub/Sub 频道权限的问题
修复在没有 IPv6 的情况下无法启动 alpine/libmusl 的问题
修复模块中 propagation 和 MULTI/EXEC 的问题
......
只适用于 Redis 6.2 以前版本的错误修复：
ACL Pub/Sub 通道 save/load 方案的权限处理
允许在 busy scripts 中使用 RESET 命令
修复一些未计入统计信息的错误回复
Bug 修复：
为卡在 fullsync 中的副本添加超时机制
即使默认用户没有权限，也可以处理 HELLO 命令
修复 list-compress-depth 可能会压缩比所需数量更多的节点
修复 redis-cli 对 rediss://URL 方案的处理
Cluster：跳过不必要的检查，这可能会阻止故障检测
Sentinel：在 sentinel 获得第一个响应之前修复信息刷新时间字段
Systemd：当副本准备好接受连接时发送准备就绪通知
Command behavior changes：
ZADD：修复当 INCR 与 GT/LT 一起使用时阻止更新的错误 reply
XAUTOCLAIM：修复响应，返回下一个可用的 id 作为光标
XAUTOCLAIM：修复 JUSTID 以防止 incrementing delivery_count
New config options：
添加 cluster-allow-replica-migration 配置选项
添加 replica-announced 配置选项
在 TLS 群集中添加对纯文本客户端的支持
添加对读取加密密钥文件的支持
Improvements：
修复 BRPOP 在 Redis 6.0 上的性能回归
避免为含有敏感数据的配置置添加 slowlog entries
改进 redis-cli 非二进制安全字符串的处理方式
优化 CLUSTER SLOTS reply
处理 remaining fsync 错误
Info fields 和 introspection changes：
从 current_fork_perc 信息字段中删除 ％ 符号
修复 FreeBSD 上的 RSS 内存信息
修复'INFO CLIENTS'中当所有客户端都掉线时的 client_recent_max_input/output_buffer
修复信息复制中无效的 master_link_down_since_seconds
与平台和部署相关的更改：修复 FreeBSD <12.x 版本
Modules：
为 RedisModule_log logging levels 添加宏
添加 RedisModule_GetAbsExpire/RedisModule_SetAbsExpire
为 key space notification 添加一个模块类型
仅在 masters 中设置 module eviction context 标志
修复无法使用的 RedisModule_IsAOFClient API
修复 EVAL 执行失败后 modules propagatio 中 EXEC 缺失的问题
更多详情可查看更新说明。
6.0.11
修复对线程 IO 和客户端暂停故障转移的处理可能导致数据丢失或崩溃的问题
修复从大型哈希表中选择随机元素的问题
修复客户端跟踪 tracking-redir-broken 消息中损坏的协议
XINFO 能够访问副本上的过期密钥
修复与 -a或 --dbnum 一起使用时 redis-benchmark 中损坏的协议
避免测试 arm64 CoW 错误时的断言在较早的内核上
CONFIG REWRITE 应该接受 umask 设置
修复 COMMAND 命令中 firstkey、lastkey、step 的某些命令
6.2
修复客户端跟踪tracking-redir-broken消息中损坏的协议
避免在 INFO 命令状态、错误状态、模块中使用不安全的字段名称字符
XINFO 可以在 CLIENT PAUSE WRITE 期间访问过期的密钥
修复 REPLCONF ip 地址的允许长度
当切换到新的列表包时，XADD 会计算已删除的记录
v6.2.3 已于2021年5月发布，此版本主要包含对影响认证客户端连接的安全问题的修复。
STRALGO LCS 命令中的整数溢出(CVE-2021-29477)：Redis 6.0 版或更新的版本中存在一个整数溢出漏洞，可利用 STRALGO LCS 命令破坏堆并可能导致远程代码执行。从 6.0 开始，所有版本的 Redis 都存在整数溢出漏洞。
在 large intsets 的 COPY 命令中出现整数溢出(CVE-2021-29478)：Redis 6.2 中的一个整数溢出漏洞可被利用来破坏堆并可能导致远程代码执行。该漏洞涉及改变默认的 set-max-intset-entries 配置值，创建一个由整数值组成的大型集合键，并使用 COPY 命令来复制它。整数溢出漏洞存在于从 2.6 开始的所有版本的 Redis 中，它可能导致损坏的 RDB 或 DUMP 有效载荷，但不能通过 COPY(6.2 之前不存在)进行利用。适用于 Redis 6.2 以前版本的错误修复：
修复 moduleDefragGlobals 中的内存泄漏
修复执行 lazy freeing 客户端跟踪表时的内存泄漏
阻止滥用副本发送可能断言和使 Redis 崩溃的命令
使用 monotonic clock 检查 Lua 脚本超时
redis-cli：在 cluster 模式下重定向时，不要使用 unix socket
详细内容请查看 Redis 仓库更新。
最新版本：7.0
Redis 7.0 现已于2022年4有下旬正式发布，该版本已经开发了将近一年，之前经历了三个候选版本。现如今，开发团队认为它已经足够稳定，可以应用于生产。7.0 几乎包括了对各个方面的增量改进。其中最值得注意的是 Redis Functions、ACLv2、command introspection 和 Sharded Pub/Sub，它们代表了基于用户反馈和生产经验教训的现有功能的重大演变。添加了近 50 个新命令和选项来支持这种演变并扩展 Redis 的现有功能。例如，位图、列表、集合、排序集合和流数据类型都添加了支持其数据管理用例的功能。此外，缓存语义已扩展为支持 existential 和 comparative modifiers。
公告指出，“虽然面向用户的功能很容易夸大，但这个版本中真正的 unsung heroes 其实是努力使 Redis 更高效、更稳定和更精简”。开发人员的大部分精力都投入到了通过关注 Redis 相对于它使用的资源的性能来提高 Redis 的操作效率。对其管理的几乎每个子系统都进行了多项改进，包括内存、计算、网络和存储。虽然有些优化是默认启用的，但其他优化可能需要配置。有关详细信息，可参阅 redis.conf 文件中的内联文档。
同时Redis 7.2 的开发工作也已经在进行当中了，更多详情可查看发行说明。
7.0.12 现已于2023年7月上旬发布，此版本包含了一些安全问题修复。具体更新内容如下：
修复(CVE-2022-24834) 在 Redis 中执行的特制 Lua 脚本可能会触发 cjson 和 cmsgpack 库中的堆溢出，并导致堆损坏和潜在的远程代码执行。从 2.6 开始，所有支持 Lua 脚本的 Redis 版本都存在该问题，并且仅影响经过认证和授权的用户。
修复(CVE-2023-36824) 在某些情况下，从命令和参数列表中提取键名称可能会触发堆溢出，并导致读取随机堆内存、堆损坏和潜在的远程代码执行。特别是：使用 COMMAND GETKEYS* 并验证 ACL 规则中的键名称。
当存在分叉子项时重新启用 downscale rehashing。
修复与 <count> 一起使用时 HRANDFIELD、SRANDMEMBER、ZRANDMEMBER 中可能出现的挂起问题。
改善 RANDOMKEY、HRANDFIELD、SRANDMEMBER、ZRANDMEMBER、SPOP 和 eviction 中的公平性问题。
修复 WAIT 在被阻止的模块命令被解锁后生效的问题。
在极少数情况下，避免 master 重新启动后不必要的完全同步。
更多情况请详见更新说明。
7.2.0 现已于2023年8月中旬发布，这是首个 Unified Redis Release。包含一系列广泛的新功能，以及对人工智能计划功能支持的重大投资。公告称，这是 “影响最深远的版本。在每一项增强功能中，你都能感受到一个强烈的主题：让开发人员更轻松地使用 Redis，使其运行得更快，并更轻松地实现创新成果。我们承诺通过所有分发渠道一次性交付所有这些功能，称之为 Unified Redis Release。”
让 AI 创新更容易实现
Redis 通过多种旨在提高效率、降低成本以及增强可扩展性和性能的策略来支持其数据库服务中的生成式 AI 工作负载。Redis 的矢量数据库支持两种矢量索引类型：FLAT（brute force search）和 HNSW（approximate search），以及三种流行的距离度量：余弦、内积和欧几里得距离。其他功能包括范围查询、混合搜索（组合过滤器和语义搜索）、JSON 对象支持等。其通过以下方式帮助构建和部署 LLM 支持的应用程序：
1.检索增强生成 (RAG)：在 RAG 框架内，使用预先训练的 LLM 和客户自己的数据生成响应。许多组织希望利用生成式人工智能的力量，而不需要构建自己的模型或对现有模型进行微调。此外，他们对于是否与商业 LLM 分享其专有数据犹豫不决。这就是 Redis Enterprise 的用武之地。作为矢量数据库，它提供强大的混合语义搜索功能来精确定位相关数据。此外，它还可以部署为外部特定领域的知识库。这可确保通用 LLM 获得最相关和最新的背景信息，从而提高结果质量并减少幻觉。
2.LLM 语义缓存： Redis Enterprise 通常用作可扩展缓存来存储先前回答的用户查询和结果。Redis 还使用语义缓存来识别和检索在语义上与输入查询足够相似的缓存响应，从而显着提高缓存命中率。这显着减少了发送到 LLM 服务的请求和令牌的数量，从而通过减少生成响应的时间来降低成本并提高性能。
3.推荐系统：LLM 可以作为复杂的电子商务虚拟购物助理的支柱。Redis Enteprise 的上下文理解和语义搜索使应用程序能够理解客户查询、提供个性化产品推荐，甚至模拟对话交互 —— 所有这些都是实时的。
4.文档搜索：在需要组织分析大量文档的情况下，LLM 支持的应用程序可以作为文档发现和检索的强大工具。Redis Enterprise 的混合语义搜索功能使得查明相关信息并从这些文档生成新内容成为可能。
在过去的 12 个月时间里，Redis 已与最流行的应用程序开发框架集成，以创建由 LLM 驱动的聊天机器人、代理和链。其中包括 LlamaIndex、Langchain、RelevanceAI、DocArray、MantiumAI 和 ChatGPT 检索插件。此外，还与 NVIDIA 就一些领先的 AI 项目进行了密切合作：NVIDIA 的 AI Workflows（Merlin 和 Morpheus）、Tools（Triton 和 RAPIDS），以及 NVIDIA 为提供更高的每秒查询次数（QPS）而提供的最先进索引技术 RAPIDS RAFT。在 Redis Enterprise 7.2 中推出了可扩展搜索功能的预览版。它允许运行高 QPS、低延迟的工作负载，并跨集群实现最佳分布式处理。与之前 Redis Enterprise 的搜索和查询引擎相比，它可以将查询吞吐量提高高达 16 倍。
轻松融入更大的开发者生态系统
随着 Redis 7.2 的发布，为 Redis 客户端提供了全新的指导和支持。其目前正在与五个客户端库（Jedis (Java)、node-redis (NodeJS)、redis-py (Python)、NRedisStack (.Net) 和 Go-Redis (Go)）的社区维护人员直接合作，建立文档、用户界面、治理和安全性等方面的一致性。还在 Redis Stack 和 Redis Enterprise（云和软件）中支持 RESP3 协议。
让 Redis 对开发人员来说更加强大
此版本还将实时数据的可编程性提升到了一个新的水平。Triggers 和 Functions 的公共预览版带来了服务器端事件驱动引擎，可以在数据库中执行 Typescript/JavaScript 代码。此功能允许开发人员直接在 Redis 上执行复杂的数据操作，确保跨任何客户端应用程序执行的一致性。 Triggers 和 Functions 支持集群级别的 cross-shard 读取操作。该功能是前几代 Redis 可编程引擎（例如 Lua 和函数）所不具备的。
地理空间功能也得到了改进。改进了 Redis Stack 中的多边形搜索，以方便搜索地理空间数据以查找地理区域内的信息。
还大幅提高了 Redis 数据类型排序集的性能，其通常用于创建游戏排行榜等用途。与 Redis Enterprise Cloud 6.2 相比，此增强功能带来了 30% 到 100% 的收益。
能够轻松地与企业工具和基础设施集成
Redis Redis Data Integration (RDI) 现已可用，这是一种直接在 Redis Enterprise 上运行的工具，可以轻松地将任何数据集转换为 Redis。开发团队捕获了最常见的用例，并通过配置界面（而不是代码）提供它们。RDI 可以从各种来源（例如 Oracle、Postgres 或 Cassandra）获取数据，并在功能上将其转换为实时数据。同样，当数据不 “real-time” 时，RDI 可以将 Redis Enterprise 的下游更改引入记录系统，而无需添加更多代码或执行神秘的集成。
RDI（目前处于公共预览版）将源数据库中的更改直接流式传输到 Redis，并在其中进一步过滤、转换并映射为 JSON 和 Hash 等格式。更多详情可查看官方说明。
欲涉足磁盘存储
Redis 方面于2023年10月透露，其正在寻求将磁盘作为分层存储架构的一部分，以降低成本并扩大系统的吸引力。其首席执行官 Rowan Trollope 在接受 The Register 采访时表示，希望此举能够帮助客户降低成本并简化其架构。Trollope 称，亚毫秒级分布式系统为开发人员提供了所需的性能，但必须承认的是，为互联网规模构建的其他系统（例如 MongoDB）可能更具价格优势。为了解决这个问题，该公司已经创建了一种分层的内存方法，在其内存系统后提供闪存支持。
"我们在磁盘和内存之间有半步之遥。对于一些特定的用例，例如在游戏中，公司可能会使用我们来提供他们所需的实时排行榜和其他游戏内统计数据。然而在一些游戏发布初期的热潮结束之后，一大批用户会离开其账户也会随之进入休眠状态，直至新的一集或一些新的内容发布。Trollope 认为，使用闪存可以让用户对内存进行动态分层。"我们可以把那些很久没有使用过的数据转移到闪存中，在那里存放一段时间。当用户再次回来时时，我们可以很容易的将其从闪存无缝移回内存。这样公司就可以节约成本。
现在，Redis 则计划将这一概念扩展到基于磁盘的内存，以提供对三层架构的支持。在 Stack Overflow 2023 年度报告中指出，Redis 被评为专业开发人员中第六大最受欢迎的数据库和第二大最受欢迎的 NoSQL 数据库，有大约 23% 的专业开发人员使用率。系统监控公司 Sumo Logic 的研究报告指出，2020 年，Redis 成为了 AWS 上最受欢迎的数据库。对此，Trollope 认为Redis 流行的一大原因在于缺乏竞争。
“我们并没有真正与其他公司竞争...... 我想说的是，细数世界上最流行的一些数据库，我们在其中也属于领先的内存数据库，其他人都做不到这一点。Mongo 没有这样做。也没有一家云厂商能做到这一点，比如 Azure Cosmos DB、或甲骨文或亚马逊的任何技术（如 DynamoDB）：它们都不是内存数据库。我们与所有其他十大数据库一起被使用，但我们并不真正与它们竞争。”另一方面，Trollope 还透露，Redis 已经解决了缺乏 SQL 支持的问题，RediSQL 模块现已在 GitHub 上可用。并表示未来 Redis 还将支持自然语言查询，以及增强向量和特征存储功能。
7.2.4 已于2024年1月中旬发布，此版本包含了一些安全问题修复。具体更新内容如下：
安全修复：(CVE-2023-41056) 在某些情况下，Redis 可能会错误地处理内存缓冲区的大小调整，这可能导致缓冲区大小的不正确计算，并导致堆溢出和潜在的远程代码执行。
修复 7.0 和 7.2 混合版本的集群命令集群崩溃问题；
修复从节点删除 slot 时 slot ownership 未得到正确处理的问题；
修复 RedisModuleEvent_Key module API 事件的 atomicity issues；
更多信息可参考更新说明。
最新版本：8
Redis v8 已于2025年5月上旬正式 GA，发布公告写道：v8 是迄今为止性能最强、可扩展性最高的 Redis 版本。它拥有超过 30 项性能改进，包括命令速度提升高达 87%，每秒操作吞吐量提升高达 2 倍，复制速度提升高达 18%，以及通过 Redis 查询引擎提供高达 16 倍的查询处理能力。
本次发布新增了 8 种数据结构，包括向量集合 (vector set)、JSON、时间序列以及五种概率结构，包括布隆过滤器、布谷鸟过滤器、计数最小化草图、top-k 和 t-digest（其中一些之前作为单独的 Redis 模块提供）。这些新的数据结构可以帮助您更好地解决当前用例，并为下一代快速和实时应用构建。
布隆过滤器与布谷鸟过滤器 (Bloom filter & Cuckoo filter)：用于检查给定值是否已出现在数据流中
计数最小化草图 (Count-min sketch)：用于估计给定值在数据流中出现的次数
top-k：查找数据流中最频繁的值
t-digest：用于查询数据流中哪些值的比例小于 / 大于给定值
此外，为了让大众更好地感知「Redis 重新开源」的决心，Redis 将免费产品的名称从 Redis 社区版更改为 Redis 开源版，以反映 AGPLv3 开源许可证的添加。Redis Git 仓库的合并已添加了 AGPLv3，同时保留了 RSALv2 和 SSPLv1 作为可选许可证。
最新版本：3.2
该版本改进包括：
* 修复了无磁盘的复制问题(Oran Agra)
* 在角色变化后对 BLPOP 复制进行测试(Salvatore Sanfilippo)
* prepareClientToWrite() 错误处理方法的改进(Salvatore Sanfilippo)
* 移除 dict.c 中不再使用的函数(Salvatore Sanfilippo
3.0 版本与 2.8 版本比较，主要新特性包括如下几个方面：
* Redis Cluster —— 一个分布式的 Redis 实现
* 全新的 "embedded string" 对象编码结果，更少的缓存丢失，在特定的工作负载下速度的大幅提升
* AOF child -> parent 最终数据传输最小化延迟，通过在 AOF 重写过程中的 "last write"
* 大幅提升 LRU 近似算法用于键的擦除
* WAIT 命令堵塞等待写操作传输到指定数量的从节点
* MIGRATE 连接缓存，大幅提升键移植的速度
* MIGARTE 新的参数 COPY 和 REPLACE
* CLIENT PAUSE 命令：在指定时间内停止处理客户端请求
* BITCOUNT 性能提升
* CONFIG SET 接受不同单位的内存值，例如 "CONFIG SET maxmemory 1gb".
* Redis 日志格式小调整用于反应实例的角色 (master/slave)
* INCR 性能提升
3.2版本中增加的最大功能就是对GEO(地理位置)的支持，说起redis的GEO特性，最大的贡献还是中国人。redis作者在对3.2引进新特性的博客中介绍了为什么支持GEO。GEO hashing的api是在Ardb实现的，Ardb是github用户yinqiwen实现的基于redis协议实现的nosql系统，Ardb支持除了redis、还有LevelDB、RocksDB 、LMDB等kv引擎。其中Ardb实现了GEO hashing功能。从Ardb作者的用户名和标识的位置在深圳可以看出Ardb作者应该是中国人，Ardb是用C++写的。redis另一个开发者Matt Stancliff从Ardb提取GEO库，用C语言改写，整合进redis的一个自己的分支，并被redis作者接受，合并进了3.2版本。GEO目前提供以下6个命令。
1、geoadd：增加某个地理位置的坐标。
2、geopos：获取某个地理位置的坐标。
3、geodist：获取两个地理位置的距离。
4、georadius：根据给定地理位置坐标获取指定范围内的地理位置集合。
5、georadiusbymember：根据给定地理位置获取指定范围内的地理位置集合。
6、geohash：获取某个地理位置的geohash值。
地理位置的坐标是以WGS84为标准，WGS84，全称World Geodetic System 1984，是为GPS全球定位系统使用而建立的坐标系统。
-------------------------------
GEO命令
下面来看看具体每个命令的用法。
geoadd
geoadd用来增加地理位置的坐标，可以批量添加地理位置，命令格式为：
GEOADD key longitude latitude member [longitude latitude member ...]
key标识一个地理位置的集合。longitude latitude member标识了一个地理位置的坐标。longitude是地理位置的经度，latitude是地理位置的纬度。member是该地理位置的名称。GEOADD可以批量给集合添加一批地理位置。
geopos
geopos可以获取地理位置的坐标，可以批量获取多个地理位置的坐标，命令格式为：
GEOPOS key member [member ...]
geodist
geodist用来获取两个地理位置的距离，命令格式为：
GEODIST key member1 member2 [m|km|ft|mi]
单位可以指定为以下四种类型：
m：米，距离单位默认为米，不传递该参数则单位为米。
km：公里。
mi：英里。
ft：英尺。
georadius
georadius可以根据给定地理位置坐标获取指定范围内的地理位置集合，命令格式为：
GEORADIUS key longitude latitude radius [m|km|ft|mi] [WITHCOORD] [WITHDIST] [ASC|DESC] [WITHHASH] [COUNT count]
longitude latitude标识了地理位置的坐标，radius表示范围距离，距离单位可以为m|km|ft|mi，还有一些可选参数：
WITHCOORD：传入WITHCOORD参数，则返回结果会带上匹配位置的经纬度。
WITHDIST：传入WITHDIST参数，则返回结果会带上匹配位置与给定地理位置的距离。
ASC|DESC：默认结果是未排序的，传入ASC为从近到远排序，传入DESC为从远到近排序。
WITHHASH：传入WITHHASH参数，则返回结果会带上匹配位置的hash值。
COUNT count：传入COUNT参数，可以返回指定数量的结果。
georadiusbymember
georadiusbymember可以根据给定地理位置获取指定范围内的地理位置集合。georadius命令传递的是坐标，georadiusbymember传递的是地理位置。georadius更为灵活，可以获取任何坐标点范围内的地理位置。但是大多数时候，只是想获取某个地理位置附近的其他地理位置，使用georadiusbymember则更为方便。georadiusbymember命令格式为(命令可选参数与georadius含义一样)：
GEORADIUSBYMEMBER key member radius [m|km|ft|mi] [WITHCOORD] [WITHDIST] [ASC|DESC] [WITHHASH] [COUNT count]
geohash
geohash可以获取某个地理位置的geohash值。geohash是将二维的经纬度转换成字符串hash值的算法，后面会具体介绍geohash原理。可以批量获取多个地理位置的geohash值。命令格式为：
GEOHASH key member [member ...]
-------------------------------
Redis GEO实现
GEO实现主要包含了以下两项技术：
1.使用geohash保存地理位置的坐标。
2.使用有序集合(zset)保存地理位置的集合。
geohash
geohash的思想是将二维的经纬度转换成一维的字符串，geohash有以下三个特点：
1.字符串越长，表示的范围越精确。编码长度为8时，精度在19米左右，而当编码长度为9时，精度在2米左右。
2.字符串相似的表示距离相近，利用字符串的前缀匹配，可以查询附近的地理位置。这样就实现了快速查询某个坐标附近的地理位置。
3.geohash计算的字符串，可以反向解码出原来的经纬度。
这三个特性让geohash特别适合表示二维hash值。这篇文章：GeoHash核心原理解析详细的介绍了geohash的原理，想要了解geohash实现的朋友可以参考这篇文章。
GEO命令实现
知道了redis使用有序集合(zset)保存地理位置数据(想了解redis有序集合的，可以参看这篇文章《有序集合对象》)，以及geohash的特性，就很容易理解redis是如何实现redis GEO命令了。细心的读者可能发现，redis没有实现地理位置的删除命令。不过由于GEO数据保存在zset中，可以用zrem来删除某个地理位置。
geoadd命令增加地理位置的时候，会先计算地理位置坐标的geohash值，然后地理位置作为有序集合的member，geohash作为该member的score。然后使用zadd命令插入到有序集合。
geopos命令则先根据地理位置获取geohash值，然后decode得到地理位置的坐标。
geodist命令先根据两个地理位置各自得到坐标，然后计算两个坐标的距离。
georadius和georadiusbymember使用相同的实现，georadiusbymember多了一步把地理位置转换成对应的坐标。然后查找该坐标和周围对应8个坐标符合距离要求的地理位置。因为geohash得到的值其实是个格子，并不是点，这样通过计算周围对应8个坐标就能解决边缘问题。由于使用有序集合保存地理位置，在对地列位置基于范围查询，就相当于实现了zrange命令，内部的实现确实与zrange命令一致，只是geo有些特别的处理，比如获得的某个地理位置，还需要计算该地理位置是否符合给定的距离访问。
geohash则直接返回了地理位置的geohash值。
redis关于geohash使用了Ardb的geohash库geohash-int，redis使用的geohash编码长度为26位。可以精确到0.59m的精度。
通过开GEO的相关信息，可以看出redis借助了有序集合(zset)和geohash，加上redis本身实现的命令框架，可以很容易的实现地理位置相关的命令。
最新版本：4.0
Redis v4.0.0 正式发布，这是 Redis v4.0 系列的首个稳定版，包含以下的一些重大改进：模块化的系统、更好的复制 (PSYNC2)、对 eviction policies, threaded DEL/FLUSH 的改进、混合 RDB+AOF 格式、对 Raspberry Pi 的支持作为主要平台、新的 MEMORY 命令行、Redis Cluster 对 Nat/Docker 的支持、更快的 Redis Cluster 键创建，以及许多其他较小的功能和一些行为修复等。与之前的 RC 相比，有一些错误修复和改进，主要是：
针对新的复制引擎 PSYNC2 的修复
引入了模块线程安全上下文(Modules thread safe contexts)，现在还是一个实验性的 API，但是当需要时，该 API 被认为是稳定和可用的
SLOWLOG 现在会记录 offending 的客户端名字和地址。要注意的是，这是对于向后兼容性的破坏，以防旧代码会判断 slowlog 条目由三个条目组成。
模块原生数据类型 RDB 格式已更改
AOF 检查程序现在可以处理 RDB preambles
添加了不支持 STORE 选项的 GEORADIUS_RO 和 GEORADIUSBYMEMBER_RO 变体，为了允许这种查询的只读扩容
HSET 现在是可变的，HMSET 被认为是弃用的(但将来会支持)。新的代码中请使用 HSET
添加 DEBUG DIGEST 模块 API
HyperLogLog 命令不再在某些输入的字符串中(非 HLL)崩溃
修复在 MULTI/EXEC blocks 中的 SLAVEOF
修复了重要的安全问题、SCAN 命令系列错误、PSYNC2 边界案件到期。与 Sentinel 相关的修复。
其他许多小的 bug 修复和改进
更多详情请参阅发行说明。
最新版本：5.0
1. 新的流数据类型(Stream data type)
2. 新的 Redis 模块 API：定时器、集群和字典 API(Timers, Cluster and Dictionary APIs)
3. RDB 现在可存储 LFU 和 LRU 信息
4. redis-cli 中的集群管理器从 Ruby (redis-trib.rb) 移植到了 C 语言代码。执行 `redis-cli --cluster help` 命令以了解更多信息
5. 新的有序集合(sorted set)命令：ZPOPMIN/MAX 和阻塞变体(blocking variants)
6. 升级 Active defragmentation 至 v2 版本
7. 增强 HyperLogLog 的实现
8. 更好的内存统计报告
9. 许多包含子命令的命令现在都有一个 HELP 子命令
10. 客户端频繁连接和断开连接时，性能表现更好
11. 许多错误修复和其他方面的改进
12. 升级 Jemalloc 至 5.1 版本
13. 引入 CLIENT UNBLOCK 和 CLIENT ID
14. 新增 LOLWUT 命令
15. 在不存在需要保持向后兼容性的地方，弃用 "slave" 术语
16. 网络层中的差异优化
17. Lua 相关的改进：
- 将 Lua 脚本更好地传播到 replicas / AOF
- Lua 脚本现在可以超时并在副本中进入 -BUSY 状态
18. 引入动态的 HZ(Dynamic HZ) 以平衡空闲 CPU 使用率和响应性
19. 对 Redis 核心代码进行了重构并在许多方面进行了改进
Redis 5 是 Redis 引入流数据类型(Stream data type)的第一个版本。按照官方的说法，不使用该特性的用户在生产环境中使用 Redis 5 会有更好的体验 -- 虽然开发团队尚未发现关于这项特性的关键错误。此外，因为许多内部结构与 Redis 4 共享，因此在内部工作方式方面，变化不会很大。修复了两个关于 Streams 消费者的问题 -- 可以在访问历史记录时由 XREADGROUP 复制项目的组，以及 XREADGROUP 可以报告某些历史记录的另一个错误，即使待添加的消费者列表为空。目前已解决了这两个问题，并进行了单元测试以避免出现回归错误。此外，该版本还修复了集群模式下 redis-cli 的一些问题。最后关于 FreeBSD 和 DragonFly 的一些构建问题现在也已经解决。详细更新内容请查看发行说明。
2021年2月下旬，Redis 同时发布了 5.0.11、6.0.11 和 6.2 版本。对于使用 32 位 Redis 的用户来说，此次更新解决了一个重要的安全问题，即 32 位系统上的整数溢出(CVE-2021-21309：Redis 4.0 或更新版本对批量输入的最大值使用了一个可配置的限制。默认情况下，它是 512MB，对所有平台来说都是一个安全值。如果大幅增加限制，从客户端接收到一个大的请求可能会触发整数溢出的情况，这将导致缓冲区溢出和堆损坏。主要更新内容如下：
5.0.11
修复分叉进程删除父进程 pid 文件的问题
修复 flock 群集配置可能导致 kill -9 后重启失败的问题
避免在 redis-sentinel 中读取越界
最新版本：6.0
Redis v6.0.6 已发布，此版本修复了一些 bug，其中主要内容包括：
修复启用带前缀的 CLIENT TRACKING 时崩溃的问题
EXEC 始终会因 EXECABORT 而失败，并且已清除多状态
RESTORE ABSTTL 不会将过期的密钥存储到数据库中
redis-cli 能够更好地处理非优先键名
TLS：关闭 tls-auth-clients 时忽略客户端证书
Tracking：修复刷新时的无效消息
在 Sentinel 启动时通知 systemd
修复因滥用 STRALGO 而导致的崩溃
module API 中的一些修复
修复一些罕见的泄漏(STRALGO 错误滥用，Sentinel)
修复了脚本碎片整理中可能的无效访问
一些新的特性
LPOS 命令，用于在列表中搜索
在集群模式下的 redis-cli 和 redis-benchmark 中使用 user+pass 进行迁移
redis-cli 支持 --pipe、-rdb 和 --replica 选项的 TLS
TLS：支持会话缓存配置
更多更新说明请查看这里。
常说 Redis 是单线程模型，是指 Redis 采用单线程的事件驱动模型，只有并且只会在一个主线程中执行 Redis 命令操作，这意味着它在处理请求时不使用复杂的上下文切换或锁机制。尽管只是单线程的架构，但 Redis 通过非阻塞的 I/O 操作和高效的事件循环来处理大量的并发连接，性能仍然非常高。然而在 Redis4.0 开始也引入了一些后台线程执行异步淘汰、异步删除过期 key、异步执行大 key 删除等任务，然后，在 Redis6.0 中引入了多线程 IO 特性，将 Redis 单节点访问请求从 10W 提升到 20W。
而在 Valkey 社区首个发布的 Valkey v8.0 版本，在 I/O 线程系统上进行了重大升级，特别是异步 I/O 线程的引入，使主线程和 I/O 线程能够并行工作，可实现最大化服务吞吐量并减少瓶颈，使得 Valkey 单节点访问请求可以提升到 100W。那么在 Redis6.0 和 Valkey8.0 中多线程 IO 是怎么回事呢，是否改变了 Redis 原有单线程模型？
1.2024 年，Redis 商业支持公司 Redis Labs 宣布 Redis 核心代码的许可证从 BSD 变更为 RSALv2，明确禁止云厂商提供 Redis 托管服务，这一决定直接导致社区分裂。
2.为维护开源自由，Linux 基金会联合多家科技公司（包括 AWS、Google、Cloud、Oracle 等）宣布支持 Valkey，作为 Redis 的替代分支。
3.新近在 Redis 项目创始人 antirez 今年加入 Redis 商业公司 5 个月后，Redis 宣传从 Redis8 开始，Redis 项目重新开源。
本节主要介绍 Redis v6.0 多线程 IO 特性。
多线程 IO 概述
Redis v6.0 引入多线程 IO，但多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。默认是不开启的，需要进程启动前开启配置，并且在运行期间无法通过 config set 命令动态修改。
参数与配置
多线程 IO 涉及下面两个配置参数：
# io-threads 4 IO 线程数量
# io-threads-do-reads no 读数据及数据解析是否也用 IO 线程
1.io-threads 表示 IO 线程数量， io-threads 设置为 1 时（代码中默认值），表示只使用主线程，不开启多线程 IO。因此，若要配置开启多线程 IO，需要设置 io-threads 大于 1，但不可以超过最大值 128。
2.但在默认情况下，Redis 只将多线程 IO 用于向客户端写数据，因为作者认为通常使用多线程执行读数据的操作帮助不是很大。如果需要使用多线程用于读数据和解析数据，则需要将参数 io-threads-do-reads 设置为 yes 。
3.此两项配置参数在 Redis 运行期间无法通过 config set 命令修改，并且开启 SSL 时，不支持多线程 IO 特性。
4.若机器 CPU 将至少超过 4 核时，则建议开启，并且至少保留一个备用 CPU 核，使用超过 8 个线程可能并不会有多少帮助。
执行流程概述
Redis v6.0 引入多线程 IO 后，读写数据执行流程如下所示：
流程简述
主线程负责接收建立连接请求，获取 socket 放入全局等待读处理队列。
主线程处理完读事件之后，通过 RR（Round Robin）将这些连接分配给这些 IO 线程，也会分配给主线程自己。
主线程先读取分配给自己的客户端数据，然后阻塞等待其他 IO 线程读取 socket 完毕。
IO 线程将请求数据读取并解析完成（这里只是读数据和解析、并不执行）。
主线程通过单线程的方式执行请求命令。
主线程通过 RR（Round Robin）将回写客户端事件分配给这些 IO 线程，也会分配给主线程自己。
主线程同样执行部分写数据到客户端，然后阻塞等待 IO 线程将数据回写 socket 完毕。
设计特点
1.IO 线程要么同时在读 socket，要么同时在写，不会同时读和写。
2.IO 线程只负责读写 socket 解析命令，不负责命令执行。
3.主线程也会参与数据的读写。
使用 redis-benchmark 做 Redis6 单线程和多线程简单 SET/GET 命令性能测试：
1.GET/SET 命令在设置 4 个 IO 线程时，QPS 相比于大部分情况下的单线程，性能几乎是翻倍了。
2.连接数越多，多线程优势越明显；value 值越小，多线程优势越明显。
3.使用多线程读命令比写命令优势更加明显，当 value 越大，写命令越发没有明显的优势。
4.参数 io-threads-do-reads 为 yes，性能有微弱的优势，不是很明显。
总体来说，以上结果基本符合预期，结果仅作参考。尽管引入多线程 IO 大幅提升了 Redis 性能，但是 Redis v6.0 的多线程 IO 仍然存在一些不足：
1.CPU 核心利用率不足：当前主线程仍负责大部分的 IO 相关任务，并且当主线程处理客户端的命令时，IO 线程会空闲相当长的时间，同时值得注意的是，主线程在执行 IO 相关任务期间，性能受到最慢 IO 线程速度的限制。
2.IO 线程执行的任务有限：目前，由于主线程同步等待 IO 线程，线程仅执行读取解析和写入操作。如果线程可以异步工作，我们可以将更多工作卸载到 IO 线程上，从而减少主线程的负载。
3.不支持带有 TLS 的 IO 线程。
最新的 Valkey v8.0 版本中，通过引入异步 IO 线程，将更多的工作转移到 IO 线程执行，同时通过批量预读取内存数据减少内存访问延迟，大幅提高 Valkey 单节点访问 QPS，单个实例每秒可处理 100 万个请求。后续再详细介绍 Valkey8.0 异步 IO 特性。
Redis v6.0 引入多线程 IO，但多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。通过开启多线程 IO，并设置合适的 CPU 数量，可以提升访问请求一倍以上。多线程 IO 仍然存在一些不足，没有充分利用 CPU 核心，在最新的 Valkey v8.0 版本中，引入异步 IO 将进一步大幅提升 Valkey 性能。
2020年9月，v6.0.7 发布，修复了一些中等程度的 bug 并添加了新特性。更新内容如下：
在 RDB/ROF 加载期间到达时，CONFIG SET 可能会挂起客户端(当处理完另一条同样以 -LOADING error 被拒绝的命令后)。
stream 类型密钥的 UNLINK/Lazyfree 永远不会进行异步释放。
PERSIST 应该使 WATCH 无效(就像 EXPIRE 一样)
只有 read 命令的 EXEC 可能在 OOM 时被拒绝。
TLS：放宽对 CONFIG SET 的验证(如果设置了某些配置并且未启用 tls，则不会出错)
TLS：支持 cluster/replication，无需 tls-port
网络联机后系统启动
Redis 基准改进及各种小错误修复
添加 oom-score-adj 配置选项以控制 Linux OOM killer
在 INFO 输出中显示 IO 线程统计信息和状态
添加可选的 tls 验证模式
Module API
添加 RedisModule_HoldString 与 loaded keyspace event
修复 RedisModuleEvent_LoadingProgress
修复 successful psync 时 RedisModuleEvent_MasterLinkChange hook missing 的问题
修复丢失的 RM_CLIENTINFO_FLAG_SSL
重构 redismodule.h 以与 -fno-common/extern 一起使用
官方表示，除非有意外情况，否则此版本应当是最后的一个 6.0.x 系列版本，Redis 团队更专注于 Redis 6.2 的开发。通过 CONFIG SET 设置 oom-score-adj-value 或从配置文件加载 oom-score-adj-value 后，CONFIG REWRITE 将生成损坏的配置文件，这会导致 Redis 无法启动
修复 MacOS 上的 redis-cli --pipe 问题；修复 HKEYS/HVALS 在不存在的密钥上的 RESP3 响应
各种小的 bug 修复以及如下的新特性
设为 madvise 时，删除 THP 警告；允许 EXEC 在集群中的只读副本上使用读取命令；将主/副本选项添加到 redis-cli --cluster 调用命令
更多详情见发行公告。
最新版本：6.2
Redis 6.2.2 现已于2021年4月发布，该版本升级迫切性程度为高，尤其对于那些使用 ACL 和 pub/sub，CONFIG REWRITE，或遭受性能下降影响的用户来说，详见下文：
修复了 Redis 6.2 之前版本中的回归问题：
修复 BGSAVE、AOFRW 和复制速度因 child reporting CoW 而变慢的问题
修复定时器事件即将触发时的 short busy loop
修复 default user、overwritten 和 reset users 失去 Pub/Sub 频道权限的问题
修复在没有 IPv6 的情况下无法启动 alpine/libmusl 的问题
修复模块中 propagation 和 MULTI/EXEC 的问题
......
只适用于 Redis 6.2 以前版本的错误修复：
ACL Pub/Sub 通道 save/load 方案的权限处理
允许在 busy scripts 中使用 RESET 命令
修复一些未计入统计信息的错误回复
Bug 修复：
为卡在 fullsync 中的副本添加超时机制
即使默认用户没有权限，也可以处理 HELLO 命令
修复 list-compress-depth 可能会压缩比所需数量更多的节点
修复 redis-cli 对 rediss://URL 方案的处理
Cluster：跳过不必要的检查，这可能会阻止故障检测
Sentinel：在 sentinel 获得第一个响应之前修复信息刷新时间字段
Systemd：当副本准备好接受连接时发送准备就绪通知
Command behavior changes：
ZADD：修复当 INCR 与 GT/LT 一起使用时阻止更新的错误 reply
XAUTOCLAIM：修复响应，返回下一个可用的 id 作为光标
XAUTOCLAIM：修复 JUSTID 以防止 incrementing delivery_count
New config options：
添加 cluster-allow-replica-migration 配置选项
添加 replica-announced 配置选项
在 TLS 群集中添加对纯文本客户端的支持
添加对读取加密密钥文件的支持
Improvements：
修复 BRPOP 在 Redis 6.0 上的性能回归
避免为含有敏感数据的配置置添加 slowlog entries
改进 redis-cli 非二进制安全字符串的处理方式
优化 CLUSTER SLOTS reply
处理 remaining fsync 错误
Info fields 和 introspection changes：
从 current_fork_perc 信息字段中删除 ％ 符号
修复 FreeBSD 上的 RSS 内存信息
修复'INFO CLIENTS'中当所有客户端都掉线时的 client_recent_max_input/output_buffer
修复信息复制中无效的 master_link_down_since_seconds
与平台和部署相关的更改：修复 FreeBSD <12.x 版本
Modules：
为 RedisModule_log logging levels 添加宏
添加 RedisModule_GetAbsExpire/RedisModule_SetAbsExpire
为 key space notification 添加一个模块类型
仅在 masters 中设置 module eviction context 标志
修复无法使用的 RedisModule_IsAOFClient API
修复 EVAL 执行失败后 modules propagatio 中 EXEC 缺失的问题
更多详情可查看更新说明。
6.0.11
修复对线程 IO 和客户端暂停故障转移的处理可能导致数据丢失或崩溃的问题
修复从大型哈希表中选择随机元素的问题
修复客户端跟踪 tracking-redir-broken 消息中损坏的协议
XINFO 能够访问副本上的过期密钥
修复与 -a或 --dbnum 一起使用时 redis-benchmark 中损坏的协议
避免测试 arm64 CoW 错误时的断言在较早的内核上
CONFIG REWRITE 应该接受 umask 设置
修复 COMMAND 命令中 firstkey、lastkey、step 的某些命令
6.2
修复客户端跟踪tracking-redir-broken消息中损坏的协议
避免在 INFO 命令状态、错误状态、模块中使用不安全的字段名称字符
XINFO 可以在 CLIENT PAUSE WRITE 期间访问过期的密钥
修复 REPLCONF ip 地址的允许长度
当切换到新的列表包时，XADD 会计算已删除的记录
v6.2.3 已于2021年5月发布，此版本主要包含对影响认证客户端连接的安全问题的修复。
STRALGO LCS 命令中的整数溢出(CVE-2021-29477)：Redis 6.0 版或更新的版本中存在一个整数溢出漏洞，可利用 STRALGO LCS 命令破坏堆并可能导致远程代码执行。从 6.0 开始，所有版本的 Redis 都存在整数溢出漏洞。
在 large intsets 的 COPY 命令中出现整数溢出(CVE-2021-29478)：Redis 6.2 中的一个整数溢出漏洞可被利用来破坏堆并可能导致远程代码执行。该漏洞涉及改变默认的 set-max-intset-entries 配置值，创建一个由整数值组成的大型集合键，并使用 COPY 命令来复制它。整数溢出漏洞存在于从 2.6 开始的所有版本的 Redis 中，它可能导致损坏的 RDB 或 DUMP 有效载荷，但不能通过 COPY(6.2 之前不存在)进行利用。适用于 Redis 6.2 以前版本的错误修复：
修复 moduleDefragGlobals 中的内存泄漏
修复执行 lazy freeing 客户端跟踪表时的内存泄漏
阻止滥用副本发送可能断言和使 Redis 崩溃的命令
使用 monotonic clock 检查 Lua 脚本超时
redis-cli：在 cluster 模式下重定向时，不要使用 unix socket
详细内容请查看 Redis 仓库更新。
最新版本：7.0
Redis 7.0 现已于2022年4有下旬正式发布，该版本已经开发了将近一年，之前经历了三个候选版本。现如今，开发团队认为它已经足够稳定，可以应用于生产。7.0 几乎包括了对各个方面的增量改进。其中最值得注意的是 Redis Functions、ACLv2、command introspection 和 Sharded Pub/Sub，它们代表了基于用户反馈和生产经验教训的现有功能的重大演变。添加了近 50 个新命令和选项来支持这种演变并扩展 Redis 的现有功能。例如，位图、列表、集合、排序集合和流数据类型都添加了支持其数据管理用例的功能。此外，缓存语义已扩展为支持 existential 和 comparative modifiers。
公告指出，“虽然面向用户的功能很容易夸大，但这个版本中真正的 unsung heroes 其实是努力使 Redis 更高效、更稳定和更精简”。开发人员的大部分精力都投入到了通过关注 Redis 相对于它使用的资源的性能来提高 Redis 的操作效率。对其管理的几乎每个子系统都进行了多项改进，包括内存、计算、网络和存储。虽然有些优化是默认启用的，但其他优化可能需要配置。有关详细信息，可参阅 redis.conf 文件中的内联文档。
同时Redis 7.2 的开发工作也已经在进行当中了，更多详情可查看发行说明。
7.0.12 现已于2023年7月上旬发布，此版本包含了一些安全问题修复。具体更新内容如下：
修复(CVE-2022-24834) 在 Redis 中执行的特制 Lua 脚本可能会触发 cjson 和 cmsgpack 库中的堆溢出，并导致堆损坏和潜在的远程代码执行。从 2.6 开始，所有支持 Lua 脚本的 Redis 版本都存在该问题，并且仅影响经过认证和授权的用户。
修复(CVE-2023-36824) 在某些情况下，从命令和参数列表中提取键名称可能会触发堆溢出，并导致读取随机堆内存、堆损坏和潜在的远程代码执行。特别是：使用 COMMAND GETKEYS* 并验证 ACL 规则中的键名称。
当存在分叉子项时重新启用 downscale rehashing。
修复与 <count> 一起使用时 HRANDFIELD、SRANDMEMBER、ZRANDMEMBER 中可能出现的挂起问题。
改善 RANDOMKEY、HRANDFIELD、SRANDMEMBER、ZRANDMEMBER、SPOP 和 eviction 中的公平性问题。
修复 WAIT 在被阻止的模块命令被解锁后生效的问题。
在极少数情况下，避免 master 重新启动后不必要的完全同步。
更多情况请详见更新说明。
7.2.0 现已于2023年8月中旬发布，这是首个 Unified Redis Release。包含一系列广泛的新功能，以及对人工智能计划功能支持的重大投资。公告称，这是 “影响最深远的版本。在每一项增强功能中，你都能感受到一个强烈的主题：让开发人员更轻松地使用 Redis，使其运行得更快，并更轻松地实现创新成果。我们承诺通过所有分发渠道一次性交付所有这些功能，称之为 Unified Redis Release。”
让 AI 创新更容易实现
Redis 通过多种旨在提高效率、降低成本以及增强可扩展性和性能的策略来支持其数据库服务中的生成式 AI 工作负载。Redis 的矢量数据库支持两种矢量索引类型：FLAT（brute force search）和 HNSW（approximate search），以及三种流行的距离度量：余弦、内积和欧几里得距离。其他功能包括范围查询、混合搜索（组合过滤器和语义搜索）、JSON 对象支持等。其通过以下方式帮助构建和部署 LLM 支持的应用程序：
1.检索增强生成 (RAG)：在 RAG 框架内，使用预先训练的 LLM 和客户自己的数据生成响应。许多组织希望利用生成式人工智能的力量，而不需要构建自己的模型或对现有模型进行微调。此外，他们对于是否与商业 LLM 分享其专有数据犹豫不决。这就是 Redis Enterprise 的用武之地。作为矢量数据库，它提供强大的混合语义搜索功能来精确定位相关数据。此外，它还可以部署为外部特定领域的知识库。这可确保通用 LLM 获得最相关和最新的背景信息，从而提高结果质量并减少幻觉。
2.LLM 语义缓存： Redis Enterprise 通常用作可扩展缓存来存储先前回答的用户查询和结果。Redis 还使用语义缓存来识别和检索在语义上与输入查询足够相似的缓存响应，从而显着提高缓存命中率。这显着减少了发送到 LLM 服务的请求和令牌的数量，从而通过减少生成响应的时间来降低成本并提高性能。
3.推荐系统：LLM 可以作为复杂的电子商务虚拟购物助理的支柱。Redis Enteprise 的上下文理解和语义搜索使应用程序能够理解客户查询、提供个性化产品推荐，甚至模拟对话交互 —— 所有这些都是实时的。
4.文档搜索：在需要组织分析大量文档的情况下，LLM 支持的应用程序可以作为文档发现和检索的强大工具。Redis Enterprise 的混合语义搜索功能使得查明相关信息并从这些文档生成新内容成为可能。
在过去的 12 个月时间里，Redis 已与最流行的应用程序开发框架集成，以创建由 LLM 驱动的聊天机器人、代理和链。其中包括 LlamaIndex、Langchain、RelevanceAI、DocArray、MantiumAI 和 ChatGPT 检索插件。此外，还与 NVIDIA 就一些领先的 AI 项目进行了密切合作：NVIDIA 的 AI Workflows（Merlin 和 Morpheus）、Tools（Triton 和 RAPIDS），以及 NVIDIA 为提供更高的每秒查询次数（QPS）而提供的最先进索引技术 RAPIDS RAFT。在 Redis Enterprise 7.2 中推出了可扩展搜索功能的预览版。它允许运行高 QPS、低延迟的工作负载，并跨集群实现最佳分布式处理。与之前 Redis Enterprise 的搜索和查询引擎相比，它可以将查询吞吐量提高高达 16 倍。
轻松融入更大的开发者生态系统
随着 Redis 7.2 的发布，为 Redis 客户端提供了全新的指导和支持。其目前正在与五个客户端库（Jedis (Java)、node-redis (NodeJS)、redis-py (Python)、NRedisStack (.Net) 和 Go-Redis (Go)）的社区维护人员直接合作，建立文档、用户界面、治理和安全性等方面的一致性。还在 Redis Stack 和 Redis Enterprise（云和软件）中支持 RESP3 协议。
让 Redis 对开发人员来说更加强大
此版本还将实时数据的可编程性提升到了一个新的水平。Triggers 和 Functions 的公共预览版带来了服务器端事件驱动引擎，可以在数据库中执行 Typescript/JavaScript 代码。此功能允许开发人员直接在 Redis 上执行复杂的数据操作，确保跨任何客户端应用程序执行的一致性。 Triggers 和 Functions 支持集群级别的 cross-shard 读取操作。该功能是前几代 Redis 可编程引擎（例如 Lua 和函数）所不具备的。
地理空间功能也得到了改进。改进了 Redis Stack 中的多边形搜索，以方便搜索地理空间数据以查找地理区域内的信息。
还大幅提高了 Redis 数据类型排序集的性能，其通常用于创建游戏排行榜等用途。与 Redis Enterprise Cloud 6.2 相比，此增强功能带来了 30% 到 100% 的收益。
能够轻松地与企业工具和基础设施集成
Redis Redis Data Integration (RDI) 现已可用，这是一种直接在 Redis Enterprise 上运行的工具，可以轻松地将任何数据集转换为 Redis。开发团队捕获了最常见的用例，并通过配置界面（而不是代码）提供它们。RDI 可以从各种来源（例如 Oracle、Postgres 或 Cassandra）获取数据，并在功能上将其转换为实时数据。同样，当数据不 “real-time” 时，RDI 可以将 Redis Enterprise 的下游更改引入记录系统，而无需添加更多代码或执行神秘的集成。
RDI（目前处于公共预览版）将源数据库中的更改直接流式传输到 Redis，并在其中进一步过滤、转换并映射为 JSON 和 Hash 等格式。更多详情可查看官方说明。
欲涉足磁盘存储
Redis 方面于2023年10月透露，其正在寻求将磁盘作为分层存储架构的一部分，以降低成本并扩大系统的吸引力。其首席执行官 Rowan Trollope 在接受 The Register 采访时表示，希望此举能够帮助客户降低成本并简化其架构。Trollope 称，亚毫秒级分布式系统为开发人员提供了所需的性能，但必须承认的是，为互联网规模构建的其他系统（例如 MongoDB）可能更具价格优势。为了解决这个问题，该公司已经创建了一种分层的内存方法，在其内存系统后提供闪存支持。
"我们在磁盘和内存之间有半步之遥。对于一些特定的用例，例如在游戏中，公司可能会使用我们来提供他们所需的实时排行榜和其他游戏内统计数据。然而在一些游戏发布初期的热潮结束之后，一大批用户会离开其账户也会随之进入休眠状态，直至新的一集或一些新的内容发布。Trollope 认为，使用闪存可以让用户对内存进行动态分层。"我们可以把那些很久没有使用过的数据转移到闪存中，在那里存放一段时间。当用户再次回来时时，我们可以很容易的将其从闪存无缝移回内存。这样公司就可以节约成本。
现在，Redis 则计划将这一概念扩展到基于磁盘的内存，以提供对三层架构的支持。在 Stack Overflow 2023 年度报告中指出，Redis 被评为专业开发人员中第六大最受欢迎的数据库和第二大最受欢迎的 NoSQL 数据库，有大约 23% 的专业开发人员使用率。系统监控公司 Sumo Logic 的研究报告指出，2020 年，Redis 成为了 AWS 上最受欢迎的数据库。对此，Trollope 认为Redis 流行的一大原因在于缺乏竞争。
“我们并没有真正与其他公司竞争...... 我想说的是，细数世界上最流行的一些数据库，我们在其中也属于领先的内存数据库，其他人都做不到这一点。Mongo 没有这样做。也没有一家云厂商能做到这一点，比如 Azure Cosmos DB、或甲骨文或亚马逊的任何技术（如 DynamoDB）：它们都不是内存数据库。我们与所有其他十大数据库一起被使用，但我们并不真正与它们竞争。”另一方面，Trollope 还透露，Redis 已经解决了缺乏 SQL 支持的问题，RediSQL 模块现已在 GitHub 上可用。并表示未来 Redis 还将支持自然语言查询，以及增强向量和特征存储功能。
7.2.4 已于2024年1月中旬发布，此版本包含了一些安全问题修复。具体更新内容如下：
安全修复：(CVE-2023-41056) 在某些情况下，Redis 可能会错误地处理内存缓冲区的大小调整，这可能导致缓冲区大小的不正确计算，并导致堆溢出和潜在的远程代码执行。
修复 7.0 和 7.2 混合版本的集群命令集群崩溃问题；
修复从节点删除 slot 时 slot ownership 未得到正确处理的问题；
修复 RedisModuleEvent_Key module API 事件的 atomicity issues；
更多信息可参考更新说明。
最新版本：8
Redis v8 已于2025年5月上旬正式 GA，发布公告写道：v8 是迄今为止性能最强、可扩展性最高的 Redis 版本。它拥有超过 30 项性能改进，包括命令速度提升高达 87%，每秒操作吞吐量提升高达 2 倍，复制速度提升高达 18%，以及通过 Redis 查询引擎提供高达 16 倍的查询处理能力。
本次发布新增了 8 种数据结构，包括向量集合 (vector set)、JSON、时间序列以及五种概率结构，包括布隆过滤器、布谷鸟过滤器、计数最小化草图、top-k 和 t-digest（其中一些之前作为单独的 Redis 模块提供）。这些新的数据结构可以帮助您更好地解决当前用例，并为下一代快速和实时应用构建。
布隆过滤器与布谷鸟过滤器 (Bloom filter & Cuckoo filter)：用于检查给定值是否已出现在数据流中
计数最小化草图 (Count-min sketch)：用于估计给定值在数据流中出现的次数
top-k：查找数据流中最频繁的值
t-digest：用于查询数据流中哪些值的比例小于 / 大于给定值
此外，为了让大众更好地感知「Redis 重新开源」的决心，Redis 将免费产品的名称从 Redis 社区版更改为 Redis 开源版，以反映 AGPLv3 开源许可证的添加。Redis Git 仓库的合并已添加了 AGPLv3，同时保留了 RSALv2 和 SSPLv1 作为可选许可证。