我刚从巴黎回来，DotScale 2015 是一场非常有意思的大会。出发前我一直在不稳定分支上从事 Sentinel 相关的工作，主要是连接共享方面的。简单来说，就是让少量的 Sentinel 能够扩展，以监控大量的主节点。出发前和回来后，我一直在努力“敲定”一组将作为 Redis 3.2 基础的功能特性。接下来几周我将集中精力开发这些功能，所以我想尽快把这份清单分享给大家。

Geo 哈希 API：这项工作源自 Ardb——它最初是 Redis 的一个分支（https://github.com/yinqiwen/ardb），后来由 Matt Stancliff 提取、改进并移植到了 Redis（https://matt.sh/redis-geo）。开源很酷，不是吗？目前的代码需要重构，因为它与有序集合的实现存在部分重复。我也有可能会对 API 做一些改动，目前还不确定，如果有需要修正的地方，我就会去改。但归根结底：这是一个很棒的功能，现在 Matt 已经不再为 Redis 贡献代码，失去这项成果的风险很大，所以我会把它作为 Redis 3.2 的首要任务，投入精力进行重构、审查和合并。我认为这是对 Redis API 一个非常令人兴奋的补充。

布隆过滤器：3.2 版本中我们会加入布隆过滤器。我还不确定它是会像 HyperLogLog 那样作为 String 类型的一项功能来实现，但更有可能是一种全新的特殊类型，因为我想要的是一些更复杂的语义，作为新类型会更容易实现。关于布隆过滤器我有很多设计想法，但比较确定的一点是，我希望能通过 API 来控制精度与空间之间的权衡，或许不是以指定位数和哈希函数数量这种底层方式，而是以更上层、更抽象的方式。我希望在这个 API 中实现的另一个功能，是让布隆过滤器能够自动“去污染”（比如通过多个轮换的过滤器等方式）。我会阅读所有相关文献再做决定，但这个功能一定会进入 3.2。

内存相关的 PR：RedisLabs 提交了两个用于改善 Redis 内存使用的重要 PR。我们会将它们全部合并。

内存自检命令：一个提供内存信息的命令，类似于 LATENCY 命令，但针对的是内存使用情况。会提示内存消耗在哪里，是否只是因为历史峰值导致 RSS 偏高，提示客户端输出缓冲区所占用的内存量，以及在需要时调整哈希表大小以节省内存的能力等等。

Redis Cluster 的多数据中心支持。这可能只是一个针对 Cluster 从节点的“静态”选项，让它们在主节点故障时不参与晋升。这样一来，通过使用 CLUSTER FAILOVER TAKEOVER，就可以在少数派分区中将所有从节点提升为主节点。

列表类型的新操作：一些 O(1) 的列表操作，比如 LMERGE，以及一些 O(N) 的操作——但通常 N 会非常小，所以大多数情况下实际也是 O(1) 操作，例如将 N 个元素从一个列表移动到另一个列表的操作。

AOF 安全性功能：https://github.com/antirez/redis/pull/2574

AOF 重写可选择使用 RDB 前导，这样重写 AOF 以及在启动时重新加载内容的速度会更快。

SPOP 的 COUNT 选项（已实现，3.2 将是首个包含它的稳定版本）

Redis Cluster 的 redis-trib rebalance 命令，用于自动重新哈希键，以实现节点间更均衡的内存使用。

一些原本计划在 3.2 中发布的功能，因为足够安全已被移植到了 3.0。最近的一个例子是支持 NX 和 XX 等选项的 ZADD。总的来说，Redis 3.2 中可能还会为现有类型增加一些新命令。这基本上是一个旨在让那些希望 API 更丰富的用户满意的版本，因为有一段时间我们更多地关注了 Redis 的运维层面。

关于发布时间，预计工作将于周一开始，我希望能在九月底之前完成，届时将推出第一个 RC 版本。一旦进入 RC 阶段，RC 到稳定版的过渡时间则没有固定计划，这取决于严重缺陷的报告情况。如果连续几周都没有再发现严重问题，我们就会发布稳定版。

后续我会针对上面列出的每一项分别撰写新的博文，比如关于 Geo 哈希、布隆过滤器的最终实现和 API 介绍等等。

与此同时，尽情享受 Redis 3.0 吧！