二、儲存架構演變

1、架構演變
 

在2014年7月，為了準備當時的814撒嬌節大促銷活動，我們把單個redis的服務遷移到twemproxy上。twemproxy在後端快速完成資料分片和擴容。為了避免再次擴容，我們靜態分配足夠多的資源。
之後，twemproxy暴露出來的系統瓶頸很多，資源使用很多，也存在一定的浪費。我們決定用redis cluster取代這種複雜的三層架構。
redis cluster GA之後，我們就開始上線使用。最初是3.0.2 版本，後面大量使用3.0.3 ，上個月開始使用3.0.7版本。
下面簡單對比下兩種架構，解析下他們的優缺點。

2、Twemproxy架構優點

• sharding邏輯對開發透明，讀寫方式和單個redis一致。
• 可以作為cache和storage的proxy（by auto-eject）。

缺點

• 架構複雜，層次多。包括lvs、twemproxy、redis、sentinel和其控制層程式。
• 管理成本和硬體成本很高。
• 2 * 1Gbps 網路卡的lvs機器，最大能支撐140萬pps。
• 流量高的系統，proxy節點數和redis個數接近。
• Redis層仍然擴容能力差，預分配足夠的redis儲存節點。

 


這是twemproxy的架構，客戶端直接連線最上面的lvs（LB），第二層是同構的twemproxy節點，下面的redis master節點以及熱備的slave節點，另外還有獨立的sentinel叢集和切換控制程式，twemproxy先介紹到這裡。

3、Redis Cluster架構優點

• 無中心 架構。
• 資料按照slot儲存分佈在多個redis例項上。
• 增加slave做standby資料副本，用於failover，使叢集快速恢復。
• 實現故障auto failover。節點之間通過gossip協議交換狀態資訊；投票機制完成slave到master角色的提升。
• 亦可manual failover，為升級和遷移提供可操作方案。
• 降低硬體成本和運維成本，提高系統的擴充套件性和可用性。

缺點和不足的地方

• client實現複雜，驅動要求實現smart client，快取slots mapping資訊並及時更新。
• 目前僅JedisCluster相對成熟，異常處理部分還不完善，比如常見的“max redirect exception”。
• 客戶端的不成熟，影響應用的穩定性，提高開發難度。
• 節點會因為某些原因發生阻塞(阻塞時間大於clutser-node-timeout），被判斷下線。這種failover是沒有必要，sentinel也存在這種切換場景。
  cluster的架構如下：

 


圖上只有master節點（slave略去），所有節點構成一個完全圖,slave節點在叢集中與master只有角色和功能的區別。
架構演變講完了,開始講第三部分，也是大家最感興趣的一部分。

本文作者：geelou

本文來自雲棲社群合作伙伴rediscn，瞭解相關資訊可以關注redis.cn網站。