它还不是稳定版，但很快就会是，而且带来了一长串能让 Redis 对我们用户来说更实用的特性：Redis 4.0 的首个候选版（RC1）终于来了，并且大胆地直接叫作 4.0，而不是 3.4。对我来说，语义化版本那一套并不重要，我更想做的是通过版本号和版本跳跃来传达新版本到底是怎么回事，而就这一次而言，4.0 的意思就是“这版本太牛了”。

说到底，Redis 4.0 里有太多早就该有的东西，在另一个世界里，一个开发者可以像《北斗神拳》里的健次郎那样，分身成十个自己同时开写。但不管我多努力去学新的 vim 快捷键，分身这招终究不在我的技能表里。

不过好在，到了 4.0，我们总算把其中很多都做完了……下面就是几个重头特性的清单，附带一些细节和延伸阅读的线索。

1. 模块

想必你已经知道，Redis 4.0 有了模块系统，而且这个系统能做相当炫酷的事，比如实现会被 RDB/AOF 持久化的新数据类型、创建非阻塞命令等等。关键在于，这一切都是通过一套与核心完全分离的高层抽象 API 来完成的，所以你写的模块在未来的 Redis 版本里也能继续工作。利用模块，我写了 Neural Redis——一种可以直接在 Redis 内部训练的神经网络数据类型，还有很多人也在做非常有意思的东西：有用 Rust 实现的全新限流命令、基于 Redis 的图数据库、二级索引、时序模块、全文索引等等，而我的感觉是，这仅仅是个开始。

这不仅让 Redis 得以扩展、覆盖更多新领域，同时还能让核心保持精简——即便不是极简，至少也只保留对大多数用户有用、足够通用的功能。更重要的是，它还有潜力让你在很多场景下免于重写一个网络服务器，哪怕你的目标是做一个跟 Redis、数据库、缓存或 Redis 所代表的任何东西都无关的项目。也就是说，你完全可以只写一个模块来借用 Redis 的“基础设施”：协议、现成的客户端等等。所以我对它感觉很好，核心没有压力，想玩点更疯狂东西的用户也获得了自由。

2. 复制协议第二版

这在生产环境的运维角度来看会非常有用。过去某个时候，我们引入了所谓的“PSYNC”。它是一种新的主从协议，让主库和从库在连接断开后能从断点处继续同步。在此之前，主从之间复制链路的任何一次断开都会导致一次全量同步：在主库上生成 RDB 文件、传输过去、再在从库上加载——你知道这套流程是怎么回事。所以说，PSYNC 算是一次实实在在的改进。但还不够……

PSYNC 在发生故障转移时还不够好。如果一个从库被提升为主库，原来复制旧主库的那些从库就无法连接到这个新晋主库并与之进行 PSYNC：必须做一次全量重同步。这可不妙，对 Redis Cluster 来说也不友好。然而要修复这个问题，就得改动复制协议，因为我真的想确保，只要实例之间存在共同的复制历史，那么无论拓扑怎么变，部分重同步都能正常工作。

所以第一个需要改的地方，就是“链式复制”是怎么工作的，也就是从库的从库的从库……它们是怎么运作的？比如，A 是主库，我们有这样一种结构：

A —> B —> C —> D

也就是说，A 是 B 的主库，而 B 又是 C 的主库，以此类推。在 Redis 4.0 之前，情况是这样的：B 从 A 接收复制协议。复制协议通常就是一串写命令流。B 作为 C 的主库，做的事本质上就是在内部重复 A 的行为：每次写入时，它都会重新生成一份合适的复制协议再传给 C，以此类推。

而现在，B 只是把从 A 收到的数据原样转发给 C，C 也会对 D 做同样的事：既然所有下级从库现在收到的都是完全相同的字节流，它们就可以给某段历史打上“标签”，并利用标签和偏移量，在彼此有共同历史时尝试续传。

主库本身在被转为从库后，现在也能够与新主库进行 PSYNC。并且从库即使在“干净”重启后，通常也能与主库进行 PSYNC，因为 RDB 文件中现在会保存复制标签和偏移量的信息。

要让它真正稳定工作，细节要比这复杂得多，不过总的来说，重点就是——如果可以，就别再被全量重同步烦到了。而 PSYNC v2 显然在这方面做得很好。如果你对这个特性感兴趣，请试试看并告诉我反馈。

3. 缓存淘汰策略的改进

好吧，关于这个我几个月前写过一篇完整的文章：http://antirez.com/news/109。所以这里只给你个精简版。我们现在有了 LFU（Least Frequently Used，最不经常使用），而且所有其他策略也都换成了更稳健、更快、更精确的实现。所以对于缓存场景来说这是个大消息。如果你关心这些，请去读全文，里面有大量信息。

