Tair (Redis® OSS-Compatible)：Tair（Redis OSS-compatible）開發營運規範

資源類別

說明

計算資源

使用萬用字元、Lua並發、1對多的PUBSUB、熱點Key等會大量消耗計算資源，叢集架構下還會導致訪問傾斜，無法有效利用所有資料分區。

儲存資源

Streaming慢消費、大Key等會佔用大量儲存資源，叢集架構下還會導致資料扭曲，無法有效利用所有資料分區。

網路資源

掃描全庫（KEYS命令）、大Value、大Key的範圍查詢（如HGETALL命令）等會消耗大量的網路資源，且極易引發線程阻塞。

重要程度

規範

說明

★★★★★

• 快取：建議關閉AOF以降低開銷，同時，由於資料可能會被淘汰，業務設計上避免強依賴緩衝中的資料。例如Tair被寫滿後，會觸發資料淘汰策略以挪移出空間給新的資料寫入，根據業務的寫入量會相應地導致延遲升高。

  重要

  如需使用通過資料閃回按時間點恢複資料功能，AOF功能需保持開啟狀態。

• 記憶體資料庫：應選購Tair（企業版）持久記憶體型，支援命令級持久化，同時應通過監控警示關注記憶體使用量率。具體操作，請參見警示設定。

★★★★★

就近部署業務，例如將業務部署在同一個Virtual Private Cloud下的ECS執行個體中。

Tair具備極強的效能，如果部署位置過遠（例如商務服務器與Tair執行個體通過公網串連），網路延遲將極大影響讀寫效能。

★★★★☆

為每個業務提供單獨的Tair執行個體。

避免業務混用，尤其需要避免將同一Tair執行個體同時用作快取和記憶體資料庫業務。帶來的影響例如針對某個業務淘汰原則設定、產生的慢請求或執行FLUSHDB命令影響將擴散至其他業務。

★★★★☆

設定合理的到期淘汰策略。

Tair預設的預設逐出策略為 volatile-lru ，關於各逐出策略的說明，請參見Redis開源版配置參數列表。

★★★☆☆

合理控制壓測的資料和壓測時間。

Tair不會對您壓測的資料執行自動刪除操作，您需要自行控制壓測資料的資料量和壓測時間，避免對業務造成影響。

重要程度

規範

說明

★★★★★

設計合理的Key中Value的大小，推薦小於10 KB。

過大的Value會引發資料扭曲、熱點Key、執行個體流量或CPU效能被佔滿等問題，應從設計源頭上避免此類問題帶來的影響。

★★★★★

設計合理的Key名稱與長度。

• Key名稱：

  • 使用可讀字串作為Key名，如果使用Key名拼接庫、表和欄位名時，推薦使用英文冒號（:）分隔。例如project:user:001。

  • 在能完整描述業務的前提下，盡量簡化Key名的長度，例如username可簡化為u。

  • 由於大括弧（{}）為Redis的hash tag語義，如果使用的是叢集架構的執行個體，Key名稱需要正確地使用大括弧避免 引發資料扭曲 ，更多資訊，請參見keys-hash-tags。

    說明

    叢集架構下執行同時操作多個Key的命令時（例如RENAME命令），如果被操作的Key未使用hash tag讓其處於相同的資料分區，則命令無法正常執行。

• 長度：推薦Key名的長度不超過128位元組（越短越好）。

★★★★★

對於支援子Key的複雜資料結構，應避免一個Key中包含過多的子Key（推薦低於1,000）。

由於某些命令（例如HGETALL）的時間複雜度直接與Key中的子Key數量相關。如果頻繁執行時間複雜度為O(N)及以上的命令，且Key中的子Key數量過多容易引發慢請求、資料扭曲或熱點Key問題。

★★★★☆

推薦使用序列化方法將Value轉變為可讀的結構。

由於程式設計語言的位元組碼隨著版本可能會變化，如果儲存裸對象（例如Java Object、C#對象）會導致整個軟體棧升級困難，推薦使用序列化方法將Value變成可讀的結構。

重要程度

規範

說明

★★★★★

推薦使用JedisPool或者JedisCluster串連執行個體。

如果使用單串連的方式，一旦遇到單次逾時則無法自動回復。關於JedisPool的串連方法，請參見用戶端程式串連教程、JedisPool資源集區最佳化和JedisCluster。

★★★★☆

程式用戶端需要對逾時和慢請求做容錯處理。

由於Tair服務可能因網路波動或資源佔滿引發逾時或慢請求，您需要在程式用戶端上設計合理的容錯機制。

★★★★☆

程式用戶端應設定相對寬鬆的逾時重試時間。

如果逾時重試時間設定的非常短（例如200毫秒以下），可能引發重試風暴，極易引發業務層雪崩。更多資訊，請參見Tair用戶端重連指南。

重要程度

規範

說明

