主要優勢
類別 | 說明 |
相容性 | |
效能 | 採用多執行緒模式,效能約為同規格Redis開源版的3倍,能夠突破熱點資料高頻讀寫受到的效能限制。 相比原生Redis,高QPS情境下回應時間更低,效能表現更佳。 在大並發情境下運行穩定,可以極大地緩解突發大量請求導致的串連問題,從容應對業務高峰。 全量同步和增量同步處理在IO線程中進行,提高同步速度。
|
部署架構 | |
資料結構模組整合 | |
企業級特性 | |
資料安全 | |
適用情境
適用於ApsaraVideo for Live、電商秒殺和線上教育等情境,下面列舉了記憶體型在4個典型情境中的應用。
情境1:使用Redis開源版執行個體在秒殺情境中構建緩衝,部分熱點Key的QPS要求高達20萬以上,無法滿足業務高峰期的需求。
採用記憶體型(標準架構)執行個體後,熱門商品秒殺過程流暢,未發生效能問題。
情境2:在業務中使用Redis開源版叢集執行個體,但在使用事務和Lua指令碼功能時有一定的限制。
採用記憶體型執行個體後,在滿足效能需求的同時消除了叢集版的命令使用限制。
情境3:自建有一主多備的Redis服務,隨著業務中訪問量的不斷提高,備節點數量也要隨之增加,管理維護成本越來越高。
採用具備一個資料節點五個唯讀副本的記憶體型(讀寫分離架構)執行個體後,可以輕鬆應對百萬級QPS的業務挑戰。
情境4:自建有Redis叢集來承擔線上千萬級QPS的業務壓力。隨著業務的發展,Redis分區數不斷增加,管理維護成本居高不下。
採用記憶體型(叢集架構)執行個體後,叢集規模縮到原來的三分之一,管理維護成本大幅降低。
執行緒模式對比
線程架構 | 說明 |
圖 1. Redis單執行緒模式 | Redis開源版和原生Redis採用單執行緒模式,資料處理流程為:讀取請求,解析請求,處理資料,發送響應。其中網路IO和請求解析佔用了大部分的資源。 |
圖 2. Tair多執行緒模式 | Tair記憶體型將服務各階段的任務進行分離,通過分工明確的多個線程平行處理各階段任務,達到提高效能的目的。 IO線程:負責請求讀取、響應發送、命令解析等。 Worker線程:負責命令處理、定時器事件等。 輔助線程:負責高可用探測、保活等。
IO線程讀取使用者的請求並進行解析,之後將解析結果以命令的形式放在隊列中發送給Worker線程處理。Worker線程將命令處理完成後產生響應,通過另一條隊列發送給IO線程。 Tair記憶體型最多支援4個IO線程並發運行。為了提高線程的並行度,IO線程和Worker線程之間採用無鎖隊列和管道進行資料交換。 說明 對於通用的類型,例如:String、List、Set、Hash、Zset、 Hyperloglog、Geo以及擴充結構都有很好的加速效果。 對於Pub、Sub、Blocking系列API,由於其複製是在worker中完成的,可被加速提升吞吐,效能提升約50%。 由於Transaction、Lua script要求串列執行,無加速效果。
|
說明
區別於Redis 6.0的多線程(效能至多提升2倍,且CPU資源消耗高),記憶體型的Real Multi-IO能夠將IO加速地更徹底,具備更高的抗串連衝擊性,且可以線性地提升吞吐能力。
效能對比
Redis開源版執行個體採用與原生Redis相同的單執行緒模式,每個資料節點支援8萬到10萬的QPS;Tair記憶體型採用多執行緒模式,由IO線程、Worker線程和輔助線程共同完成資料處理,單節點效能為Redis開源版執行個體的3倍左右。下表展示了不同架構下,Redis開源版和Tair記憶體型執行個體的適用情境對比。
架構 | Redis開源版 | Tair記憶體型 |
標準架構 | 不適用於單節點QPS要求超過10萬的情境。 | 可應用於QPS高於10萬的情境。 |
叢集架構 | 包含多個資料節點,每個節點的效能與標準版執行個體相似。當某個節點儲存了熱度較高的資料並面臨大並發量的請求時,該節點中其它資料的讀寫可能受到影響,形成效能瓶頸。 | 能更好地應對熱讀寫,降低維護成本。 |
讀寫分離架構 | 有較高的讀效能,在讀多寫少的情境表現良好,但不適用於大並發寫入的情境。 | 既有較高的讀效能,又能承受大並發寫入,適用於寫請求多而讀請求更多的情境。 |
常見問題
Q:用戶端不支援新模組的命令怎麼辦?
A:您可以先在應用代碼中定義需要使用的新模組命令,然後再使用這些命令,或者通過Tair用戶端直接調用Tair擴充資料結構,更多資訊,請參見Clients說明。