Redis 6是有史以来改变最大的Redis版本，因此即使稳定，也要小心处理，并在投入生产之前对其进行测试，以进行工作量测试。到目前为止，我们从未发现重大问题，但请务必小心。在收集错误报告时，我们将准备尽快发布Redis 6.0.1。
变化如下：
除了稳定性之外，RC1和今天之间还有什么变化？
1.在某些方面对客户端缓存进行了重新设计，尤其是放弃了缓存插槽方法，而只使用键名。在分析了替代方案之后，在其他Redis核心团队成员的帮助下，这种方法最终看起来更好。除此之外，尤其是“广播模式”，我相信它将成为该功能最流行的使用模式之一。
使用广播时，服务器不再尝试记住每个客户端请求的密钥。相反，客户端订阅密钥前缀：每当与该前缀匹配的密钥被修改时，它们就会收到通知。这意味着可广播更多消息（但仅适用于选定的前缀），但服务器端无需进行任何内存操作。此外，现在支持选择加入/退出模式，因此，对于不使用广播模式的客户端，可以将其将缓存的内容准确告知服务器，以减少无效消息的数量。从根本上说，现在该功能在需要低内存模式和需要选择性（低带宽）模式时都更好。
2.这是许多用户的旧请求。现在，Redis支持一种模式，用于复制的RDB文件会在不再有用时立即删除。在某些环境中，最好不要将数据存储在磁盘上，而要存储在内存中。
3. ACL在某些方面更好。首先，有一个新的ACL LOG命令，该命令允许查看所有违反ACL的客户端，访问不应该访问的命令，不应该访问的密钥或尝试失败的身份验证。该日志实际上位于内存中，因此每个外部代理都可以调用“ ACL LOG”以查看发生了什么。这对于调试ACL问题非常有用。
但是我的首选功能是重新实现ACL GENPASS。现在，它使用基于SHA256的HMAC，并接受一个可选参数来告诉服务器要生成多少位不可猜测的伪随机字符串。Redis在启动时从/ dev / urandom获得内部密钥，然后在计数器模式下使用HMAC来生成其他随机数：这样，您可以滥用API，并在每次需要时调用它，因为它将非常快。是否想为您的应用程序生成无法猜测的会话ID？只需致电ACL GENPASS。依此类推。
4.现在，对PSYNC2（复制协议）进行了改进。Redis现在将能够修整协议中的最终PING，从而能够更频繁地进行部分重新同步，从而使副本和母版更有可能找到共同的偏移。
5.带有超时的Redis命令现在要好得多：不仅BLPOP和其他以前接受秒的命令现在都能接受十进制数字，而且实际分辨率得到了改进，以使其永远不会比当前的“ HZ”值更糟，不管客户端连接的数量是多少。
6. RDB文件现在可以更快地加载。根据文件的实际组成（较大或较小的值），您可以期望获得20/30％的改进。现在，当有许多客户端连接时，INFO也更快，这是一个长期存在的问题，现在终于消失了。
7.我们有一个新命令STRALGO，它实现了复杂的字符串算法。到目前为止，唯一实现的方法是LCS（最长的公共子序列），LCS是一种重要算法，用于比较冠状病毒的RNA（通常比较其他生物的DNA和RNA）。冠状病毒这件事太大，Redis内部需要保留一些痕迹。