在寫開源專案的時候，想到了要支持多種redis部署方式，于是對于這塊的生產環境的架構選型展開調研
#一、引擎版本
推薦使用更新的引擎版本以支持更多的特性
##Redis 6.0新特性說明

模塊系統新增多個API，
支持SSL/TLS加密，
支持新的Redis協議：RESP3，
服務端支持多模式的客戶端快取，
支持多執行緒IO，
副本中支持無盤復制（diskless replication），
Redis-benchmark新增了Redis集群模式，
支持重寫Systemd，
支持Disque模塊，

##Redis 5.0新特性說明

云資料庫Redis 5.0版本大幅度優化內核，運行更加穩定，同時新增Stream、賬號管理、審計日志等多種特性，滿足您更多場景下的使用需求，
新的資料型別：流資料（Stream），詳細說明請參見Redis Streams，
新增賬號管理功能，
新增日志管理功能，支持審計日志、運行日志和慢日志，您可以通過日志管理查詢讀寫操作、敏感操作（如KEYS、FLUSHALL）和管理類命令的使用記錄以及慢日志，
新增基于快照的快取分析功能，
新的定時器（Timers）、集群（ Cluster）和字典（Dictionary）模塊的API，
RDB中增加LFU和LRU資訊，
集群管理器從Ruby （redis-trib.rb）移植到了redis-cli中的C語言代碼，
新增有序集合（Sorted Set）命令ZPOPMIN、ZPOPMAX、BZPOPMIN和BZPOPMAX，
升級Active Defragmentation至v2版本，
增強HyperLogLog的實作，
優化記憶體統計報告，
為許多有子命令的命令增加了HELP子命令，
提高了客戶端頻繁連接和斷開連接時的性能表現，
升級Jemalloc至5.1版本，
新增命令CLIENT ID和CLIENT UNBLOCK，
新增了為藝術而生的LOLWUT命令，
棄用slave術語（需要API向后兼容的情況例外），
對網路層進行了多處優化，
進行了一些Lua相關的改進，
新增動態HZ（Dynamic HZ）以平衡空閑CPU使用率和回應性，
對Redis核心代碼進行了重構并在許多方面進行了改進，

##二架構
您需要根據業務需求選擇：

集群架構可輕松突破Redis自身單執行緒瓶頸，滿足大容量、高性能的業務需求，
主從架構，提供高性能的快取服務和資料高可靠，
讀寫分離架構提供高可用、高性能、高靈活的讀寫分離服務，解決熱點資料集中及高并發讀取的業務需求，最大化地節約用戶運維成本，

##2.1 主從架構-雙副本
采用主從（master-replica）模式搭建，主節點提供日常服務訪問，備節點提供HA高可用，當主節點發生故障，系統會自動在30秒內切換至備節點，保證業務平穩運行，

可靠性

服務可靠采用雙機主從（master-replica）架構，主從節點位于不同物理機，主節點對外提供訪問，用戶可通過Redis命令列和通用客戶端進行資料的增刪改查操作，當主節點出現故障，HA系統會自動進行主從切換，保證業務平穩運行，
資料可靠默認開啟資料持久化功能，資料全部落盤，支持資料備份功能，用戶可以針對備份集回滾實體或者克隆實體，有效地解決資料誤操作等問題，

使用場景

Redis作為持久化資料存盤使用的業務標準版提供持久化機制及備份恢復機制，極大地保證資料可靠性，
單個Redis性能壓力可控的業務由于Redis原生采用單執行緒機制，性能在10萬QPS以下的業務建議使用，如果需要更高的性能要求，請選用集群版本，
Redis命令相對簡單，排序、計算類命令較少的業務由于Redis的單執行緒機制，CPU會成為主要瓶頸，如排序、計算類較多的業務建議選用集群版配置，

##2.2 主從架構-單副本

可以在沒有資料可靠性要求的純快取場景充分發揮性能優勢，

使用場景

純快取類業務場景

單副本版本只有一個資料庫節點，節點出現故障時，系統會重新拉起一個Redis行程（沒有資料），當節點故障業務自動切換完成后，應用程式需要將資料重新預熱，以免對后端資料庫產生訪問壓力沖擊，
單副本架構不能提供資料可靠性，如果發生節點故障，您需要重新對業務進行預熱，因此，在對資料可靠性要求較高的敏感性業務中，建議選用雙副本架構，

單個Redis性能壓力可控

由于Redis原生采用單執行緒機制，CPU為單核能力，性能在8萬QPS的業務建議使用，如果需要更高的性能要求，請選用集群版配置，

