Tair Proxy特性與路由轉寄規則 - Tair (Redis® OSS-Compatible)

在Tair (Redis OSS-compatible)叢集架構和讀寫分離架構中，Proxy 伺服器（Proxy）承擔著路由轉寄、負載平衡和容錯移轉等職責，可以協助您簡化用戶端的邏輯，同時支援多資料庫（DB）、緩衝熱點資料等進階功能。通過瞭解Proxy的路由轉寄規則和特定命令的處理方式，有助於您設計更高效的業務系統。

Proxy介紹

Proxy 伺服器（Proxy）是Tair執行個體中的一個組件（單節點架構），不會佔用資料分區的資源，通過多個Proxy節點實現負載平衡及容錯移轉。

Proxy能力	說明
叢集版使用模式轉換	Proxy能夠實現架構轉換，協助您如同在使用標準架構一樣地使用叢集架構。Proxy支援對DEL、EXISTS、MGET、MSET、SDIFF與UNLINK等命令進行跨Slot的多Key操作，更多資訊請參見代理模式（Proxy）支援的命令列表。當標準架構無法支撐業務發展時，您無需修改代碼即可將標準架構的資料移轉至帶有Proxy的叢集架構，大幅度降低業務改造成本。
負載平衡和路由轉寄	Proxy與後端的資料分區建立長串連，負責請求負載平衡和路由轉寄操作，關於轉寄規則的介紹，請參見Proxy的路由轉寄規則。
管理唯讀節點流量	Proxy會即時探測唯讀節點的狀態，當出現下述情況時，Proxy會執行流量管控動作：唯讀節點處於異常狀態：Proxy會降低該節點的服務權重，如果多次無法串連該節點，Proxy會停止該節點的服務（即不再將流量轉寄至該節點），待該異常被修複後重新啟用該節點。唯讀節點處於全量同步狀態：Proxy會暫時停止該節點的服務，直到該節點完成全量同步。
代理查詢快取	開啟代理查詢快取功能（Proxy Query Cache）後，Proxy會緩衝熱點Key對應的請求和返回資訊，當在有效時間內收到同樣的請求時直接返回結果至用戶端，無需和後端的資料分區互動，可更好地改善對熱點Key的發起大量讀請求導致的訪問傾斜。說明您可以設定query_cache_enabled參數開啟該功能，僅Tair記憶體型、持久記憶體型執行個體支援該功能。
支援多資料庫（DB）	叢集模式下，原生Redis和Cluster client均不支援多資料庫（DB）功能，只使用預設的`0`號資料庫，也不支援`SELECT`命令。但您可以通過Proxy訪問叢集執行個體，支援多資料庫（DB）功能，支援使用`SELECT`命令，叢集版執行個體預設為256個DB。說明若您使用StackExchange.Redis用戶端，請使用StackExchange.Redis 2.7.20及以上版本，否則會產生報錯，更多資訊請參見StackExchange.Redis升級公告。

說明

由於Proxy的演化，Proxy的個數並不完全代表Proxy處理能力，阿里雲會保證叢集規格中Proxy的配比符合規格說明的要求。

Proxy的路由轉寄規則

說明

關於各類命令的介紹，請參見命令概覽。

架構	轉寄規則	說明
叢集架構	基礎轉寄規則	對於操作單個Key的命令，Proxy會根據Key所屬的Slot（槽）將請求發送給所屬的資料分區。對於操作多個Key的命令，如果這些Key是儲存在不同的資料分區，Proxy會將命令拆分成多個命令分別發送給對應的分區。說明自Redis開源版5.0版本的5.0.1小版本起，以及在6.0、7.0及更高版本中，Proxy對命令進行Slot層級拆分，與Redis社區保持一致。但Redis開源版5.0版本在5.0.1之前的小版本，以及在4.0、2.8版本中，Proxy對命令進行分區層級拆分。當這部分執行個體升級至Redis開源版5.0及以上版本時，由於命令拆分規則的變化，可能會導致QPS增加以及流量略有上升。然而，由於Proxy是以Pipeline方式投遞命令，因此對效能的影響相對較小。
叢集架構	特定命令轉寄規則	發布訂閱類命令對於PUBLISH、SUBSCRIBE等發布訂閱命令，Proxy會根據channel name進行Hash計算，並路由至對應資料分區。Pub/Sub類命令雖然不會往資料庫中寫入資料，但仍會佔用一定的記憶體和資源，資源消耗主要體現在用戶端串連、訂閱狀態管理和訊息緩衝區上。例如某channel屬於資料分區1 ，那麼訂閱該頻道的用戶端會佔用資料分區1的記憶體、CPU、網路頻寬等資源。說明您可以在控制台的效能監控頁面選擇數據節點，然後將自訂監控項設定為Pub/Sub監控組，即可查看各資料分區（預設展示第一個資料分區）中發布與訂閱（Pub/Sub）相關命令的監控資訊。阿里雲自研的命令使用阿里雲自研的命令（例如IINFO、ISCAN等）時，如果通過idx參數指定了資料分區ID，Proxy會將這些命令發送到指定的資料分區。更多資訊，請參見阿里雲自研的Proxy命令。
讀寫分離架構	基礎轉寄規則	寫請求：Proxy將其直接轉寄到主節點（Master）。讀請求：Proxy將讀請求平均分配到主節點和唯讀節點，暫不支援自訂控制。例如擁有3個唯讀節點的執行個體，主節點和3個唯讀節點的讀權重均為25%。說明 SLOWLOG和DBSIZE也屬於讀命令。
讀寫分離架構	特定命令轉寄規則	SCAN類命令當您執行HSCAN、SSCAN、ZSCAN命令時，Proxy會先計算Key所屬的Slot，然後通過模數計算確定目標節點，從而將請求均勻分配至主節點和唯讀節點。阿里雲自研的命令使用阿里雲自研的命令（例如RIINFO、RIMONITOR等）時，可通過ro_slave_idx參數指定該命令要轉寄到的唯讀節點，通過idx參數指定該命令要轉寄到的資料分區。更多資訊，請參見阿里雲自研的Proxy命令。其他命令 Proxy會將事務命令（MULTI或EXEC）、Lua指令碼命令（EVAL或EVALSHA）、SCAN、INFO、發布訂閱命令（PUBLISH、SUBSCRIBE等）轉寄至主節點。

