若是20萬用戶同時訪問一個熱點緩存，如何優化你的緩存架構？【石杉的架構筆記】

時間 2019-11-06

標籤若是萬用同時訪問一個熱點緩存如何優化架構石杉的架構筆記欄目系統架構简体版

原文原文鏈接

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）node

週一至週五早8點半！精品技術文章準時送上！面試

（1）爲何要用緩存集羣

這篇文章，我們來聊聊熱點緩存的架構優化問題。網絡

其實使用緩存集羣的時候，最怕的就是熱key、大value這兩種狀況，那啥叫熱key大value呢？架構

簡單來講，熱key，就是你的緩存集羣中的某個key瞬間被數萬甚至十萬的併發請求打爆。

大value，就是你的某個key對應的value可能有GB級的大小，致使查詢value的時候致使網絡相關的故障問題。

這篇文章，咱們就來聊聊熱key問題。先來看看下面的一幅圖。

簡單來講，假設你手頭有個系統，他自己是集羣部署的，而後後面有一套緩存集羣，這個集羣無論你用redis cluster，仍是memcached，或者是公司自研緩存集羣，均可以。

那麼，這套系統用緩存集羣幹什麼呢？

很簡單了，在緩存裏放一些平時不怎麼變更的數據，而後用戶在查詢大量的平時不怎麼變更的數據的時候，不就能夠直接從緩存裏走了嗎？

緩存集羣的併發能力是很強的，並且讀緩存的性能是很高的。

舉個例子，假設你每秒有2萬請求，可是其中90%都是讀請求，那麼每秒1.8萬請求都是在讀一些不太變化的數據，而不是寫數據。

那此時你把數據都放在數據庫裏，而後每秒發送2萬請求到數據庫上讀寫數據，你以爲合適嗎？

固然不太合適了，若是你要用數據庫承載每秒2萬請求的話，那麼很差意思，你極可能就得搞分庫分表 + 讀寫分離。

好比你得分3個主庫，承載每秒2000的寫入請求，而後每一個主庫掛3個從庫，一共9個從庫承載每秒1.8萬的讀請求。

這樣的話，你可能就須要一共是12臺高配置的數據庫服務器，這是很耗費錢的，成本很是高，並且很不合適。

你們看看下面的圖，來體會下這種狀況。

因此，此時你徹底就能夠把平時不太變化的數據放在緩存集羣裏，緩存集羣能夠採用2主2從，主節點用來寫入緩存，從節點用來讀緩存。

以緩存集羣的性能，2個從節點徹底能夠用來承載每秒1.8萬的大量讀了，而後3個數據庫主庫就是承載每秒2000的寫請求和少許其餘讀請求就能夠了。

你們看看下面的圖，你耗費的機器瞬間變成了4臺緩存機器 + 3臺數據庫機器 = 7臺機器，是否是比以前的12臺機器減小了很大的資源開銷？

沒錯，緩存其實在系統架構裏是很是重要的組成部分。不少時候，對於那些不多變化可是大量高併發讀的數據，經過緩存集羣來抗高併發讀，是很是合適的。

這裏全部的機器數量、併發請求量都是一個示例，你們主要是體會一下這個意思就好，其目的主要是給一些不太熟悉緩存相關技術的同窗一點背景性的闡述，讓這些同窗可以理解在系統裏用緩存集羣承載讀請求是什麼意思。

（2）20萬用戶同時訪問一個熱點緩存的問題

好了，背景是已經給你們解釋清楚了，那麼如今就能夠給你們說說今天重點要討論的問題：熱點緩存。

咱們來作一個假設，你如今有10個緩存節點來抗大量的讀請求。正常狀況下，讀請求應該是均勻的落在10個緩存節點上的，對吧！

這10個緩存節點，每秒承載1萬請求是差很少的。

而後咱們再作一個假設，你一個節點承載2萬請求是極限，因此通常你就限制一個節點正常承載1萬請求就ok了，稍微留一點buffer出來。

好，所謂的熱點緩存問題是什麼意思呢？

很簡單，就是忽然由於莫名的緣由，出現大量的用戶訪問同一條緩存數據。

舉個例子，某個明星忽然宣佈跟某某結婚，這個時候是否是會引起可能短期內每秒都是數十萬的用戶去查看這個明星跟某某結婚的那條新聞？

那麼假設那條新聞就是一個緩存，而後對應就是一個緩存key，就存在一臺緩存機器上，此時瞬時假設有20萬請求奔向那一臺機器上的一個key。

此時會如何？咱們看看下面的圖，來體會一下這種絕望的感覺。

這個時候很明顯了，咱們剛纔假設的是一個緩存Slave節點最多每秒就是2萬的請求，固然實際緩存單機承載5萬~10萬讀請求也是可能的，咱們這裏就是一個假設。

結果此時，每秒忽然奔過來20萬請求到這臺機器上，會怎麼樣？

