我刚从巴黎回来，DotScale 2015 是一场非常有意思的会议。出发前，我一直在 unstable 分支上处理 Sentinel 相关的工作：主要内容是连接共享。简而言之，就是让少量的 Sentinel 能够扩展，去监控大量的 master。出发前以及回来后，我一直在尝试“敲定”一组将作为 Redis 3.2 基础的功能。接下来的几周我将集中精力开发这些功能，所以我想尽快和大家分享这份清单。

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

Bloom filters(布隆过滤器)：3.2 版本中我们将加入 Bloom filters。我还不确定它会像 HyperLogLog 那样作为 String 类型的一项功能来实现，但更有可能作为一种新的特殊类型，因为我希望提供一些非平凡的语义，而作为新类型会更容易实现。关于 Bloom filters 我有很多设计想法，但我比较确定的是，希望能通过 API 来控制精度/空间的权衡，也许不是以指定比特数和所用哈希函数数量这种底层方式，而是以更高层的方式。我希望在这个 API 中实现的另一点，是让 Bloom filter 能够自我自动去污染（比如使用多个轮换的过滤器或类似机制）。我会阅读所有现有的文献再决定具体怎么做，但我们肯定会在 3.2 中加入这一功能。

Memory PRs：有来自 RedisLabs 的两个重要的 PR，用于改进 Redis 的内存使用。我们会将它们全部合并。

Memory introspection command(内存自检命令)：一个提供内存信息的命令，就像 LATENCY 命令之于延迟，这个命令之于内存使用。比如提示内存消耗在哪里，是否只是由于过去的峰值内存使用导致 RSS 偏高，提示客户端输出缓冲区所占用的内存量，必要时调整哈希表大小以节省内存的能力，等等。

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

新的 List 类型操作：一些 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 版本，因为有一段时间我们更多地关注了 Redis 的运维方面。

关于 ETA，工作将于周一开始，我希望不会超过 9 月底，届时将推出第一个 RC。一旦进入 RC 阶段，RC -> Stable 的过渡时间并未确定，它取决于严重缺陷的报告时间。一旦连续几周都没有人再发现严重问题，我们就会发布稳定版。

我后续会针对上面列出的各个条目发布新的博文，比如关于 Geo hashing 的事情、Bloom filter 的最终实现和 API 描述等等。

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