4. 非阻塞的 DEL 与 FLUSHALL/FLUSHDB

代号叫“对象的惰性释放”，但这名字对于这么酷的功能来说有点无趣。新命令叫 UNLINK，它只是在数据库中删除键的引用，而真正的内存回收则放到单独的线程里去做，所以如果你对一个大 key 用 UNLINK 而不是 DEL，服务器就不会阻塞。更棒的是，通过 FLUSHALL 和 FLUSHDB 的 ASYNC 选项，你可以对整个数据库、甚至实例里的所有数据做同样的事。配合新的 SWAPDB 命令（用于交换两个 Redis 数据库的内容），FLUSHDB ASYNC 会变得非常有意思。比如，你先在 DB 1 中填入新版本的数据，然后执行 SWAPDB 0 1，再用 FLUSHDB ASYNC 清理掉装着旧数据的数据库，然后又可以去构建更新的版本并反复操作。这在以前是不可能的，因为清空整个数据库不再会阻塞。

UNLINK 之所以没有成为 DEL 的默认行为，是有原因的。我知道一些内情……但不能说（**）。

5. RDB-AOF 混合持久化格式

可选地，如果你开启它，现在 AOF 重写会通过在 AOF 文件头部加上一个 RDB 文件来完成，这样生成和加载都更快。这在某些环境下会非常有用，但也会让 AOF 文件变得不那么直观透明，所以目前还是一个可选项。这个功能被讨论了很久，终于“上线”了。

6. 全新的 MEMORY 命令

我很喜欢它，就像当初喜欢 LATENCY DOCTOR 一样——它的出现让邮件列表里“My Redis is slow（我的 Redis 很慢）”这类抱怨的比例降到了一小部分。现在，我们在内存问题上也有同样的利器了。

127.0.0.1:6379> MEMORY DOCTOR
Hi Sam, this instance is empty or is using very little memory, my issues detector can't be used in these conditions. Please, leave for your mission on Earth and fill it with some data. The new Sam and I will be back to our programming as soon as I finished rebooting.

电影版权方可能会因为我借鉴科幻台词而起诉我，不过没关系。等我进去了，记得给我带橙子来。

MEMORY 能做的可不止这些。

127.0.0.1:6379> MEMORY HELP
1) "MEMORY USAGE <key> [SAMPLES <count>] - Estimate memory usage of key"
2) "MEMORY STATS                         - Show memory usage details"
3) "MEMORY PURGE                         - Ask the allocator to release memory"
4) "MEMORY MALLOC-STATS                  - Show allocator internal stats"

USAGE 子命令的内存占用报告会非常有用，而“STATS”提供的深度信息也同样如此。

目前这些完全没有文档，所以，祝你玩得开心，慢慢琢磨它们到底是干嘛的吧。

7. Redis Cluster 现在兼容 NAT / Docker

但这其实也是个坏消息，因为节点间通信用的“Cluster bus”二进制协议变了，所以要升级到 4.0，你需要把整个 Redis Cluster 全部重启。抱歉，我是被忽悠去做这些 NAT / Docker 修复的，请原谅我。我也尝试过做成向后兼容，但无论是轻松还是费劲的办法，都无法轻易实现，除非搞得特别别扭。

这个特性在示例 redis.conf 文件中有说明。看得出来，相比其他特性，我对这个特性没那么兴奋吧？

好吧……我想主要就是这些了。如果你还想看，也可以去这里读发布说明：https://raw.githubusercontent.com/antirez/redis/4.0/00-RELEASENOTES

至于何时会变成稳定版，按惯例还是未知：我计划每 2 到 4 周左右发布一个新的 RC。当 bug 无论从严重程度还是被报告的频率来看都显著减少时，就是发布 Redis 4.0 正式版的时候了。不过还有大量文档要更新，所以我还有很多事要做。

非常感谢所有为这个版本做出贡献的人：很多人都做出了重要贡献。在上面的发布说明里，有所有提交的列表，你可以浏览查看提交者的名字。

感谢 Redis 社区和 Redis Labs 让这一切成为可能，但尤其要感谢所有使用 Redis 并在日常问题中把它用好、真正把事做成的开发者们，因为这才是全部的意义所在——除了写代码时的乐趣之外。

附言：最快获取新代码的方式是从 GitHub 上拉取 '4.0' 分支。仓库一如既往是 antirez/redis。

** 关于 UNLINK 为何没有成为 DEL 的默认行为，更多信息请查看 https://news.ycombinator.com/item?id=13091370。