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

zhangdh1113發表於2018-09-27

前陣子有幸現場聆聽了雲棲大會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上面，阿里雲團隊也做了很多的工作，比如：

叢集支援select、pub/sub、blpop的能力；
對熱key的感知和處理；
讀寫分離；
多資料中心的災備以及穩定可靠的基於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專案的基本架構