Redis生產架構選型解決方案

在寫開源項目的時候，想到了要支持多種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：https://redis.io/topics/streams-intro。
• 新增賬號管理功能。
• 新增日誌管理功能，支持審計日誌、運行日誌和慢日誌，您可以通過日誌管理查詢讀寫操作、敏感操作（如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自身單線程瓶頸，滿足大容量、高性能的業務需求。
• 主從架構，提供高性能的緩存服務和數據高可靠。
• 讀寫分離架構，提供高可用、高性能、高靈活的讀寫分離服務，解決熱點數據集中及高併發讀取的業務需求，最大化地節約用戶運維成本。

主從架構-雙副本

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

可靠性：

服務可靠採用雙機主從（master-replica）架構，主從節點位於不同物理機。主節點對外提供訪問，用戶可通過Redis命令行和通用客戶端進行數據的增刪改查操作。當主節點出現故障，HA系統會自動進行主從切換，保證業務平穩運行。

數據可靠默認開啓數據持久化功能，數據全部落盤。支持數據備份功能，用戶可以針對備份集回滾實例或者克隆實例，有效地解決數據誤操作等問題。

使用場景：

Redis作爲持久化數據存儲使用的業務標準版提供持久化機制及備份恢復機制，極大地保證數據可靠性。

單個Redis性能壓力可控的業務由於Redis原生採用單線程機制，性能在10萬QPS以下的業務建議使用。如果需要更高的性能要求，請選用集羣版本。

Redis命令相對簡單，排序、計算類命令較少的業務由於Redis的單線程機制，CPU會成爲主要瓶頸。如排序、計算類較多的業務建議選用集羣版配置。

主從架構-單副本

可以在沒有數據可靠性要求的純緩存場景充分發揮性能優勢。

使用場景：

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

單個Redis性能壓力可控，由於Redis原生採用單線程機制，CPU爲單核能力，性能在8萬QPS的業務建議使用。如果需要更高的性能要求，請選用集羣版配置。

Redis命令相對簡單，排序、計算類命令較少，由於Redis的單線程機制，CPU爲主要瓶頸。如排序、計算類較多的業務建議選用集羣版配置。

集羣版-雙副本

可輕鬆突破Redis自身單線程瓶頸，滿足大容量、高性能的業務需求。雙副本集羣版實例採用集羣架構，每個分片服務器採用主從（master-replica）雙副本模式。集羣版支持代理和直連兩種連接模式，你可以根據本章節的說明，選擇適合業務需求的連接模式。

代理模式：

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

直連模式：

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

前提條件 使用Jedis、PhpRedis等支持Redis Cluster的客戶端。

• 使用不支持Redis Cluster的客戶端，可能因客戶端無法重定向請求到正確的分片而獲取不到需要的數據。
• Jedis對於Redis Cluster的支持是基於JedisCluster這個類，詳細說明請參見Jedis文檔。
• 你可以在Redis官網的客戶端列表裏查找更多支持Redis Cluster的客戶端。

使用自定義連接池的示例代碼：

import redis.clients.jedis.*;
import java.util.HashSet;
import java.util.Set; 
public class main {
private static final int DEFAULT_TIMEOUT = 2000; 
private static final int DEFAULT_REDIRECTIONS = 5;
private static final JedisPoolConfig DEFAULT_CONFIG = new JedisPoolConfig();


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);
}
}

集羣版-單副本

讀寫分離版

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

特點：

高可用

通過自研的高可用系統自動監控所有數據節點的健康狀態，爲整個實例的可用性保駕護航。主節點不可用時自動選擇新的主節點並重新搭建複製拓撲。某個只讀節點異常時，高可用系統能夠自動探知並重新啓動新節點完成數據同步，下線異常節點。

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信息。