Redis 社区的发展与国内开发者的贡献
——赵钊
阿里云数据库产品事业部 高级技术专家
Redis 诞生于 2009 年，发展至今已经经历了 7 个大版本，每个大版本都有很多新的特性，比如 3.0 版本支持了集群模式；4.0 版本开发了 lazy-free、PSYNC2，解决了大 KEY 删除以及复杂场景下的数据同步问题；5.0 版本新增了 Stream 数据结构，让 Redis 具备了功能比较完整的轻量级消息队列的能力； 6.0 版本发布了很多企业级特性，比如 Threader-IO 支持了多线程、 TLS 数据传输加密以及 ACL 权限控制等。
新特性不断提升了 Redis 的性能、安全性以及企业级能力，也需要大量代码开发。 Redis 的代码从一开始的 2w+ 行，到现在 7.0 版本 15w+ 行，如果只靠固定开发团队的开发，显然无法支撑如此巨大的工作量。成功的开源产品需要有强大的社区作为基础，这也是开源的精神。
阿里云从 Redis 4.0 开始深度参与到社区的开发中，也向社区贡献了大量代码，比如 PSYNC2、pipeline 的优化、数据一致性的增强以及其他实用功能，比如基于 LFU 的热点 KEY 查询功能等。本次的 7.0 版本又贡献了 Multi-part AOF 等比较核心的重量级特性。
Redis 的原作者Salvatore Sanfilippo 自 6.0 之后宣布不再维护 Redis 。而后社区成立了 core team 组织来继续社区的日常维护和开发工作。目前阿里云在 Redis 社区有一名 core team member (核心维护者)，两名 contributor (核心贡献者)，可以说是除原作者和Redis Labs 以外对社区贡献最大的组织，也见证了国内 Redis 用户的快速增长。
阿里云与 Redis 社区的深度合作也逐渐吸引了很多来自国内的开发者参与到 Redis 社区的建设中。尤其是在 Redis core team 成立之后，社区工作人员也从单线程变成多线程，对于日常 issue 和 PR 的处理速度大幅提升，社区活跃度也显著提升。
本次 7.0 的发布，很多来自中国的开发者贡献了很多核心 feature ，比如 global replication buffer 可以解决主备同步间备库消耗的内存问题，还有底层编码从 Ziplist 向 listpack 转换，解决了 Ziplist 编码中 cascade update 的问题, multi-part AOF 结合 AOF annutation 即可实现数据按时间点恢复，解决数据丢失的问题。
我们会继续和 Redis 社区进行深度合作，推进 Redis 社区的发展， PSYNC3、cluster v2、Thread command、Slot migration 等新 feature 也已提上日程。
Redis 已经不是简单的缓存，它正在向真正的内存数据库发展。它也是目前国内用户使用量规模最大的 NoSQL 数据库之一，并且一直处于高速发展的状态。越来越多的泛互联网行业甚至传统行业都在逐渐接纳 Redis ，用于快速高效地构建业务的应用服务。
阿里云持续对 Redis 的新版本发布快速跟进， 本次 7.0 包括之前的 6.0 版本都实现了在全球主流的云厂商之中的新版本首发。
虽然 Redis 社区发展很快，也及时进行新版本的迭代，但是国内用户对于新版本的接受速度依然较为缓慢。国外大量用户已经升级到 5.0和 6.0 版本，但国内用户依然大量使用低版本，比如4.0、3.0 甚至 2.8。而很多国内开发者贡献的 feature 很大程度上都是来自于国内用户的真实需求。
7.0 版本面世后，此前的 6.0 版本会逐渐进入低版本低维护状态，而更早的版本可能只会做一些安全漏洞上的修复甚至不再开发维护。如果业务一直跑在低版本上，肯定会出现一些稳定性和安全上的风险。
用户担心升级之后会存在兼容性的问题，导致一直在坚持使用低版本，而无法享受新版本里真正能解决需求的新特性。
新版本在各个方面都有增强，比如 Redis 4.0 的 lazy-free 功能：实现 lazy-free 之前，大 KEY 删除是非常大的痛点，可能会造成整个业务的中断或阻塞；再比如， Lua 是 Redis 支持的脚本虚拟机，但是 Lua 本身的安全问题层出不穷，社区新版本一直在对其进行安全修复，但是对于大部分低版本，社区已经放弃维护了。
很多用户担心升级到了新版本之后会存在兼容性问题，这是合理的顾虑。为了解决这个顾虑，一方面云产品会及时跟进新版本的迭代，梳理这些新版本中的 breaking change ，让用户能更好地了解，可以提早尝试来验证；另一方面，我们也在与社区积极沟通，推动社区出一些官方的兼容性验证工具，给用户更多信心，让用户能够从低版本向高版本顺利迭代。
就目前来看， Redis 对于版本的向前兼容性已经较为完善，此外，类似兼容性的问题，用户也可以直接将顾虑反馈给社区，也希望有更多国内用户能够深度参与到 Redis 社区的建设中。
一项 feature 从最开始的立项到最后交付给用户，需要经过很多阶段，比如需求评审、代码开发、过程中的讨论、 code review 以及合并发布。如果用户能够参与到整个过程，就能够及时纠正开发者对这些 feature 需求的理解偏差，避免最后开发出来的 feature 与用户需求相差过大。
举个例子， 7.0 中的 client eviction 功能，就是从阿里云上的用户需求中提炼而来。Redis 作为内存数据库，与传统的数据库略有不同，所有数据都是存放在内存中。因此内存中不仅有用户的数据，还有一些元数据以及其他额外的内存消耗，这些额外的内存消耗有时也会对用户数据内存产生影响。
阿里云向社区提出需求，并与社区合作开发完成了这个需求。目前 client eviction 对于资源管理方面来说还只是比较初级的功能，在未来我们也会持续优化，在用户数据与运行内存之间实现更好的隔离。
总的来说，我们希望来自国内的开发者和用户都能够更深度、更积极地参与到社区的建设中，也希望用户能更主动地提出需求，不仅仅局限于 API 层面增加命令，也可以包括访问接入、可观测性、数据一致性以及安全等各个方面，推进社区发展进步，也使得 Redis 能够向真正的内存数据库发展。
真实用户更多地发声，才能为社区提供更有力的支持。