很簡單，上面圖裏那臺被20萬請求指向的緩存機器會過分操勞而宕機的。

那麼若是緩存集羣開始出現機器的宕機，此時會如何？

接着，讀請求發現讀不到數據，會從數據庫裏提取原始數據，而後放入剩餘的其餘緩存機器裏去。可是接踵而來的每秒20萬請求，會再次壓垮其餘的緩存機器。

以此類推，最終致使緩存集羣全盤崩潰，引起系統總體宕機。

我們看看下面的圖，再感覺一下這個恐怖的現場。

（3）基於流式計算技術的緩存熱點自動發現

其實這裏關鍵的一點，就是對於這種熱點緩存，你的系統須要可以在熱點緩存忽然發生的時候，直接發現他，而後瞬間立馬實現毫秒級的自動負載均衡。

那麼咱們就先來講說，你如何自動發現熱點緩存問題？

首先你要知道，通常出現緩存熱點的時候，你的每秒併發確定是很高的，可能每秒都幾十萬甚至上百萬的請求量過來，這都是有可能的。

因此，此時徹底能夠基於大數據領域的流式計算技術來進行實時數據訪問次數的統計，好比storm、spark streaming、flink，這些技術都是能夠的。

而後一旦在實時數據訪問次數統計的過程當中，好比發現一秒以內，某條數據忽然訪問次數超過了1000，就直接立馬把這條數據斷定爲是熱點數據，能夠將這個發現出來的熱點數據寫入好比zookeeper中。

固然，你的系統如何斷定熱點數據，能夠根據本身的業務還有經驗值來就能夠了。

你們看看下面這張圖，看看整個流程是如何進行的。

固然確定有人會問，那你的流式計算系統在進行數據訪問次數統計的時候，會不會也存在說單臺機器被請求每秒幾十萬次的問題呢？

答案是否，由於流式計算技術，尤爲是storm這種系統，他能夠作到同一條數據的請求過來，先分散在不少機器裏進行本地計算，最後再彙總局部計算結果到一臺機器進行全局彙總。

因此幾十萬請求能夠先分散在好比100臺機器上，每臺機器統計了這條數據的幾千次請求。

而後100條局部計算好的結果彙總到一臺機器作全局計算便可，因此基於流式計算技術來進行統計是不會有熱點問題的。

（4）熱點緩存自動加載爲JVM本地緩存

咱們本身的系統能夠對zookeeper指定的熱點緩存對應的znode進行監聽，若是有變化他立馬就能夠感知到了。

此時系統層就能夠立馬把相關的緩存數據從數據庫加載出來，而後直接放在本身系統內部的本地緩存裏便可。

這個本地緩存，你用ehcache、hashmap，其實均可以，一切都看本身的業務需求，主要說的就是將緩存集羣裏的集中式緩存，直接變成每一個系統本身本地實現緩存便可，每一個系統本身本地是沒法緩存過多數據的。

由於通常這種普通系統單實例部署機器可能就一個4核8G的機器，留給本地緩存的空間是不多的，因此用來放這種熱點數據的本地緩存是最合適的，剛恰好。

假設你的系統層集羣部署了100臺機器，那麼好了，此時你100臺機器瞬間在本地都會有一份熱點緩存的副本。

而後接下來對熱點緩存的讀操做，直接系統本地緩存讀出來就給返回了，不用再走緩存集羣了。

這樣的話，也不可能容許每秒20萬的讀請求到達緩存機器的一臺機器上讀一個熱點緩存了，而是變成100臺機器每臺機器承載數千請求，那麼那數千請求就直接從機器本地緩存返回數據了，這是沒有問題的。

咱們再來畫一幅圖，一塊兒來看看這個過程：

（5）限流熔斷保護

除此以外，在每一個系統內部，其實還應該專門加一個對熱點數據訪問的限流熔斷保護措施。

每一個系統實例內部，均可以加一個熔斷保護機制，假設緩存集羣最多每秒承載4萬讀請求，那麼你一共有100個系統實例。

你本身就該限制好，每一個系統實例每秒最多請求緩存集羣讀操做不超過400次，一超過就能夠熔斷掉，不讓請求緩存集羣，直接返回一個空白信息，而後用戶稍後會自行再次從新刷新頁面之類的。

經過系統層本身直接加限流熔斷保護措施，能夠很好的保護後面的緩存集羣、數據庫集羣之類的不要被打死，咱們來看看下面的圖。

（6）本文總結

具體要不要在系統裏實現這種複雜的緩存熱點優化架構呢？這個還要看大家本身的系統有沒有這種場景了。

若是你的系統有熱點緩存問題，那麼就要實現相似本文的複雜熱點緩存支撐架構。

可是若是沒有的話，那麼也別過分設計，其實你的系統可能根本不須要這麼複雜的架構。

若是是後者，那麼大夥兒就權當看看本文，來了解一下對應的架構思想好了^_^

End

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授