代理查詢快取

代理節點支援緩衝：包含熱點Key的請求和對應查詢結果。當Proxy在緩衝有效期間內收到同樣請求時，將直接返回結果至用戶端，無需和後端的資料分區互動。本功能可緩解或預防熱點Key讀請求引發的訪問效能傾斜問題。

此熱點Key與Top Key統計功能中的熱Key（QPS）一致，由資料庫核心根據排序和統計演算法進行識別。預設為Key的QPS超過5000，也可以通過bigkey-threshold參數自訂閾值。
若熱點Key在緩衝有效期間內被修改，其修改結果不會同步至緩衝中。即後續請求可能會讀到緩衝中的髒資料，直至緩衝失效。對此，您可以根據實際情況縮短緩衝有效期間。

說明

Proxy節點並不緩衝整個熱點Key，而是緩衝包含熱點Key的請求和對應查詢結果。
本功能僅支援Tair記憶體型、持久記憶體型執行個體，且執行個體為叢集架構代理模式或讀寫分離架構。

應用情境

適用於熱搜榜單、大V使用者資訊、遊戲公告等情境，應用程式能夠容忍稍舊的資料。

功能架構

使用方法

本功能預設關閉，您可以設定query_cache_enabled參數開啟該功能。

查看使用方法詳細說明

參數	說明

query_cache_enabled	代理節點查詢快取功能。啟用後，代理節點會緩衝熱點Key對應的請求和查詢結果，當在有效時間內收到同樣的請求時直接返回結果至用戶端，無需和後端的資料分區互動。重要由於代理節點中緩衝的熱點Key的索引值對資訊在有效時間內不會更新，在啟用該功能前，您需要確認業務上是否允許資料在緩衝有效時間內的最終一致性。 query_cache_enabled：是否啟用該功能。取值為0（不啟用、預設）、1（啟用）。 query_cache_expire：快取資料的有效時間，單位為毫秒，取值範圍為[100-60000]，預設為1000。若快取資料在有效期間內被修改，修改後的資料不會同步至緩衝中，即相同的讀請求會擷取到緩衝中的髒資料，直至緩衝失效。您需要根據具體的業務情境和對髒資料的容忍度謹慎評估該參數的值，該值設定過小會降低緩衝的命中率，設定過大會導致用戶端在較長的時間內讀取到的是髒資料。 query_cache_mode：代理節點查詢快取功能的工作模式，取值如下。 0（預設）：只快取資料分區推送的熱點Key。 1：緩衝所有Key並進行根據最近最少使用演算法LRU（Least Recently Used）進行淘汰。由於代理節點的緩衝空間有限（代理節點每個線程100 MB），若設定該參數的值為1，代理節點將按照LRU演算法淘汰Key，可能降低緩衝的命中率，從而引起整體效能的下降。
query_cache_expire
query_cache_mode

您可以通過Tair自研的QUERYCACHE KEYS、QUERYCACHE INFO、QUERYCACHE LISTALL命令，查看代理查詢快取的使用方式。

查看使用方式

QUERYCACHE KEYS

命令格式：QUERYCACHE KEYS

命令描述：查詢代理節點中已緩衝的所有熱點Key，將返回每個熱點Key的資料庫名和Key名稱資訊。

命令樣本：

QUERYCACHE KEYS

返回樣本：

1) 1) (integer) 0
   2) "key:000000000003"
2) 1) (integer) 0
   2) "key:000000000001"
3) 1) (integer) 0
   2) "key:000000000002"
