内容簡要：
一、Redis叢集架構
二、Redis存儲媒體
三、從社群到企業版
如上圖所示，Redis叢集架構分為兩大類：标準版與叢集版。
标準版是最原始的Redis單程序模式，标準版細分為雙副本、單副本、讀寫分離三個類别。
叢集版分為代理模式與直連模式。業務從标準版遷移到叢集版時的可能存在Redis指令不相容，代理模式可以通過Proxy幫業務解決這方面問題。直連模式中，Redis Client通過Redis Cluster模式直連Redis DB節點，做到減少網絡時延，提升一定的性能。這兩種連接配接模式下分别支援了雙副本跟單副本兩種資料形态。
（一）标準版
如上圖所示，标準版的拓撲結構是業務在ECS直接通過SLB連接配接到後端的 Redis節點。這裡Redis節點會有兩種情況，第一種情況是左圖的一組一備，程序B是一個熱備，主備之間資料直接進行同步。第二種情況是右圖的冷備，隻有在主節點挂掉以後，冷備會被拉起，這個時候資料是空的。
● 使用場景：
1. 對Redis協定相容性要求較⾼的業務；
2. 單個Redis性能壓⼒可控的場景；
3. Redis指令相對簡單，排序和計算之類的指令較少的場景。
标準版細分為：雙副本、單副本和讀寫分離三種形态，下面逐一介紹。
1.标準版 - 雙副本
标準版-雙副本模式采用主從（Master-Replica）模式搭建。主節點提供日常服務通路，備節點提供HA高可用，當主節點發生故障，系統會自動在30秒内切換至備節點，保證業務平穩運作。
● 特點：
1. 可靠性：采用雙機主從（Master-Replica）架構，主從節點位于不同實體機。主節點對外提供通路，使用者可通過Redis指令行和通用用戶端進行資料的增删改查操作。當主節點出現故障，自研的HA系統會自動進行主從切換，保證業務平穩運作。
2. 資料可靠：預設開啟資料持久化功能，資料全部落盤。支援資料備份功能，使用者可以針對備份集復原執行個體或者克隆執行個體，有效地解決資料誤操作等問題。同時，在支援容災的可用區（例如杭州可用區H+I）建立的執行個體，還具備同城容災的能力。
兩個副本之間的資料實時異步同步，切換主備時可能存在延遲情況。當主節點當機的時候，可能存在一部分資料沒有同步到B程序（即備節點）上，此時如果進行主備切換，B程序相對于A程序有同步延遲，可能存在部分資料丢失。
此外，在雙副本中可以做資料的克隆，即備份機，備份到另一個地方做資料持久化。當業務需要做資料復原時，可以從備份機上進行恢複。
2.标準版 – 單副本
标準版-單副本采用單個資料庫節點部署架構，沒有可實時同步資料的備用節點，不提供資料持久化和備份政策，使用于資料可靠性要求不高的純緩存業務場景使用。
1. 純緩存類業務使用，單副本隻有一個線上資料節點，成本效益高；
2. 阿裡雲自研HA高可用系統，異常30秒自動切換。
單副本在使用時需要注意，當高可用節點A當機後，需要先對B節點進行緩存的預熱，避免切換後發現B節點無資料可用。
3.讀寫分離
針對讀多寫少的業務場景，雲資料庫Redis推出了讀寫分離版的産品形态，提供高可用、高性能、靈活的讀寫分離服務，滿足熱點資料集中及高并發讀取的業務需求，最大化地節約運維成本。
ECS執行個體通過Proxy節點，可以将讀寫請求分發到主節點資料分片，并将部分讀請求分發到其他隻讀節點。
1. 讀取請求QPS壓力較大：适合讀多寫少型業務；
2. 對Redis協定相容要求較高的業務。
● 建議與使用須知：
1. 非特殊需求不建議使用，QPS壓力大的業務建議使用叢集版；
2. 當一個隻讀節點發生故障時，請求會轉發到其他節點；如果所有隻讀節點均不可用，請求會全部轉發到主節點，導緻主節點壓力過大；
3. 隻讀節點發生異常時，高可用系統會暫停異常節點服務進行重搭恢 複，但不承諾隻讀節點的恢複時間名額；
4. 隻讀節點資料舊于主節點且落後時間可能很長。
（二）叢集版
1. 資料量較大的場景；
2. QPS壓力較大的場景；
3. 吞吐密集型（網絡帶寬較大）應用場景。
1.叢集版 – 雙副本
雲資料庫Redis版提供雙副本叢集版執行個體，可輕松突破Redis自身單線程瓶頸，滿足大容量、高性能的業務需求。叢集版支援代理和直連兩種連接配接模式。
1. 資料量大：相比Redis标準版，叢集版可以有效地擴充存儲量，最大 可達4098 GB，能有效的滿足業務擴充的需求；
2. QPS壓力較大：标準版Redis無法支撐較大的QPS，需要采用多分片的部署方式來突破Redis單線程的性能瓶頸；
3. 吞吐密集型應用：相比Redis标準版，叢集版的内網吞吐限制相對較低，可以更好地支援熱點資料讀取、大吞吐類業務；
4. 對Redis協定相容性不敏感的應用：叢集版對Redis協定支援上相比标準版本有一定的限制。
代理模式因所有請求都需要通過代理伺服器轉發，代理模式在降低業務開發難度的同時也會小幅度影響Redis服務的響應速度，如果業務響應速度的要求非常高，可以選擇直連模式，繞過代理伺服器直連後端資料分片，進而降低網絡開銷和服務響應時間，直連模式适用于對響應要求較高的業務。
2.叢集版 – 指令限制
● 不支援指令
1. SWAPDB
2. CLIENT ID
3. SORT (BY和GET)
● 受限指令
在叢集模式下如果需要執行受限制的指令，需要使用Hash Tag確定所要操作的Key在同個Hash Slot中，Hash Tag的詳細用法參見Redis官方文檔。
可以看到，許多受限指令為多Key指令，為什麼多Key指令會受到限制？
因為叢集版會根據資料的Key做一次性Hash，分散到不同的資料節點上，這些涉及到多Key的指令，key經過Hash後如果分布在不同的節點上，指令就不能在一個單資料節點裡面完成，這些指令會直接傳回錯誤。
如果要使用這些多Key指令，需要每一個Key準确Hash到同一個Slot上。Redis的Key可以添加一個Hash Tag，相同的Tag會被Hash到同一個Slot上，在同一個Slot中，這些受限的指令就可以支援。
● Lua腳本使用限制：
1. 所有Key都應該由KEYS數組來傳遞；
2. 所有Key必須在同一個Slot上；
3. 調用必須要帶有Key；
4. 不支援釋出訂閱消息；
5. 不支援UNPACK函數；
6. 其他詳細限制參見Redis官方文檔。
3.叢集模式如何選型
● 選型時應注意以下兩點：
1. 評估QPS和容量時⼀定要為未來留有餘量；
2. 不同架構間存在一定的相容性問題，業務允許的情況下盡量使用不同架構指令支援集合的交集，以便後續架構切換。
如上圖所示，簡言之，如果業務qps低且容量低（小于32GB）選擇标準版，否則選擇叢集版。
在選擇标準版的情況下，根據資料可靠性與讀寫情況可再進行細分。
如果業務資料單純作為緩存加速或資料可丢，可以選擇單副本，減少一半的成本。如果要求資料在異常情況下不能全部丢失，對可靠性要求較高的情況下，此時要根據讀寫情況進行選擇。
如果讀寫情況沒有明顯差異，可以選擇雙副本，如果讀請求數量遠大于寫請求，可以選擇讀寫分離。但是除去特殊情況，讀寫分離有諸多限制，大多數情況下不是一個很好的選擇，我們還是建議考慮叢集的模式。
如果使用者原本使用标準版，随着業務的發展QPS容量上升，需要由标準版切換成叢集版，根據指令相容性可選擇不同模式。
如果使用者業務代碼有太多需要修改，或者不想修改代碼，對指令相容性要求較高，可以選擇代理模式，相容性問題由阿裡雲提供的Proxy解決。如果業務對相容性要求較低，或者新業務在開發時本就是按照叢集版标準進行，則可選擇直連模式。
模式選擇完之後，可根據業務對資料可靠性的要求，進一步選擇單副本或雙副本。此處的單雙副本使用注意事項，與标準版類似。
二、Redis存儲媒體
購買Redis時還需選擇存儲媒體，目前阿裡雲提供四種存儲媒體，分别為記憶體型、持久記憶體型、容量存儲型和混合存儲型。
記憶體型為我們常見的純記憶體，混合存儲型正逐漸被持久記憶體型與容量存儲型替代，下面重點介紹持久記憶體型與容量存儲型。
（一）持久記憶體型
Redis企業版持久記憶體型（簡稱持久記憶體型）基于Intel 傲騰™資料中心級持久記憶體（AEP），為使用者提供大容量、相容Redis的記憶體資料庫産品。單執行個體成本對比Redis社群版最高可降低30%，且資料持久化不依賴傳統磁盤，保證每個操作持久化的同時提供近乎Redis社群版的吞吐和延時，極大提升業務資料可靠性。
1. 超高成本效益：相同容量下對比阿裡雲Redis社群版本，價格降低30%左右；
2. 大規格優化：解決AOF的造成的性能開銷，無需在性能和持久化之間取舍；
3. 掉電資料不丢失：每個寫操作都同步持久化；
4. 高相容性：相容現有阿裡雲Redis資料庫體系。
（二）容量存儲型
Redis企業版容量存儲型（簡稱容量存儲型）基于雲盤ESSD研發，相容Redis核心資料結構與接口，可提供大容量、低成本、強持久化的資料庫服務。容量存儲型在降低成本和提升資料可靠性的同時，也解決了原生Redis固有的Fork指令而預留部分記憶體的問題。适用于相容Redis、需要大容量且較高通路性能的溫冷資料存儲場景。
1. 相容性：相容大部分原生Redis指令；
2. 成本：最低為Redis社群版的15%。
（一）阿裡雲叢集能力
阿裡雲Redis與開源版Redis叢集能力對比
（二）開源Redis叢集實作
● 實作細節：
1. 通過Gossip使所有Redis節點彼此互相心跳探活，使用内部的二進制協定優化傳輸速度和帶寬；
2. 節點Fail時通過叢集中超過半數節點探活協商确定失敗，如果叢集較大則會拉長協商時間；
3. 節點間資料遷移是按照Key的粒度進行的，遷移過程中一個Slot的資料會分布在兩個節點上。
● 優點：
使用Gossip協定無中心控制，無額外控制節點。
● 缺點：
1. 無中心控制，叢集狀态更新慢，故障HA慢；
2. 探活方式單一，受慢查詢幹擾，容易誤切換；
3. 按Key遷移，大Key遷移造成服務卡頓；
4. 遷移異常中斷，無法自動恢複；
5. 遷移期間多Key指令失敗；
6. 遷移依賴外部元件。
（三）阿裡雲Redis叢集實作
1. 中心控制節點采用自研的多因子進行準确的探活；
2. 資料遷移采用Slot粒度Precopy的方式，遷移快速，異常可復原。
1. 準确快速的探活，保障服務品質(SLA<15s)；
2. 同時支援直連模式和代理模式；
3. 擴縮容業務無感覺（大Key，多key，Lua），不斷連接配接；
4. 遷移流量在節點間直接傳輸，不需要外部元件中轉。