Redis 6.0 稳定版发布，支持多线程 IO

五一期间，Redis 6.0.0 稳定版（GA）终于发布，Redis 6.0 最终的发布一共经历了四个 RC（Release Candidate）版，从第一个候选版本的发布到一个稳定版本前后经历了大概四个半月（Redis 6.0 RC1 于 2019-12-19 发布）。Redis 6 是 Redis 有史以来最大的版本，虽然现在发布了 GA 版，但是在将它投入生产之前仍然需要谨慎。本文将介绍 Redis 6.0 RC1 到 GA 版本除稳定性相关之外的新功能或改进。

客户端缓存进行了重新设计

Redis 6.0 RC1 到 GA 版本，Redis 客户端缓存在某些方面进行了重新设计，特别是放弃了缓存槽（caching slot）方法而只使用 key 的名称。在分析了备选方案之后，在其他 Redis 核心团队成员的帮助下，这种方法最终看起来更好。

客户端缓存重新设计中引入了广播模式（broadcasting mode）。在使用广播模式时，服务器不再尝试记住每个客户端请求的 key。取而代之的是，客户订阅 key 的前缀：每次修改匹配前缀的 key 时，这些订阅的客户端都会收到通知。这意味着会产生更多的消息（仅适用于匹配的前缀），但服务器端无需进行任何内存操作。

用于复制的 RDB 文件如果不再有用，它将立即被删除

现在，Redis 支持一种模式，就是用于复制的 RDB 文件如果不再有用，它将立即被删除，这个需求是大家很早之前就非常期待的。不过，在某些环境中，最好不要将数据放在磁盘上，而只放在内存中。

ACL 有所提升

ACL在某些方面做的更好。首先，Redis 6.0 有一个新的 ACL LOG 命令，该命令允许查看所有违反 ACL 的客户端，访问不应该访问的命令，不应该访问的 key 或尝试失败的身份验证。这些日志实际上是在内存中，因此每个外部代理都可以调用 ACL LOG 来查看发生了什么，这对于调试 ACL 问题非常有用。

PSYNC2 复制协议进行了改进

复制协议 PSYNC2 现在得到了改进。Redis 将能够更频繁地部分重新同步，因为它能够修整协议中的最终 PING，从而使副本和主副本更有可能找到一个公共的偏移量。

带有超时的 Redis 命令现在要好用得多

除了 BLPOP 命令，其他用于接受秒的命令现在都接受十进制数字，而且实际分辨率也得到了改进，以使其永远不会比当前的“HZ”值更差，因为其不管连接客户机的数量。

RDB文件现在加载速度更快了

Redis 6.0，RDB 文件的加载速度比之前变得更快了。根据文件的实际组成（较大或较小的值），大概可以获得 20-30％的改进。除此之外，INFO 也变得更快了，当有许多客户端连接时，这会消耗很多时间，不过现在终于消失了。

新的 STRALGO 命令

STRALGO 实现了复杂的字符串算法。目前唯一实现的是 LCS（最长的公共子序列），它是一种重要算法，用于比较冠状病毒的RNA (以及其他生物的DNA和RNA)。

支持多线程 IO

众所周知，Redis 在过去一直都是用单线程模型来处理数据的。但是对于单线程 Redis 来说，性能瓶颈主要在于网络的 IO 消耗, 所以如果采用多线程 IO，优化的方向主要有以下两点：

提高网络 IO 性能，典型的实现像使用 DPDK 来替代内核网络栈的方式；使用多线程充分利用多核，典型的实现像 Memcached。从 Redis 6.0 RC1 起，Redis 提供了可选的多线程模型，以此来满足不同用户的需求。国外有同学对比了 Redis 多线程和单线程的 SET 和 GET 性能，

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

从上图可以看出，多线程 IO 的 Redis 版本在 SET 和 GET 的性能确实比单线程有所提高。

好了，上面就是 Redis 6.0 相对于 6.0 RC1 的新功能。不过截止到本文编写时，Redis 已经发布了 6.0.1 版本，这个版本主要是解决一些小的 bug，具体参见 Redis 6.0 release notes。

本文参考 Redis 6.0 Release Note^[1]

Redis 6.0.0 GA is out!^[2]