4) 1) (integer) 0
   2) "key:000000000000"

QUERYCACHE INFO

命令格式：QUERYCACHE INFO

命令描述：擷取代理查詢快取的運行情況。

命令樣本：

QUERYCACHE INFO

返回樣本：

1) "put_qps:4.00"
2) "get_qps:16570.00"
3) "hit_rate:99.98"
4) "memory_size:180"
5) "query_count:4"
6) "bandwidth_limit_query_cnt:0"
7) "qps_limit_query_cnt:0"

返回樣本說明：

put_qps：資料節點每秒往Querycache寫入的次數。
get_qps：用戶端每秒從Querycache中讀取的次數。
hit_rate：緩衝的命中率。
memory_size：快取資料佔用的記憶體容量，單位為位元組。
query_count：已緩衝的請求的數量。
bandwidth_limit_query_cnt：因頻寬節流設定訪問Querycache被限流的次數，預設未開啟限制。
qps_limit_query_cnt：因QPS限制訪問Querycache被限流的次數，預設未開啟限制。

QUERYCACHE LISTALL

命令格式：QUERYCACHE LISTALL

命令描述：擷取已緩衝的所有請求命令。

命令樣本：

QUERYCACHE LISTALL

返回樣本：

1) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000000\r\n"
   3) (integer) 668
2) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000001\r\n"
   3) (integer) 668
3) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000003\r\n"
   3) (integer) 668
4) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000002\r\n"
   3) (integer) 667

返回樣本說明：每個請求命令的資訊由三行資訊組成，分別為資料庫名、請求命令的完整內容（格式遵照Redis協議規範）、剩餘存留時間（單位為毫秒）。

串連數使用說明

通常情況下，Proxy通過與資料分區建立長串連來處理請求。當請求中包含以下命令時，Proxy會根據命令的處理需求在相應的資料分區上建立額外的串連，此時串連無法彙總，執行個體的最大串連數會受到資料節點單個分區的限制（單個分區的限制請參見具體的執行個體規格）。您需要合理使用下述命令，避免串連數超限。

說明

代理模式下，Redis社區版執行個體每個資料分區的串連數上限為10,000，Tair（企業版）執行個體每個資料分區的串連數上限為30,000。

阻塞類命令：BRPOP、BRPOPLPUSH、BLPOP、BZPOPMAX、BZPOPMIN、BLMOVE、BLMPOP、BZMPOP。
事務類命令：MULTI、EXEC、WATCH。
MONITOR類命令：MONITOR、IMONITOR、RIMONITOR。
訂閱命令：SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE、SSUBSCRIBE、SUNSUBSCRIBE。

常見問題

Q：是否支援將只進行讀操作的Lua指令碼轉寄至唯讀節點嗎？
A：支援，但需要滿足以下條件。
- 使用唯讀帳號，更多資訊請參見建立與管理帳號。
- 將執行個體的readonly_lua_route_ronode_enable參數的值設定為1，即僅包含讀操作的Lua指令碼會被轉寄到唯讀副本處理。具體操作，請參見設定參數。
Q：代理（Proxy）模式和直連模式有什麼區別，推薦使用什麼模式？
A：推薦使用代理模式，介紹與區別如下：
- 代理模式：用戶端的請求由代理節點轉寄至資料分區，可享受代理節點帶來的負載平衡、讀寫分離、容錯移轉、代理查詢快取、長串連等特效能力。
- 直連模式：可通過直連地址繞過代理，直接存取後端的資料分區（類似串連原生Redis叢集）。相比代理模式，直連模式節約了通過代理處理請求的時間，可以在一定程度上提高Redis服務的響應速度。

Q：如果後端的某個資料分區出現異常，對資料讀寫有什麼影響？

A：資料分區均採用主備高可用架構，當主節點發生故障後，系統會自動進行主備切換保證服務高可用。在特別極端情境下某個資料分區出現異常後，對資料的影響及最佳化方案如下。

情境	影響與最佳化方案
圖 1. 多Key命令情境	影響：用戶端通過4個串連發送4個請求，當資料分區2處於異常狀態時，僅有請求1（GET Key1可正常讀取到資料），其他請求會訪問到資料分區2會返回逾時。最佳化方案：降低多Key命令（例如MGET）的使用頻率，或降低一次請求中包含的Key的數量，避免因單個資料分區異常導致該請求全部返回失敗。降低事務類命令的使用頻率或降低事務大小，避免因某個子事務失敗導致整個事務失敗。
圖 2. 單串連情境	影響：用戶端通過1個串連分別發送2個請求，當資料分區2處於異常狀態時，請求2（GET Key2）將返回逾時，同時由於請求1（GET Key1）和請求2共用同一串連，導致請求1也無法正常返回。最佳化方案：避免或降低對pipeline的使用。避免使用單串連的用戶端，推薦使用串連池的用戶端，例如用戶端程式串連教程（需設定合理的逾時時間和串連池大小）。