Redis 8 来了 — 并且它是开源的
了解更多
分享
不久前——就在该项目迎来 12 岁生日的前四天——我们发布了 Redis 6.2 的正式版本。尽管它“只是”另一个 Redis 开源软件的次要版本，但 6.2 版本对于 Redis 开源软件项目来说代表着一个重要的里程碑。
新版本引入了数十个新命令并扩展了现有命令。除了性能和内存优化外，它还支持较旧的操作系统。它还展示了 Redis 项目开发的新管理原则，并撤销了一些历史性决定。虽然所有这些改进都很棒，但它们不足以让 Redis 6.2 成为一个重大事件。然而，Redis 的新版本实际上意义重大。
这归因于 Redis 社区的深度参与，这也是为什么我喜欢将 Redis 6.2 称为“社区版”，尽管并非采用该术语的通常含义。
请允许我解释一下。
除非您一直不问世事，否则您可能已经知道，去年 antirez（Redis 创建者 Salvatore Sanfilippo）退出了项目维护，并且我们采用了新的治理模式。该项目现在由 Redis 核心团队领导，团队成员包括来自 Amazon Web Services 的 Madelyn Olson、来自 Alibaba Cloud 的 Zhao Zhao，以及来自 Redis 的 Yossi Gottlieb、Oran Agra 和我本人。
经过短暂的调整期后，核心团队一致认为项目社区是 Redis 最重要的资产。作为 Redis 维护者的集体卓越表现，其价值仅取决于我们为社区成员提供的价值。团队坚信，项目的长期价值和可持续性取决于开发者和用户之间的开放、透明和全双工沟通与合作。毕竟，用户也是各行各业关心 Redis 的开发者和技术人员。
因此，团队在线上坐下来（甚至在疫情之前，因为我们分布在全球各地），开始规划我们的下一步行动。有无数的任务需要关注：分流问题、复现和解决 bug、实施改进和优化、审查和合并拉取请求、设计和开发新功能、响应和满足愿望等等。待办事项列表过去是，现在仍然很长且充满雄心壮志。
为了真正有机会推动 Redis 向前发展，我们需要更广泛的 Redis 社区的帮助。我很高兴地报告，超过 35 位开发者（不包括核心团队成员）在 Redis 6.2 的开发过程中贡献了他们的智慧。虽然看起来我们做得不错，但我们非常希望能有更多社区成员为 Redis 做出贡献。
为了充分利用 Redis 社区的参与，我们还花费时间制定了一些指导我们活动的原则。Redis 发布周期的更新定义涵盖了其中一些原则，并设定了发布时间表、向后兼容性和支持的指导方针。为了遵守这一“正式义务”并使其生效，我们根据几个标准汇总了 Redis 6.2 的内容。
从技术角度来看，这样的次要版本允许我们添加新功能以及修改现有行为。因此，Redis 6.2 是我们在认真投入 Redis 7 工作之前进行这些更改的完美载体。6.2 版本还给了我们机会来解决社区关注的重要问题，无论其创建日期和开放/关闭状态如何。发行说明详细介绍了所有更改，因此我将重点介绍几个关键示例
社区声音被响亮而清晰地听到的一个地方是放宽了编译 Redis 的要求（参见 PR #7707）。在这方面，Redis 6.0 做出了重大改变，要求编译器支持 C11 和原子操作。由于这些特性只在较新版本的操作系统中可用，此举让许多社区成员感到沮丧并无法使用 Redis。来自社区的反馈（参见 issue #7509 及其重复项）是我们解决此问题所需的全部动力。更棒的是，正是社区，特别是 Wang Yuan（Twitter 上的 @ShooterIT），在这种情况下贡献了修复。正是这些类型的社区贡献促成了 Redis 6.2 的许多新特性。（此句中的 backlash 已被 feedback 替换）
除了常规的修复和优化之外，Redis 6.2 还带来了超过 25 个新命令。这些大多是多年来大量社区成员为了提高项目可用性而请求的小功能。由于这样或那样的原因，这些扩展尽管提供了实际价值，却从未进入 Redis。例如，此版本解决的最老问题是 ZUNION 和 ZINTER 在 Redis 中长达 11 年的缺失。在这种情况下，解决这个问题不仅仅是为了 API 的完整性，主要是为了解决只有这些命令才能解决的痛点，即返回结果而不是存储结果（这正是新命令对应的现有命令 ZUNIONSTORE 和 ZINTERSTORE 所做的事情）。
还有 GETEX 命令，该命令于 2015 年首次提出，它在读取值的同时设置其存活时间 (TTL)；以及那些本应从一开始就存在的 HRANDFIELD 和 ZRANDMEMBER 命令，它们返回 Hash 和 Sorted Set 数据结构中的随机值；SMISMEMBER 和 ZMSCORE 命令适用于希望一次调用查询多个值的可变参数爱好者；通用的 LMOVE 命令旨在取代 RPOPLPUSH 并通过所有可想象的方式在两个 List 数据结构的端点之间移动元素来补充其功能；以及边界框 GEOSEARCH 查询；等等。
Redis 5.0 中引入的 Streams API 也受到了关注和改进。新增功能使流的使用更加简单方便，涵盖了从排他范围查询、按空闲时间过滤待处理消息、按最小 ID 进行裁剪（MINID 策略）到 XAUTOCLAIM 命令，该命令允许用户通过单个命令重新获取处理过程中丢失的消息，这应该会让任何消费者组用户感到高兴。
本文无需详细讲解 Redis 6.2 的发行说明。更重要的是，此版本充分体现了 Redis 社区对项目的投入以及 Redis 开发的势头。作为一个从乐观主义者转变为悲观主义者的人，我曾对 Redis 社区将如何回应过去一年项目的所有变化持谨慎态度。因此，我很惊喜地看到了社区的参与程度以及我们在 Redis 6.2 中实现的许多有益改进。
非常感谢社区开发者和整个全球 Redis 社区付出的辛勤工作。现在是时候着手创建下一个版本了！
有兴趣了解更多关于 Redis 6.2 的信息吗？我们将在 RedisConf 2021（我们一年一度的实时数据大会，将于 4 月 20-21 日在线上举行）上讨论该版本和所有关于 Redis 的事情。
