天天看點
傳回

技術圈兒007---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。
  • 新增賬号管理功能。
  • 新增日志管理功能，支援審計日志、運作日志和慢日志，您可以通過日志管理查詢讀寫操作、敏感操作（如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叢集，用戶端的請求通過代理伺服器轉發到各資料分片，代理伺服器、資料分片和配置伺服器均不提供單獨的連接配接位址，降低了應用開發難度和代碼複雜度。代理模式的服務架構圖群組件說明如下。

技術圈兒007---Redis 生産架構選型解決方案
技術圈兒007---Redis 生産架構選型解決方案

直連模式

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

技術圈兒007---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);
}

2.4 叢集版-單副本

技術圈兒007---Redis 生産架構選型解決方案
技術圈兒007---Redis 生産架構選型解決方案

2.5 讀寫分離版

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

技術圈兒007---Redis 生産架構選型解決方案
技術圈兒007---Redis 生産架構選型解決方案

特點

  • 高可用
  1. 通過自研的高可用系統自動監控所有資料節點的健康狀态，為整個執行個體的可用性保駕護航。主節點不可用時自動選擇新的主節點并重新搭建複制拓撲。某個隻讀節點異常時，高可用系統能夠自動探知并重新啟動新節點完成資料同步，下線異常節點。
  2. Proxy節點實時感覺每個隻讀執行個體的服務狀态。在某個隻讀執行個體異常期間，Proxy會自動降低該節點的服務權重，發現隻讀節點連續失敗超過一定次數以後，會停止異常節點的服務權利，并具備繼續監控後續重新啟動節點服務的能力。
  • 高性能
  1. 讀寫分離版采取鍊式複制架構，可以通過擴充隻讀執行個體個數使整體執行個體性能呈線性增長 ，同時基于源碼層面對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資訊。
資料庫 Redis 架構選型 資料
上一篇: 深信服asv授權管理
下一篇: linux主機名

繼續閱讀