在Redis叢集技術上，你不可錯過的四大內建者

前陣子有幸現場聆聽了雲栖大會Redis專場的分享，可以說是不虛此行：會上見到了Redis之父Salvatore Sanfilippo，Redis labs CTO Yiftach Shoolman，Redisson 聯合創始人 Jack Gu，Codis 作者王乃峥以及阿裡雲Redis團隊的衆多技術大牛。演講的内容幹貨也很多，這裡稍作總結跟大家分享。

一、阿裡雲ApsaraCache

先介紹一下阿裡雲開源的飛天緩存ApsaraCache項目(https://github.com/alibaba/ApsaraCache)，這是在社群2.8版基礎上開始維護的分支，并backport了部分3.0分支的功能。

那與社群版Redis相比有哪些特點呢？阿裡雲技術專家白宸在演講中做了很詳細的介紹，先從架構上有一個整體的認識：

架構圖

特點：

與Redis相比，ApsaraCache的顯著特點是與場景有關，與資料規模無關。其技術特點和優勢，主要表現在：

• 災備深度加強，可以重構核心同步機制，解決了原生核心在弱網條件下容易複制中斷導緻的全量同步問題。（作者注：社群版2.8引入psync機制在一定程度上解決了類似問題）
• 相容Memcached協定，能支援雙副本的Memcached，資料可持久化，提供更可靠的Memcached服務。（作者注：Memcached是一種in-memory KV 存儲，執行個體重新開機資料丢失，極容易導緻“雪崩”）
• 短連結優化，使短連結場景下性能提升30%以上，對PHP短連接配接應用居多的應用提升效果明顯。
• AOF強化，避免AOF Rewrite頻繁造成的主機穩定性瓶頸，且能精确到秒級的按時間點恢複。（作者注：單機上部署多個執行個體如同時觸發bgsave或bgrewriteaof操作，在copy-on-write機制作用下，非常可能會導緻伺服器記憶體很快耗盡，進而導緻Redis服務崩潰，微網誌也作了類似的改造，廢棄掉了aof重寫機制，增加了定時持久化操作的配置項cronsave，相當于一個定時任務）
• 獨特的熱更新機制，增加了熱更新的功能，能夠在3ms内完成一個執行個體的熱更新。（作者注：這個功能可以避免由于更新造成的業務影響）
• 執行個體的可用性檢測等。

除了上面的，在Redis Cluster上面，阿裡雲團隊也做了很多的工作，比如：

1. 叢集支援select、pub/sub、blpop的能力；
2. 對熱key的感覺和處理；
3. 讀寫分離；
4. 多資料中心的災備以及穩定可靠的基于aof log的複制等。

二、Redis Enterprise

來自Redis labs的聯合創始人&CTO YiftachShoolman先生在會上提到的一點非常有意思，根據similarweb.com的統計，在Redis使用者TOP5中，中國排第一，遠超第二名美國，可見國内Redis使用者群體之多。

另外，他還給大家普及了一下Redis的基礎，比如Redis的資料結構。

Redis modules 這個功能，相信大家不陌生吧？就是Redis labs這個公司所提出的，并且在此基礎上開發了很多的擴充功能，其中本文作者就翻譯過其中幾篇介紹的文章，比如有：ReJSON、

Redis-ML

、RediSearch等。

連結：

• http://www.sohu.com/a/155063241_99937638
• http://www.sohu.com/a/155010567_99937638
• http://www.sohu.com/a/154690419_99937638

還講了很多關于Redis labs産品相關的内容，最後講到了Redis 企業版的優勢，聽上去他們真的做了很多的事情，有很多值得學習地方。如下：

三、Codis叢集演化和Redis異步遷移

1、Codis叢集演化

Codis作者spinlock9首先分享了Codis出現的背景和開發中的挑戰，他們也跟大多公司一樣，也經曆過多次的技術選型上的疊代，也曾在Redis + Twemproxy和Redis Cluster進行過嘗試，踩過坑，比如twitter 在2015年就不再貢獻Twemproxy代碼，它最大的缺點是一個靜态的Sharding 政策，随着業務的增長也幾乎沒有辦法進行動态的擴縮容。而當時Redis Cluster也隻是推出了beta版本，對于線上的業務存在風險。故最終确定在2014年醞釀要開發Codis，15年開始Release出來，會上他介紹了開發過程需要解決的問題，比如：

• 相容所有語言的用戶端
• 能支援GB到TB級别的水準擴充能力
• 也能提供Redis同樣的高吞吐和低延遲的優勢
• 高可用等

挑戰：

Redis Cluster和Codis的特性比較：

需要特别提醒一下的是：Codis在3.2版本的時候就允許異步遷移，能夠進行平滑的擴容縮容，這是比Redis Cluster進步的地方。

架構設計：

優缺點：

特性介紹

高吞吐

• - 指令流水
• - 實作效率 + 優化GC

并發多連接配接

• - 單連接配接 – Redis
• - 多連接配接 – SSD（RocksDB）

多DB支援

• - 預設16個DB

通路控制

• - 指令黑名單
• - SessionAuth – Proxy 獨立配置
• - ProductAuth – Codis 叢集共享

讀寫分離 – 跨機房優化（預設是關閉的）

• - 犧牲一緻性
• - 寫：寫主
• - 讀：同IP > 同IDC > 跨IDC （優先級政策）

高可用

• - Sentinel 替換了HA

他還講述了未來的規劃，提到了有如下幾點：

• - 相容Redis，更新到Redis4.2，做到最小修改，相容分片政策等；
• - 完善Codis，完善K8S的支援，提升自動化部署程度、實作Transaction等，內建Sentinel功能等。

更大的挑戰

• - 更大的副本容量：單副本100TB以上
• - 更高的叢集吞吐：QPS 500 ~ 1000w/s

• - 更複雜的通路模式1）普通業務 – 低延遲

  2）資料平台 – 高吞吐

• Codis + RocksDB開源方案Pika

2、Redis異步遷移

聽到這裡時，還以為上面是重點，結果不是，重點下面才真正開始。

Redis同步遷移存在的問題：

降低服務品質

• - 阻塞服務
• - 誤觸HA、丢失資料

限制資料規模

• - 實際建議<2MB（RESP限制<512MB）

遷移受網絡品質（RTT）影響

• - 增加阻塞時間、降低遷移效率

增加錯誤處理難度

• - 錯誤恢複困難、人工介入困難

舉個栗子：

那麼上述的問題的解決思路是什麼呢？他繼續分享到：

指令分解

• - 單個複雜、耗時的操作，分解成多個簡單、高效的指令
• - 分攤CPU分攤，單指令us級别
• - 支援AUTH、SELECT指令

異步IO + 指令流水

• - 連接配接複用
• - 流量控制 – 發送視窗
• - 批量遷移（Batch）

錯誤處理 – 髒資料處理

• - 主動清理
• - 過期清理

遷移狀态機

• - 發送視窗初始化
• - 确定傳輸模式：簡單 or 分片？
• - 連接配接初始化（start）
• - REPLACE語義
• - 發送分片（Chunked）
• - 臨時TTL = RTT x 3
• - 遷移完成
• - 重置TTL
• - 标記完成（Done）
• - 異步删除 – BIO thread

通路沖突

• - 遷移間隙 – Key Missing
• - 遷移過程中 – 1）讀 – 遷沖突； 2）寫 – 遷沖突；3）Key Missing

四、Redisson

Redisson是什麼？以及Redisson專業版有哪些特性和優點？Redisson聯合創始人顧睿從Redisson使用上，舉例“如何利用Redisson分布式化傳統web項目”的分享，算是對之前内容的一個很好的補充和論證。(Redisson項目位址：https://github.com/redisson/redisson)傳統Web項目的基本架構

傳統Web項目的典型特征：

• - 非分布式
• - 非高可用
• - 非高并發

什麼是分布式系統？

• - 網絡 – 高度互聯
• - 叢集 – 多節點
• - 單一 – 透明化

分布式系統的特點：

• - 開放性
• - 透明性
• - 擴充性
• - 并發性

分布式化的實作方式有哪些呢？

• - 架構細分
• - 服務化、子產品化
• - 資料中心化
• - 事件驅動

分布式系統會遇到哪些挑戰？

接着他分享了Redis以及Redisson的概念和特點的介紹，這裡為了節省篇幅，省略N多文字，但為了後面的了解，多啰嗦一句：Redisson是操作最簡單，功能最豐富的Redis智能用戶端，為JVM提供基于Redis的高性能駐記憶體資料網格。那Redisson的智能化又是展現在哪些方面呢？

Redisson是如此智能的用戶端，那相比其它的普通用戶端又有怎樣的差異和優勢呢？

回到主題上，Redisson可以解決傳統Web項目分布式化？那它是怎麼做到的？當時由于時間的關系，Jack Gu隻是從兩個方面進行了講解，相信能在更多的方面進行解決，這兩個方面分别是從資料緩存的角度和分布式鎖的角度進行分享。

Redisson映射

• Redis基本結構：Redis Hash
• Java 接口：java.util.Map、java.util.concurrent.ConcurrentMap
• 緩存設計模式：Read Through、Write Through、Write Behind
• 資料預熱：Data Preload

防緩存穿透，在Redisson上做了一些改進：

Redisson映射資料緩存的兩種方案：

在鎖上Redisson又做了哪些改進來滿足分布式的需求呢？

看着上面的簡單描述，各種名詞似曾相識吧？真正要用起來，還是需要花些時間慢慢消化的。Redisson在一定程度上減少了使用的複雜性，提高了業務性能，提升了開發效率，可以嘗試一下。