Redis命令相對簡單，排序、計算類命令較少

由于Redis的單執行緒機制，CPU為主要瓶頸，如排序、計算類較多的業務建議選用集群版配置，
##2.3 集群版-雙副本
可輕松突破Redis自身單執行緒瓶頸，滿足大容量、高性能的業務需求，雙副本集群版實體采用集群架構，每個分片服務器采用主從（master-replica）雙副本模式，集群版支持代理和直連兩種連接模式，您可以根據本章節的說明，選擇適合業務需求的連接模式，

代理模式

集群架構的本地盤實體默認采用代理（proxy）模式，支持通過一個統一的連接地址（域名）訪問Redis集群，客戶端的請求通過代理服務器轉發到各資料分片，代理服務器、資料分片和配置服務器均不提供單獨的連接地址，降低了應用開發難度和代碼復雜度，代理模式的服務架構圖和組件說明如下，

直連模式
因所有請求都要通過代理服務器轉發，代理模式在降低業務開發難度的同時也會小幅度影響Redis服務的回應速度，如果業務對回應速度的要求非常高，您可以使用直連模式，繞過代理服務器直接連接后端資料分片，從而降低網路開銷和服務回應時間，直連模式的服務架構和說明如下，

public static void main(String args[]){
    JedisPoolConfig config = new JedisPoolConfig();
    // 最大空閑連接數, 根據業務需要設定，不能超過實體規格規定的最大的連接數
    config.setMaxIdle(200);
    // 最大連接數, 根據業務需要設定，不能超過實體規格規定的最大的連接數
    config.setMaxTotal(300);
    config.setTestOnBorrow(false);
    config.setTestOnReturn(false);

    // 開通直連訪問時申請到的直連地址
    String host = "r-bp1xxxxxxxxxxxx.redis.rds.aliyuncs.com"; 
    int port = 6379;
    // 實體的密碼
    String password = "xxxxx";

    Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>();
    jedisClusterNode.add(new HostAndPort(host, port));
    JedisCluster jc = new JedisCluster(jedisClusterNode, DEFAULT_TIMEOUT, DEFAULT_TIMEOUT,
            DEFAULT_REDIRECTIONS,password, "clientName", config);
}

##2.4 集群版-單副本

##2.5 讀寫分離版

針對讀多寫少的業務場景，提供高可用、高性能、靈活的讀寫分離服務，滿足熱點資料集中及高并發讀取的業務需求，最大化地節約運維成本，讀寫分離版主要由主備節點、只讀節點、Proxy（代理）節點和高可用系統組成，

特點

高可用

1.通過自研的高可用系統自動監控所有資料節點的健康狀態，為整個實體的可用性保駕護航，主節點不可用時自動選擇新的主節點并重新搭建復制拓撲，某個只讀節點例外時，高可用系統能夠自動探知并重新啟動新節點完成資料同步，下線例外節點，
2.Proxy節點實時感知每個只讀實體的服務狀態，在某個只讀實體例外期間，Proxy會自動降低該節點的服務權重，發現只讀節點連續失敗超過一定次數以后，會停止例外節點的服務權利，并具備繼續監控后續重新啟動節點服務的能力，

高性能

讀寫分離版采取鏈式復制架構，可以通過擴展只讀實體個數使整體實體性能呈線性增長，同時基于原始碼層面對Redis復制流程的定制優化，可以最大程度地提升線性復制的系統穩定性，充分利用每一個只讀節點的物理資源，

使用場景

讀取請求QPS（Queries Per Second）壓力較大

標準版Redis無法支撐較大的QPS，如果業務型別是讀多寫少型別，需要采用多個只讀節點的部署方式來突破Redis單執行緒的性能瓶頸，Redis集群版提供1個、3個、5個只讀節點的配置，相比標準版可以將QPS提升近5倍，
對Redis協議兼容性要求較高的業務
讀寫分離版完全兼容Redis協議命令，可將自建Redis資料庫遷移至讀寫分離版，同時支持從Redis標準版（雙副本）一鍵平滑升級至讀寫分離版，

建議與使用須知

當一個只讀節點發生故障時，請求會轉發到其他節點；如果所有只讀節點均不可用，請求會全部轉發到主節點，只讀節點例外可能導致主節點負載提高、回應時間變長，因此在讀負載高的業務場景建議使用多個只讀節點，
某些場景會觸發只讀節點的全量同步，例如在主節點觸發高可用切換后，全量同步期間只讀節點不提供服務并回傳-LOADING Redis is loading the dataset in memory\r\n資訊，

#小結