快速的未来即将出现在你的城市中的某个活动中。
加入我们，了解发布的 Redis
共享
就在不久之前——项目 12 周年庆前四天，我们发布了 Redis 6.2 的通用可用版本。尽管“仅仅”是另一个小型的开源 Redis 版本，但版本 6.2 代表着 Redis 开源软件项目的一个重要里程碑。
新版本引入了数十个新命令和现有命令的扩展。除了性能和内存优化之外，它还受到较旧操作系统支持。它展示了 Redis 项目开发的新管理原则，并颠覆了多个历史决策。虽然所有这些改进都很棒，但还不足以让 Redis 6.2 成为一项重大事件。然而，新版本的 Redis 实际上是一件非常重大的事情。
这要归功于Redis 社区的积极参与，这也是我愿意将 Redis 6.2 称为“社区版本”的原因，尽管并不是通常意义上的版本。
请允许我解释一下。
除非你一直与世隔绝，否则你可能已经知道去年 antirez（Redis 创造者 Salvatore Sanfilippo）退出了项目的维护，并且我们采用了新的治理模型。该项目现在由Redis 核心团队领导，团队成员包括来自亚马逊网络服务公司的 Madelyn Olson、来自阿里云的赵昭以及 Redis 的 Yossi Gottlieb、Oran Agra 和我自己。
在经过一段时间的重新定位之后，核心团队一致认为，该项目的社区是 Redis 最重要的资产。我们作为 Redis 维护者的集体能力，将仅对我们为成员提供的价值有用。该团队坚信，该项目的长期价值和可持续性取决于开发人员和用户之间的开放、透明和全双工通信和合作。毕竟，用户也是开发人员和来自各行各业的技术人员，他们非常关心 Redis。
因此，该团队在线上坐下来（甚至在全球大流行之前，因为我们分布在世界各地），并开始计划我们的下一步工作。有无数需要关注的任务：需要分类的问题、需要复现和消除的错误、需要实施的改进和优化、需要审核和合并的请求、需要设计和开发的功能、需要实现的愿望等等。待办事项清单又长又艰巨。
为了让 Redis 真正有机会向前发展，我们需要来自更大 Redis 社区的帮助。我很高兴地报告说，有超过 35 位开发人员（不包括核心团队）为 Redis 6.2 的制作贡献了脑力循环。虽然我们似乎做对了某些事，但我们希望看到更多社区成员为 Redis 做出贡献。
为了能够尽量发挥 Redis 社区的参与作用，我们还花了时间制定了指导我们活动的原则。更新后版本的 Redis 发行周期 体现了这些原则的一部分，并为发行时间表、向后兼容性和支持设定了指导方针。为了遵守此“正式义务”并切实履行，我们根据数项标准整理了 Redis 6.2 的内容。
从技术角度来说，像这样的小幅版本更新允许我们添加新功能，也可以修改现有行为。所以，在着手认真开发 Redis 7 之前，Redis 6.2 是执行这些更改的完美媒介。无论社区成员提出的问题创建日期或开启/关闭状态如何，6.2 版本同样给了我们一个机会来解决这些问题。发行说明 详细说明了所有更改，所以我将重点介绍几个关键示例。
社区成员心声受到明确关注的一个地方是放宽 Redis 的编译要求（请参阅 PR #7707）。在这方面，Redis 6.0 做出了重大更改，要求编译器支持 C11 和原子变量。因为这些特性只能在较新版本的操作系统中使用，所以许多社区成员都感到失望，并无法使用 Redis。社区（请参阅 问题 #7509 及其副本）的强烈反弹反馈是我们决定解决此问题的全部动力。更重要的是，是社区，具体来说是王元（在 Twitter 上的 @ShooterIT）在这个案例中，提出了此修复程序。这类社区贡献催生了 Redis 6.2 的许多新功能。
除了常规修复和优化外，Redis 6.2 还带来了 25 个以上的新命令。为了提高项目的可用性，这些新命令基本上是从前几年开始由大量成员要求的小功能。出于这样或那样的原因，尽管这些扩展功能具有真正的价值，但却从未纳入 Redis 中。例如，此发行版解决的最早的问题是 Redis 长达 11 年没有使用 ZUNION 和 ZINTER 的问题。在这个案例中，解决问题不仅仅是为了 API 的完整性，主要还是为了解决只有这些命令才能满足的痛点，即返回结果而不是存储结果（而新命令的现有对应命令 ZUNIONSTORE 和 ZINTERSTORE 则会存储结果）。
还有 GETEX 命令，首次提出于 2015 年，它在读取值时设置其生存时间；一直都没有 HRANDFIELD 和 ZRANDMEMBER 命令，它们从散列和排序集合数据结构中返回随机值；SMISMEMBER 和 ZMSCORE 命令是针对希望通过一次调用查询多个值的泛型 aficionados；泛型 LMOVE 命令旨在取代 RPOPLPUSH 并用在两种列表数据结构的末端之间移动元素的所有可想而知的方面来补充其功能；边界框 GEOSEARCH 查询；仅举几例。
Streams API（在 Redis 5.0 中引入）也受到了关注并得到了改进。新增功能让它更容易使用流，范围从 排他范围查询，通过空闲时间过滤延迟消息 到 通过最小 ID (MINID 策略) 修整，还有 XAUTOCLAIM 命令，它应让任何消费者组用户的心跳跃起来，因为它允许用户使用一个命令来回收处理中丢失的消息。
这篇文章不需要变成 Redis 6.2 发布说明 的演练。更重要的是，此版本充分说明了 Redis 社区对该项目的承诺以及 Redis 开发的势头。作为一个变成了悲观主义者的乐观主义者，我一直小心翼翼地预测 Redis 社区将如何回应过去一年的所有项目更改。因此，目睹社区参与的程度以及我们能够将许多有用的改进纳入 Redis 6.2 的事实让我感到惊喜。
非常感谢社区开发人员和整个全球 Redis 社区付出的所有辛勤劳动。现在是时候继续创建下一个版本了！
有兴趣了解有关 Redis 6.2 的更多信息吗？我们将在我们的年度实时数据大会——4 月 20-21 日RedisConf 2021 上讨论此版本以及所有有关 Redis 的内容。
