我剛從巴黎回來，DotScale 2015 是場非常精彩的研討會。出發前，我一直在 unstable 分支上處理 Sentinel，主要工作是關於連線共享。簡而言之，就是讓少數幾個 Sentinel 能夠擴展，以監控眾多的 master。出發前以及回來後，我試著「確定」了一組將作為 Redis 3.2 基礎的功能。接下來幾週我將專注於開發這些功能，所以我想盡快和大家分享這份清單。

Geo hashing API(地理雜湊 API)：這項工作源自 Ardb，它原本是 Redis 的一個 fork（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 用以改善 Redis 記憶體使用量的重要 PR，我們會將兩者皆合併。

Memory introspection command：一個提供記憶體資訊的指令，就像 LATENCY 指令之於延遲資訊，但這是針對記憶體使用量。它會提示記憶體的消耗位置、是否只是因為過去的記憶體使用高峰而導致常駐記憶體（RSS）偏高、提示客戶端輸出緩衝區所使用的記憶體量、必要時重新調整雜湊表大小以節省記憶體的能力等等。

對 Redis Cluster 的多資料中心支援。這可能只會是 Cluster slaves 的一個「static」選項，讓它們在 master 失效時不參與晉升。如此一來，使用 CLUSTER FAILOVER TAKEOVER 就能在少數分割區中晉升所有的 slaves。

新 List 型別操作：一些 O(1) 的 List 操作，例如 LMERGE，以及 O(N) 操作，這些操作通常會在 N 非常小的情況下使用，因此大多數時候實際上是 O(1) 操作，例如將 N 個元素從一個 List 移至另一個 List 的操作。

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 的維運層面。

關於預計時程，工作將於週一開始，我希望能在九月底前完成，屆時將推出第一個 RC。一旦進入 RC 階段，RC 轉為 Stable 所需的時間並未排定，它取決於重大錯誤的回報時間。一旦數週內都沒有人發現更嚴重的問題，我們就會進入穩定版。

我會針對上面列出的各個項目，後續發表新的部落格文章，例如關於 Geo hashing 的部分、bloom filter 最終的實作與 API 說明等等。

在此期間，盡情享受 Redis 3.0 吧！