文｜曹佳俊

網易云信資深服務端開發工程師

背? ? 景

?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模型，上述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服務器相關的開發工作。

推薦閱讀

《從入門到進階｜如何基于WebRTC搭建一個視頻會議》

《漫談企業級SaaS的多租戶設計》

總結

以上是生活随笔為你收集整理的开源｜如何开发一个高性能的redis cluster proxy？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。