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]


猜你喜欢

转载自blog.51cto.com/15127525/2686442