背景
redis cluster簡介
Redis cluster是redis官方提供集羣方案，設計上採用非中心化的架構，節點之間通過gossip協議交換互相的狀態，redis cluster使用數據分片的方式來構建集羣，集羣內置了16384個哈希槽，每個key都屬於這16384這個哈希槽中的一個，通過crc16算法計算哈希值，再取餘可得每個key歸屬的哈希槽；redis cluster支持動態加入新節點，動態遷移slot，自動的故障轉移等。
Redis cluster的架構要求客戶端需要直接與redis集羣中的每個節點建立連接，並且當出現新增節點加入、節點宕機failover、slot遷移等事件時，客戶端需要能夠通過redis cluster協議去更新本地的slot映射表，並且能處理ASK/MOVE語義，因此，我們一般稱實現了redis cluster協議的客戶端爲smart redis client。
Redis cluster最多可以構建超過100個主節點的集羣（超過之後gossip協議開銷過大，且可能引起集羣不穩定），按照單節點10G容量（單實例內存過大可能導致性能下降），單集羣最多可以支撐1T左右的容量。
問題
redis cluster有很多優點（比如可以構建大容量集羣，性能好，擴縮容靈活），但是當一些項目工程期望從redis遷移到redis cluster時，客戶端卻面臨着大量的改造工作，與此同時帶來的是需要大量的測試工作以及引入的新風險，這對於一些穩定運行的線上工程代價無疑是巨大的。
需求
爲了更方便的將業務遷移到redis cluster，最期望的是客戶端SDK的API完全兼容redis/redis-cluster，spring提供的RedisTemplate是一個很好實現，但是對於沒有使用SpringRedisTemplate的項目，很多客戶端實現的redis和redis-cluster訪問API是不一致的（比如Java中流行的Jedis），這無形中提高了遷移工作的工作量和複雜性，此時redis cluster proxy是不錯的選擇，有了proxy，就可以像操作單實例redis一樣操作redis cluster，客戶端程序就不需要做任何的修改。
當然，增加一層proxy，必然會導致性能有一定程度的下降，但是proxy作爲無狀態的服務，理論上可以水平擴展，並且由於proxy層的存在減少了後端redis server的連接數，在某些極端場景下甚至能提高redis集羣整體的吞吐量。此外，基於proxy，我們還可以做很多額外的事情：
- 比如可以在proxy層做分片邏輯，這樣當單集羣的redis cluster不滿足需求（內存/QPS）時，就可以通過proxy層實現透明的同時訪問多個redis cluster集羣。
- 再比如可以在proxy層做雙寫邏輯，這樣在遷移或者拆分緩存類型的redis時，就不需要使用redis-migrate-tool之類的工具進行全量遷移，而只需要按需雙寫，即可完成遷移。
- 此外因爲proxy實現了redis協議，因此可以在proxy層利用其它存儲介質實現redis相關命令，從而可以模擬成redis對外服務。一個典型的場景就是冷熱分離存儲。
功能
介於上述各種原因和需求，我們基於netty開發了camellia-redis-proxy這樣一箇中間件，支持如下特性：
- 支持設置密碼
- 支持代理到普通redis，也支持代理到redis cluster
- 支持配置自定義的分片邏輯（可以代理到多個redis/redis-cluster集羣）
- 支持配置自定義的雙寫邏輯（服務器會識別命令的讀寫屬性，配置雙寫之後寫命令會同時發往多個後端）
- 支持外部插件，從而可以複用協議解析模塊（當前提供了camellia-redis-proxy-hbase插件，實現了zset命令的冷熱分離存儲）
- 支持在線變更配置（需引入camellia-dashboard）
- 支持多個業務邏輯共享一套proxy集羣，如：A業務配置轉發規則1，B業務配置轉發規則2（需要在建立redis連接時通過client命令設置業務類型）
- 對外提供了一個spring-boot-starter，3行代碼即可快速搭建一個proxy集羣
如何提升性能
客戶端向camellia-redis-proxy發起一條請求，到收到請求回包的過程中，依次經歷瞭如下過程
- 上行協議解析（IO讀寫）
- 協議轉發規則匹配（內存計算）
- 請求轉發（IO讀寫）
- 後端redis回包解包（IO讀寫）
- 後端redis回包下發到客戶端（IO讀寫）
可以看到作爲一個proxy，大量的工作是在進行網絡IO的操作，爲了提升proxy的性能，做了以下工作：
多線程
我們知道redis本身是單線程的，但是作爲一個proxy，完全可以使用多線程來充分利用多核CPU的性能，但是過多的線程引起不必要的上下文切換又會引起性能的下降。camellia-redis-proxy使用了netty的多線程reactor模型來確保服務器的處理性能，默認會開啓cpu核心數的work線程。 此外，如果服務器支持網卡多隊列，開啓它，能避免CPU不同核心之間的load不均衡；如果不支持，那麼將業務進程綁核到非CPU0的其他核心，從而讓CPU0專心處理網卡中斷而不被業務進程過多的影響。
異步非阻塞
異步非阻塞的IO模型一般情況下性能都是優於同步阻塞的IO模型，對於proxy場景尤其如此，上述5個過程中，除了協議轉發規則匹配這樣的內存計算，整個轉發流程都是異步非阻塞的，確保不會因爲個別流程的故障影響整個服務。
流水線
我們知道redis協議支持流水線（pipeline），pipeline的使用，可以有效減少網絡開銷。camellia-redis-proxy也充分利用了這樣的特性，主要包括兩方面：
- 上行協議解析時儘可能的一次性解析多個命令，從而進行規則轉發時可以批量進行
- 往後端redis節點進行轉發時儘可能的批量提交，這裏除了對來自同一個客戶端連接的命令進行聚合，還可以對來自不同客戶端連接，但轉發目標redis相同時，也可以進行命令聚合
當然，所有這些批量和聚合的操作都需要保證請求和響應的一一對應。
TCP分包和大包處理
不管是上行協議解析，還是來自後端redis的回包，特別是大包的場景，在碰到TCP分包時，利用合適的checkpoint的機制可以有效減少重複解包的次數，提升性能。
異常處理和異常日誌合併
如果沒有有效的處理各種異常，在異常發生時也會導致服務器性能迅速下降。想象一個場景，我們配置了90%的流量轉發給A集羣，10%的流量轉發到B集羣，如果B集羣發生了宕機，我們期望的是來自客戶端的90%的請求正常執行，10%的請求失敗，但是實際上卻可能遠遠超過10%的請求都失敗了，原因是多方面的：
- 後端操作系統層面的突然宕機proxy層可能無法立即感知（沒有收到TCP fin包），導致大量請求在等待回包，雖然proxy層沒有阻塞，但是客戶端表現爲請求超時
- proxy在嘗試轉發請求到B集羣時，針對B集羣的重新連接請求可能拖慢整個流程
- 宕機導致的大量異常日誌可能會引起服務器性能下降（這是一個容易忽視的地方）
- pipeline提交上來的請求，99個請求指向A集羣，1個請求指向B集羣，但是由於B集羣的不可用，導致指向B集羣的請求遲遲不回包或者異常響應過慢，客戶端的最終表現是100個請求全部失敗了
camellia-redis-proxy在處理上述問題時，採取瞭如下策略：
- 設置對異常後端節點的快速失敗降級策略，避免拖慢整個服務
- 異常日誌統一管理，合併輸出，在不丟失異常信息的情況下，減少異常日誌對服務器性能的影響
- 增加對後端redis的定時探活探測，避免宕機無法立即感知導致業務長時間異常
部署架構
proxy作爲無狀態的服務，可以做到水平擴展，爲了服務的高可用，也至少要部署兩個以上的proxy節點，對於客戶端來說，想要像使用單節點redis一樣訪問proxy，可以在proxy層之前設置一個LVS代理服務，此時，部署架構圖如下：
當然，還有另外一個方案，可以將proxy節點註冊到zk/Eureka/Consul等註冊中心，客戶端通過拉取和監聽proxy的列表，然後再向訪問單節點redis一樣訪問每個proxy即可。以Jedis爲例，僅需將JedisPool替換爲封裝了註冊發現邏輯的RedisProxyJedisPool，即可像訪問普通redis一樣使用proxy了，此時，部署架構圖如下：
應用場景
- 需要從redis遷移到redis-cluster，但是客戶端代碼不方便修改
- 客戶端直連redis-cluster，導致cluster服務器連接過多，導致服務器性能下降
- 單個redis/redis-cluster集羣容量/QPS不滿足業務需求，使用camellia-redis-proxy的分片功能
- 緩存類redis/redis-cluster集羣拆分遷移，使用camellia-redis-proxy的雙寫功能
- 使用雙寫功能進行redis/redis-cluster的災備
- 混合使用分片和雙寫功能的一些業務場景
- 基於camellia-redis-proxy的插件功能，開發自定義插件
結語
Redis cluster作爲官方推薦的集羣方案，越來越多的項目已經或正在遷移到redis cluster，camellia-redis-proxy正是在這樣的背景下誕生的；特別的，如果你是一個Java開發者，camellia還提供了CamelliaRedisTemplate這樣的方案，CamelliaRedisTemplate擁有和普通Jedis一致的API，提供了mget/mset/pipeline等原生JedisCluster不支持的特性，且提供了和camellia-redis-proxy功能一致的分片/雙寫等特性。
爲了回饋社區，camellia已經正式開源了，想詳細瞭解camellia項目的請移步github，地址如下：https://github.com/netease-im/camellia
如果你有什麼好的想法或者提案，或者有什麼問題，歡迎提交issue與我們交流！
關於作者
曹佳俊。網易智慧企業資深服務端開發工程師。中科院研究生畢業後加入網易，一直在網易雲信負責IM服務器相關的開發工作。
更多技術乾貨，歡迎關注vx公衆號“網易智慧企業技術+”。聽網易CTO講述前沿觀察，看最有價值技術乾貨，學網易最新實踐經驗。網易智慧企業技術+，陪你從思考者成長爲技術專家。