★★★★★

避免執行範圍查詢（例如KEYS *），使用多次單點查詢或SCAN命令來擷取延遲優勢。

執行範圍查詢可能導致服務發生抖動、引發慢請求或產生阻塞。

★★★★★

推薦使用擴充資料結構（資料結構模組整合）實現複雜功能，避免使用Lua指令碼。

Lua指令碼會佔用較多的計算和記憶體資源，且無法被多線程加速，過於複雜或不合理的Lua指令碼可能導致資源被佔滿的情況。

★★★★☆

合理使用管道（pipeline）降低鏈路的往返時延RTT（Round-trip time）。

如果有多個操作命令需要被迅速提交至伺服器端，且用戶端不依賴每個操作返回的結果，那麼可以通過管道來作為最佳化效能的批處理工具，注意事項如下：

• 管道執行期間用戶端將獨佔與伺服器端的串連，推薦為管道單獨建立一個串連，將其與常規操作分離。

• 每個管道應包含合理的命令數量（不超過100個）。

★★★★☆

正確使用Redis命令。

使用事務（Transaction）時，需要注意其限制：

• 不同於關係型資料庫的事務功能，Redis的事務功能不支援復原（Rollback）。

• 對於叢集架構的執行個體，需要使用hash tag確保命令所要操作的Key都分布在1個Hash槽中，同時還需要避免hash tag帶來的儲存傾斜問題。

• 避免在Lua指令碼中封裝事務命令，可能因編譯載入消耗較多的計算資源。

★★★★☆

避免使用Redis命令執行大量的訊息分發工作。

由於Pub和Sub不支援資料持久化，且不支援ACK應答機制無法實現資料可靠性，當執行大量訊息分發工作時（例如訂閱用戶端數量超過100且Value超過1 KB），訂閱用戶端可能因服務端資源被佔滿而無法接收到資料。

重要程度

規範

說明

★★★★★

充分瞭解不同的執行個體管理操作帶來的影響。

在對Tair執行個體執行變更配置、重啟等操作時，執行個體的狀態將發生變化併產生某些影響（例如產生秒級的串連閃斷），在操作前您需要充分瞭解。更多資訊，請參見執行個體狀態與影響。

★★★★★

驗證用戶端程式的差錯處理能力或容災邏輯。

Tair支援節點健康狀態監測，當監測到執行個體中的主節點不可用時，會自動觸發主備切換，保障執行個體的高可用性。在用戶端程式正式上線前，推薦手動觸發主備切換，可協助您驗證用戶端程式的差錯處理能力或容災邏輯。具體操作，請參見手動執行主備切換。

★★★★★

禁用高耗時或高風險的命令。

生產環境中，無限制地使用命令可能帶來諸多問題，例如執行FLUSHALL會直接清空全部資料；執行KEYS會阻塞Redis服務。為保障業務穩定、高效率地運行，您可以根據實際情況禁用特定的命令，具體操作，請參見禁用高風險命令。

★★★★☆

及時處理阿里雲發起的計劃內營運操作（即待處理事件）

為提供更優質的服務，持續提升產品效能和穩定性，阿里雲會不定期地發起計劃內營運操作（即待處理事件），對部分執行個體所屬的機器執行軟硬體或網路換代升級（例如資料庫小版本升級）。當您收到來自阿里雲的事件通知後，您可以查看本次事件的影響，根據業務需求評估是否需要調整執行時間。更多資訊，請參見查看並管理計劃內事件。

★★★★☆

為核心指標配置監控警示，協助掌握執行個體運行狀態。

為CPU使用率、記憶體使用量率、頻寬使用率等核心指標配置監控警示，即時掌握執行個體運行狀態。具體操作，請參見警示設定。

★★★★☆

通過Tair提供的豐富的營運功能，定期檢查執行個體狀態或輔助排查資源消耗異常問題。

• 分析慢日誌：協助您快速找到慢請求問題發生的位置，定位發出請求的用戶端IP，為徹底解決逾時問題提供可靠的依據。

• 查看效能監控：Tair支援豐富的效能監控指標，協助您掌握Redis服務的健全狀態和進行問題溯源。

• 發起執行個體診斷：協助您從效能水位、訪問傾斜情況、慢日誌等多方面評估執行個體的健康情況，快速定位執行個體的異常情況。

• 發起緩衝分析：協助您快速發現執行個體中的大Key，協助您掌握Key在記憶體中的佔用和分布、Key到期時間等資訊。

• 即時Top Key統計：協助您快速發現執行個體中的熱點Key，為進一步的最佳化提供資料支援。

★★★☆☆

評估並開啟審計日誌功能。

開通審計日誌功能後，可記錄寫操作的審計資訊，為您提供日誌的查詢、線上分析、匯出等功能，助您時刻掌握產品安全及效能情況。更多資訊，請參見開通審計日誌。