Question

Redis 即 REmote Dictionary Server (远程字典服务)。

Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API。从 2010 年 3 月 15 日起，Redis 的开发 工作由 VMware 主持。从 2013 年 5 月开始，Redis 的开发由 Pivotal 赞助。

• 官网： http://redis.io/
• Redis 中文官方网站
• 在线 redis: Try Redis

Redis 是一个开源的，基于网络的，高性能的 key-value 数据库，弥补了 memcached 这类 key-value 存储的不足，在部分场合可以对关系数据库起到很好的补充作用，满足实时的高并发需求。

Redis 跟 memcached 类似，不过数据可以持久化，而且支持的数据类型很丰富。支持在服务器端计算集合的并、交和补集(difference) 等，还支持多种排序功能。

说明： Redis 客户端跟服务端间的网络数据传输未加密，建议不要使用 Redis 存取敏感数据，否则可能存在安全风险。

Redis 与其他 key - value 缓存产品有以下三个特点：

• Redis 支持 5 种存储结构：不仅仅支持简单的 key-value 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。每种存储结构都有自己独特的命令。
• Redis 支持数据的备份，即 master-slave 模式的数据备份。
• Redis 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

Redis 优势

• 丰富的数据类型 – Redis 支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
• 原子 – Redis 的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过 MULTI 和 EXEC 指令包起来。
• 丰富的特性 – Redis 还支持 publish/subscribe、通知、key 过期等特性。

版本

版本号命名规则类似 linux，Redis 使用标准版本标记进行版本控制：major.minor.patchlevel。偶数的版本号表示稳定的版本， 例如 1.2，2.0，2.2，2.4，2.6，2.8，奇数的版本号用来表示非标准版本，例如 2.9.x 是非稳定版本，它的稳定版本是 3.0。

表格 redis 版本列表 redis 中文网更新日志 -- Redis 中国用户组（CRUG）

版本	发布时间	特性说明
6.0.6	2020-8-27	1. 多线程 IO：引入多线程 IO，但多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。2. 客户端缓存。3. ACL 权限控制。4. 支持 SSL。RESP3 协议。PSYNC2 改进。...
5	2018-10-18	1. 新的 Stream 数据类型。2.新的 Redis 模块 API。 3. RDB 现在存储 LFU 和 LRU 信息。 4.集群管理器从 Ruby（redis-trib.rb）移植到 C 代码。可以在 redis-cli 中。查看 redis-cli —cluster help 了解更多信息。 5.新 sorted set 命令：ZPOPMIN / MAX 和阻塞变量。 6.主动碎片整理 V2。 7.增强 HyperLogLog 实现。 8.更好的内存统计报告。 9.许多带有子命令的命令现在都有一个 HELP 子命令。 10.客户经常连接和断开连接时性能更好。 11.错误修复和改进。 12. Jemalloc 升级到 5.1 版
4	2017.7.15	1）提供了模块系统，方便第三方开发者拓展 Redis 的功能。 2）PSYNC2.0：优化了之前版本中，主从节点切换必然引起全量复制的问题。 3）提供了新的缓存剔除算法：LFU（Last Frequently Used），并对已有算法进行了优化。 4）提供了非阻塞 del 和 flushall/flushdb 功能，有效解决删除了 bigkey 可能造成的 Redis 阻塞。 5）提供了 memory 命令，实现对内存更为全面的监控统计。 6）提供了交互数据库功能，实现 Redis 内部数据库的数据置换。 7）提供了 RDB-AOF 混合持久化格式，充分利用了 AOF 和 RDB 各自优势。
3.2	2015-5-6
3.0	2015-4-7	添加 Redis 的分布式实现 Redis Cluster
2.8	2013-11-22	2.8.x 共 24 个版本。Redis Sentinel 第二版生产已可用。
2.6	2012	2.6.x 共 17 个版本。服务端支持 Lua 脚本。
1.0	2010

说明：

表格 reids 消息队列的演变

版本	原理	优点	不足
1.0	list，先进先出的队列。应用 A 可以通过 lpush 写入消息，应用 B 通过 rpop 从队列中读取消息，每个消息只会被读取一次，而且是按照 lpush 写入的顺序读到。	1. 模型简单，和使用本地 list 基本相同，适配容易。 2. 通过 brpop 做到消息处理的实时性。 3. 通过 rpoplpush 来联动 2 个 list，可以做到消息先消费后确认，避免消费者应用异常情况下消息丢失。	消息只能被消费一次，缺乏广播机制
2.0	pubsub	1. 消息具备广播能力 2. psubscribe 能按字符串通配符匹配，给予了业务逻辑的灵活性 3. 能订阅特定 key 或特定命令的系统消息	1. Redis 异常、客户端断连都会导致消息丢失。 2. 消息缺乏堆积能力，不能削峰填谷。推送的方式缺乏背压机制，没有考虑消费者处理能力，推送的消息超过消费者处理能力后可能导致消息丢失或服务异常。
5.0 stream	stream 数据类型	1. 在成本、功能上做了很多改进，支持了紧凑的存储小消息、具备广播能力、消费者能水平扩容、具备背压机制。 2. 通过 ack 机制保证了 Redis 服务端正常情况下消息至少被处理一次的能力。	1.内存型消息队列，数据堆积成本高 2. Redis 本身 rpo>0，故障恢复可能会丢数据，所以 stream 在 Redis 发生故障恢复后也不能保证消息至少被消费一次。
5.0 Tair	Tair 持久内存。	1. 引入了 AEP 作为存储介质，目前 Tair 持久内存版价格是社区版的 70%。 2. 保证了数据的实时持久化，并且通过半同步技术保证了 HA 不丢数据，大多数情况下做到消息不丢失（备库故障或主备网络异常时会降级为异步同步，优先保障可用性），消息至少被消费一次或仅被消费一次。

消息队列主要是为了解决 3 类问题，应用模块的解耦、消息的异步化、削峰填谷。目前主流的消息队列都能满足这些需求，所以在实际选型时还会考虑一些特殊的功能是否满足，产品的性能如何，具体业务场景下的成本怎么样，开发的复杂度等。

Redis 的消息队列功能并不是最全面的，它不希望做成一个大而全的产品，而是做一个小而美的产品，服务好一部分用户在某些场景下的需求。目前用户 选型 Redis 作为消息队列服务的原因，主要有 Redis 在相同成本下吞吐更高、Redis 的延时更低、应用需要一个消息服务但又不想额外引入一堆依赖 等。