907      iPhone_iPad_Mac_手機_平板_蘋果apple

設置熱點 Key__用戶指南_雲數據庫 Memcache 版-阿裏雲

熱點 Key 技術詳情

背景信息

在分布式 K-V 存儲係統中，對某個 key 進行讀寫時，會根據該 key 的 hash 計算出一台固定的 server 來存取該 K-V，如果集群不發生服務器數量變化，那麼這一映射關係就不會變化。

雲數據庫 Memcache 版就是這樣一種 K-V 緩存係統。因此在實際應用中，某些高峰時段，有的雲數據庫 Memcache 版用戶會大量請求同一個 Key（可能對應應用的熱賣商品、熱點新聞、熱點評論等），所有的請求（且這類請求讀寫比例非常高）都會落到同一個 server 上，該機器的負載就會嚴重加劇，此時整個係統增加新 server 也沒有任何用處，因為根據 hash 算法，同一個 key 的請求還是會落到同一台新機器上，該機器依然會成為係統瓶頸。這個問題稱為“熱點key”問題。

現狀

用戶使用雲數據庫 Memcache 版就是為了提升業務性能，難免會觸發“熱點key問題”。但雲數據庫 Memcache 版做為公共雲服務，在發現有熱點的情況下，如果繼續放任該熱點無限激增，就會帶來整個係統宕機。所以當前的做法會對每個用戶在每台服務器上分配一定的 QPS 或帶寬，當用戶在某台服務器上的請求超過該用戶的配額，我們就會對用戶進行流控，服務端返回 TEMPORARY_FAILURE。該限製會影響用戶正常請求，持續時間分鍾級。

解決方案

雲數據庫 Memcache 版簡單架構圖如下。

proxy 是無狀態層，上麵做了些訪問控製功能，用戶客戶端到 proxy 是隨機的，不受固定算法（如 hash）控製。而 proxy 到 DataServer 的鏈路是根據 key 決定的，當用戶訪問熱點 key 時，所有 proxy 上關於該 key 的請求都會落到同一台 DataServer。

所以解決熱點問題，其核心思路是：每台 DataServer 對所有 key 進行采樣、定位，實時計算出當前熱點 key，將其反饋給 proxy 層，由 proxy 緩存備份。即負載壓力由 DataServer 轉向 proxy，因為 proxy 可以無狀態擴容，而 DataServer 不可以。

DataServer如何發現熱點？

每台服務器有個 HotKey 邏輯，讓每個到達服務器的目標請求（可配置不同類型請求）經曆三個流水階段。流程圖如下。

• 采樣階段（根據配置設定采樣次數 sample_max）

  本階段輸出：是否有熱點現象，如果有熱點，輸出熱點的桶號供下階段使用。

• 定位階段（根據配置設定采樣次數 reap_max）

  本階段輸出：熱點 key（如果滿足閾值）。 並添加到服務端的 LRU 鏈表。

• 反饋階段

  對到達服務器的目標請求，取出 key，然後查詢 LRU 鏈表判斷該 key 是否為熱點 key。如果是熱點，就會在請求結束後，向 proxy 發送一個 feedback 包，通知 proxy。至此，服務器 HotKey 邏輯結束。

發現熱點後 proxy 怎麼處理？

當 proxy 收到 DataServer 的熱點反饋之後，會將該 key 寫入到自己的 LRU-cache 裏麵。這樣，熱點的 key 就已經存在於與 proxy 中了，下次用戶請求就可以直接返回了。

如何保證數據一致性呢？

下麵討論都是用戶 client 已經觸發了熱點 key 問題，假設用戶 client 跟每個 proxy 都建立了鏈接，並且每個 proxy 上都有對熱點 key 的請求，那麼理論上每個 proxy 的 LRU-cache 都有一份數據。

保證單條連接上的一致性

當用戶 client 和 proxy1 建立連接，用戶修改了一個 key（任何寫操作），proxy1 上會在 LRU-cache 中同步刪除該 key，新 key 就會寫到 DataServer 上，然後在讀數據的時候，由於 LRU-cache 不命中，就會 從DataServer 上拿到最新數據。

不同鏈接上隻能提供弱一致性

如果這個時候用戶從 proxy2 上讀熱點數據呢？理論上就會讀到老數據，該數據將於100 ms之後從 proxy-cache 中過期淘汰掉，之後就會更新會最新數據，即不同連接間可能有100 ms 不一致。

怎樣看待弱一致性

事實上，不開啟熱點 key 功能，在不同鏈接上也會存在弱一致。假設用戶 client 建立了兩條鏈接到雲數據庫 Memcache 版，在鏈接1上寫 入key-value1，在鏈接1、2上分別讀該 key。當鏈接1上用戶 update 了 key-value2，這個請求需要一定的網絡延遲才能寫入到服務端，如果這個時候鏈接2上同時發起對 key 的讀取操作，如果讀請求先到服務端，它將讀到的是 value1 的老值。

所以開啟熱點 key 功能，隻是增加了不一致時間，且該功能為可選。控製權由用戶掌握。

適用場景

開啟熱點 key功 能之後，隻會對用戶的讀請求產生影響，該影響增加了不同鏈接上的弱一致性的時間。因此，該功能適合讀多寫少，且對強一致性要求不高的應用。收益整個方案核心是負載壓力由 DataServer 轉移到 proxy。好處如下：

• 因為 DataServer 擴容也解決不了熱點問題，而 proxy 可以無狀態擴容，對用戶來講就極大提升了熱點 key 訪問的能力，不受單點製約。

• 縮短了服務端處理鏈路，對用戶平均 RT 也所降低。

• 免除服務端熱點流控的分鍾級別影響。

操作步驟

開啟熱點 Key 模式，可以有效提升高峰業務時段的響應能力。

1. 登錄 Memcache 管理控製台。

2. 在實例列表頁麵，定位到目標實例。

3. 單擊實例右側的管理，進入到基本信息頁麵。

4. 在左側導航欄選擇熱點 Key 設置。

5. 選擇開啟熱點 Key 模式。

最後更新：2016-12-14 14:57:00

  上一篇： 免密碼訪問__用戶指南_雲數據庫 Memcache 版-阿裏雲

  下一篇： 監控與報警__用戶指南_雲數據庫 Memcache 版-阿裏雲