云數據庫 Tair（兼容 Redis）擁有極強的性能，阿里云結合多年的運維經驗，從業(yè)務部署、Key的設計、SDK、命令、運維管理等維度展示云數據庫 Tair（兼容 Redis）開發(fā)運維規(guī)范，為您設計高效的業(yè)務系統(tǒng)提供參考，幫助您充分發(fā)揮Tair的能力。
了解Tair性能邊界
圖 1. Tair性能邊界
資源類別 | 說明 |
計算資源 | 使用通配符、Lua并發(fā)、1對多的PUBSUB、熱點Key等會大量消耗計算資源，集群架構下還會導致訪問傾斜，無法有效利用所有數據分片。 |
存儲資源 | Streaming慢消費、大Key等會占用大量存儲資源，集群架構下還會導致數據傾斜，無法有效利用所有數據分片。 |
網絡資源 | 掃描全庫（KEYS命令）、大Value、大Key的范圍查詢（如HGETALL命令）等會消耗大量的網絡資源，且極易引發(fā)線程阻塞。 重要 Tair的高并發(fā)能力不等同于高吞吐能力，例如將大Value存在Tair里以期望提升訪問性能，此類場景往往不會有特別大的收益，反而會影響Tair整體的服務能力。 |
集群架構下，熱點Key、大Key或大Value等還會引發(fā) 存儲或訪問傾斜 ，在生產環(huán)境中，您應當避免觸達Tair的性能邊界。
業(yè)務部署規(guī)范
重要程度 | 規(guī)范 | 說明 |
★★★★★ | 確定使用場景為 高速緩存 或 內存數據庫 。 |
|
★★★★★ | 就近部署業(yè)務，例如將業(yè)務部署在同一個專有網絡VPC下的ECS實例中。 | Tair具備極強的性能，如果部署位置過遠（例如業(yè)務服務器與Tair實例通過公網連接），網絡延遲將極大影響讀寫性能。 說明 針對多地部署應用的場景，您可以通過全球多活功能，借助其提供的跨域復制（Geo-replication）能力，快速實現(xiàn)數據異地災備和多活，降低網絡延遲和業(yè)務設計的復雜度。更多信息，請參見Tair全球多活簡介。 |
★★★★☆ | 為每個業(yè)務提供單獨的Tair實例。 | 避免業(yè)務混用，尤其需要避免將同一Tair實例同時用作高速緩存和內存數據庫業(yè)務。帶來的影響例如針對某個業(yè)務淘汰策略設置、產生的慢請求或執(zhí)行FLUSHDB命令影響將擴散至其他業(yè)務。 |
★★★★☆ | 設置合理的過期淘汰策略。 | Tair默認的默認逐出策略為 volatile-lru ，關于各逐出策略的說明，請參見Redis配置參數列表。 |
★★★☆☆ | 合理控制壓測的數據和壓測時間。 | Tair不會對您壓測的數據執(zhí)行自動刪除操作，您需要自行控制壓測數據的數據量和壓測時間，避免對業(yè)務造成影響。 |
Key設計規(guī)范
重要程度 | 規(guī)范 | 說明 |
★★★★★ | 設計合理的Key中Value的大小，推薦小于10 KB。 | 過大的Value會引發(fā)數據傾斜、熱點Key、實例流量或CPU性能被占滿等問題，應從設計源頭上避免此類問題帶來的影響。 |
★★★★★ | 設計合理的Key名稱與長度。 |
|
★★★★★ | 對于支持子Key的復雜數據結構，應避免一個Key中包含過多的子Key（推薦低于1,000）。 說明 常見的復雜數據結構例如Hash、Set、Zset、Geo、Stream及Tair（企業(yè)版）特有的exHash、Bloom、TairGIS等。 | 由于某些命令（例如HGETALL）的時間復雜度直接與Key中的子Key數量相關。如果頻繁執(zhí)行時間復雜度為O(N)及以上的命令，且Key中的子Key數量過多容易引發(fā)慢請求、數據傾斜或熱點Key問題。 |
★★★★☆ | 推薦使用串行化方法將Value轉變?yōu)榭勺x的結構。 | 由于編程語言的字節(jié)碼隨著版本可能會變化，如果存儲裸對象（例如Java Object、C#對象）會導致整個軟件棧升級困難，推薦使用串行化方法將Value變成可讀的結構。 |
SDK使用規(guī)范
重要程度 | 規(guī)范 | 說明 |
★★★★★ | 推薦使用JedisPool或者JedisCluster連接實例。 說明 Tair（企業(yè)版）內存型實例推薦使用TairJedis客戶端，支持新數據結構的封裝類。使用方法，請參見客戶端程序連接Redis。 | 如果使用單連接的方式，一旦遇到單次超時則無法自動恢復。關于JedisPool的連接方法，請參見客戶端程序連接Redis、JedisPool資源池優(yōu)化和JedisCluster。 |
★★★★☆ | 程序客戶端需要對超時和慢請求做容錯處理。 | 由于Tair服務可能因網絡波動或資源占滿引發(fā)超時或慢請求，您需要在程序客戶端上設計合理的容錯機制。 |
★★★★☆ | 程序客戶端應設置相對寬松的超時重試時間。 | 如果超時重試時間設置的非常短（例如200毫秒以下），可能引發(fā)重試風暴，極易引發(fā)業(yè)務層雪崩。更多信息，請參見Redis客戶端重連指南。 |
命令使用規(guī)范
重要程度 | 規(guī)范 | 說明 |
★★★★★ | 避免執(zhí)行范圍查詢（例如KEYS *），使用多次單點查詢或SCAN命令來獲取延遲優(yōu)勢。 | 執(zhí)行范圍查詢可能導致服務發(fā)生抖動、引發(fā)慢請求或產生阻塞。 |
★★★★★ | 推薦使用擴展數據結構（數據結構模塊集成）實現(xiàn)復雜功能，避免使用Lua腳本。 | Lua腳本會占用較多的計算和內存資源，且無法被多線程加速，過于復雜或不合理的Lua腳本可能導致資源被占滿的情況。 |
★★★★☆ | 合理使用管道（pipeline）降低鏈路的往返時延RTT（Round-trip time）。 | 如果有多個操作命令需要被迅速提交至服務器端，且客戶端不依賴每個操作返回的結果，那么可以通過管道來作為優(yōu)化性能的批處理工具，注意事項如下：
|
★★★★☆ | 正確使用Redis命令。 | 使用事務（Transaction）時，需要注意其限制：
|
★★★★☆ | 避免使用Redis命令執(zhí)行大量的消息分發(fā)工作。 | 由于Pub和Sub不支持數據持久化，且不支持ACK應答機制無法實現(xiàn)數據可靠性，當執(zhí)行大量消息分發(fā)工作時（例如訂閱客戶端數量超過100且Value超過1 KB），訂閱客戶端可能因服務端資源被占滿而無法接收到數據。 說明 為提升性能和均衡性，Tair對Pub和Sub類命令進行了優(yōu)化，集群架構下，代理節(jié)點會根據channel name進行Hash計算，并分配至對應數據節(jié)點。 |
運維管理規(guī)范
重要程度 | 規(guī)范 | 說明 |
★★★★★ | 充分了解不同的實例管理操作帶來的影響。 | 在對Tair實例執(zhí)行變更配置、重啟等操作時，實例的狀態(tài)將發(fā)生變化并產生某些影響（例如產生秒級的連接閃斷），在操作前您需要充分了解。更多信息，請參見實例狀態(tài)與影響。 |
★★★★★ | 驗證客戶端程序的差錯處理能力或容災邏輯。 | Tair支持節(jié)點健康狀態(tài)監(jiān)測，當監(jiān)測到實例中的主節(jié)點不可用時，會自動觸發(fā)主備切換，保障實例的高可用性。在客戶端程序正式上線前，推薦手動觸發(fā)主備切換，可幫助您驗證客戶端程序的差錯處理能力或容災邏輯。具體操作，請參見手動執(zhí)行主備切換。 |
★★★★★ | 禁用高耗時或高風險的命令。 | 生產環(huán)境中，無限制地使用命令可能帶來諸多問題，例如執(zhí)行FLUSHALL會直接清空全部數據；執(zhí)行KEYS會阻塞Redis服務。為保障業(yè)務穩(wěn)定、高效率地運行，您可以根據實際情況禁用特定的命令，具體操作，請參見禁用高風險命令。 |
★★★★☆ | 及時處理阿里云發(fā)起的計劃內運維操作（即待處理事件） | 為提供更優(yōu)質的服務，持續(xù)提升產品性能和穩(wěn)定性，阿里云會不定期地發(fā)起計劃內運維操作（即待處理事件），對部分實例所屬的機器執(zhí)行軟硬件或網絡換代升級（例如數據庫小版本升級）。當您收到來自阿里云的事件通知后，您可以查看本次事件的影響，根據業(yè)務需求評估是否需要調整執(zhí)行時間。更多信息，請參見查看并管理計劃內事件。 |
★★★★☆ | 為核心指標配置監(jiān)控報警，幫助掌握實例運行狀態(tài)。 | 為CPU使用率、內存使用率、帶寬使用率等核心指標配置監(jiān)控報警，實時掌握實例運行狀態(tài)。具體操作，請參見報警設置。 |
★★★★☆ | 通過Tair提供的豐富的運維功能，定期檢查實例狀態(tài)或輔助排查資源消耗異常問題。 |
|
★★★☆☆ | 評估并開啟審計日志功能。 | 開通審計日志功能后，可記錄寫操作的審計信息，為您提供日志的查詢、在線分析、導出等功能，助您時刻掌握產品安全及性能情況。更多信息，請參見開通審計日志。 重要 開通審計日志后，視寫入量或審計量可能會對Tair實例造成5%～15%的性能損失。如果業(yè)務對Tair實例的寫入量非常大，建議僅在運維需要（例如故障排查）期間開通審計功能，以免帶來性能損失。 |