歡迎光臨
每天分享高質量文章

微服務化之快取的設計

本文章為《互聯網高併發微服務化架構實踐》系列文章的第五篇,前四篇為:
在高併發場景下,需要通過快取來減少資料庫的壓力,使得大量的訪問進來能夠命中快取,只有少量的需要到資料庫層。由於快取基於記憶體,可支持的併發量遠遠大於基於硬碟的資料庫。所以對於高併發設計,快取的設計時必不可少的一環。


一、為什麼要使用快取

為什麼要使用快取呢?源於人類的一個夢想,就是多快好省的建設社會主義。
多快好省?很多客戶都這麼要求,但是作為具體做技術的你,當然知道,好就不能快,多就沒法省。
可是沒辦法,客戶都這樣要求:
  • 這個能不能便宜一點,你咋這麼貴呀,你看人家都很便宜的。(您好,這種打折的房間比較靠里,是不能面向大海的)

  • 你們的性能怎麼這麼差啊,用你這個系統跑的這麼慢,你看人家廣告中說速度能達到多少多少。(您好,你如果買一個頂配的,我們也是有這種性能的)

  • 你們服務不行啊,你就不能彬彬有禮,穿著整齊,送點水果瓜子啥的?(您好,我們蘭州拉麵館沒有這項服務,可以去對面的俏江南看一下)

  • 這麼貴的菜,一盤就這麼一點點,都吃不飽,就不能上一大盤麽。(您好,對面的蘭州拉麵10塊錢一大碗)

怎麼辦呢?勞動人民還是很有智慧的,就是聚焦核心需求,讓最最核心的部分享用好和快,而非核心的部門就多和省就可以了。
你可以大部分時間住在公司旁邊的出租屋裡面,但是出去度假的一個星期,選一個面朝大海,春暖花開的五星級酒店。
你可以大部分時間都擠地鐵,擠公交,跋涉2個小時從北五環到南五環,但是有急事的時候,你可以打車,想旅游的時候,可以租車。
你可以大部分時間都吃普通的餐館,而朋友來了,就去高級飯店裡面搓一頓。
在計算機世界也是這樣樣子的,如圖所示。

越是快的設備,儲存量越小,越貴,而越是慢的設備,儲存量越大,越便宜。
對於一家電商來講,我們既希望儲存越來越多的資料,因為資料將來就是資產,就是財富,只有有了資料,我們才知道用戶需要什麼,同時又希望當我想訪問這些資料的時候,能夠快速的得到,雙十一拼的就是速度和用戶體驗,要讓用戶有流暢的感覺。
所以我們要講大量的資料都儲存下來,放在便宜的儲存裡面,同時將經常訪問的,放在貴的,小的儲存裡面,當然貴的快的往往比較資源有限,因而不能長時間被某些資料長期霸占,所以要大家輪著用,所以叫快取,也就是暫時存著。


二、都有哪些型別的快取

當一個應用剛開始的時候,架構比較簡單,往往就是一個Tomcat,後面跟著一個資料庫。

簡單的應用,併發量不大的時候,當然沒有問題。
然而資料庫相當於我們應用的中軍大帳,是我們整個架構中最最關鍵的一部分,也是最不能掛,也最不能會被攻破的一部分,因而所有對資料庫的訪問都需要一道屏障來進行保護,常用的就是快取。
我們以Tomcat為分界線,之外我們稱為接入層,接入層當然應該有快取,還有CDN,這個在這篇文章中有詳細的描述:《微服務的接入層設計與動靜資源隔離》。
Tomcat之後,我們稱為應用層,應用層也應該有快取,這是我們這一節討論的重點。
最簡單的方式就是Tomcat裡面有一層快取,常稱為本地快取LocalCache。
這類的快取常見的有Ehcache和Guava Cache,由於這類快取在Tomcat本地,因而訪問速度是非常快的。
但是本地快取有個比較大的缺點,就是快取是放在JVM裡面的,會面臨Full GC的問題,一旦出現了FullGC,就會對應用的性能和相應時間產生影響,當然也可以嘗試jemalloc的分配方式。
還有一種方式,就是在Tomcat和Mysql中間加了一層Cache,我們常稱為分佈式快取。

分佈式快取常見的有Memcached和Redis,兩者各有優缺點。
Memcached適合做簡單的key-value儲存,記憶體使用率比較高,而且由於是多核處理,對於比較大的資料,性能較好。
但是缺點也比較明顯,Memcached嚴格來講沒有集群機制,橫向擴展完全靠客戶端來實現。另外Memcached無法持久化,一旦掛了資料就都丟失了,如果想實現高可用,也是需要客戶端進行雙寫才可以。
所以可以看出Memcached真的是設計出來,簡簡單單為了做一個快取的。

Redis的資料結構就豐富的多了,單執行緒的處理所有的請求,對於比較大的資料,性能稍微差一點。

Redis提供持久化的功能,包括RDB的全量持久化,或者AOF的增量持久化,從而使得Redis掛了,資料是有機會恢復的。
Redis提供成熟的主備同步,故障切換的功能,從而保證了高可用性。
所以很多地方管Redis稱為記憶體資料庫,因為他的一些特性已經有了資料庫的影子。
這也是很多人願意用Redis的原因,集合了快取和資料庫的優勢,但是往往會濫用這些優勢,從而忽略了架構層面的設計,使得Redis集群有很大的風險。
很多情況下,會將Redis當做資料庫使用,開啟持久化和主備同步機制,以為就可以高枕無憂了。

然而Redis的持久化機制,全量持久化則往往需要額外較大的記憶體,而在高併發場景下,記憶體本來就很緊張,如果造成swap,就會影響性能。增量持久化也涉及到寫磁盤和fsync,也是會拖慢處理的速度,在平時還好,如果高併發場景下,仍然會影響吞吐量。
所以在架構設計角度,快取就是快取,要意識到資料會隨時丟失的,要意識到快取的存著的目的是攔截到資料庫的請求。如果為了保證快取的資料不丟失,從而影響了快取的吞吐量,甚至穩定性,讓快取響應不過來,甚至掛掉,所有的請求擊穿到資料庫,就是更加嚴重的事情了。
如果非常需要進行持久化,可以考慮使用levelDB此類的,對於隨機寫入性能較好的key-value持久化儲存,這樣只有部分的確需要持久化的資料,才進行持久化,而非無論什麼資料,通通往Redis裡面扔,同時統一開啟了持久化。


三、基於快取的架構設計要點

所以基於快取的設計:
1、多層次
這樣某一層的快取掛了,還有另一層可以撐著,等待快取的修複,例如分佈式快取因為某種原因掛了,因為持久化的原因,同步機制的原因,記憶體過大的原因等,修複需要一段時間,在這段時間內,至少本地快取可以抗一陣,不至於一下子就擊穿資料庫。而且對於特別特別熱的資料,熱到導致集中式的快取處理不過來,網卡也被打滿的情況,由於本地快取不需要遠程呼叫,也是分佈在應用層的,可以緩解這種問題。
2、分場景
到底要解決什麼問題,可以選擇不同的快取。是要儲存大的無格式的資料,還是要儲存小的有格式的資料,還是要儲存一定需要持久化的資料。具體的場景下一節詳細談。
3、要分片
使得每一個快取實體都不大,但是實體數目比較多,這樣一方面可以實現負載均衡,防止單個實體稱為瓶頸或者熱點,另一方面如果一個實體掛了,影響面會小很多,高可用性大大增強。分片的機制可以在客戶端實現,可以使用中間件實現,也可以使用Redis的Cluster的方式,分片的演算法往往都是哈希取模,或者一致性哈希。
四、快取的使用場景

當你的應用扛不住,知道要使用快取了,應該怎麼做呢?
場景1:和資料庫中的資料結構保持一致,原樣快取
這種場景是最常見的場景,也是很多架構使用快取的適合,最先涉及到的場景。
基本就是資料庫裡面啥樣,我快取也啥樣,資料庫裡面有商品信息,快取裡面也放商品信息,唯一不同的是,資料庫裡面是全量的商品信息,快取裡面是最熱的商品信息。
每當應用要查詢商品信息的時候,先查快取,快取沒有就查資料庫,查出來的結果放入快取,從而下次就查到了。
這個是快取最最經典的更新流程。這種方式簡單,直觀,很多快取的庫都預設支持這種方式。
場景2:串列排序分頁場景的快取
有時候我們需要獲得一些串列資料,並對這些資料進行排序和分頁。
例如我們想獲取點贊最多的評論,或者最新的評論,然後列出來,一頁一頁的翻下去。
在這種情況下,快取裡面的資料結構和資料庫裡面完全不一樣。
如果完全使用資料庫進行實現,則按照某種條件將所有的行查詢出來,然後按照某個欄位進行排序,然後進行分頁,一頁一頁的展示。
但是當資料量比較大的時候,這種方式往往成為瓶頸,首先涉及的資料庫行數比較多,而且排序也是個很慢的活,儘管可能有索引,分頁也是翻頁到最後,越是慢。
在快取裡面,就沒必要每行一個key了,而是可以使用Redis的串列方式進行儲存,當然串列的長短是有限制的,肯定放不下資料庫裡面這麼多,但是大家會發現其實對於所有的串列,用戶往往沒有耐心看個十頁八頁的,例如百度上搜個東西,也是有排序和分頁的,但是你每次都往後翻了嗎,每頁就十條,就算是十頁,或者一百頁,也就一千條資料,如果保持ID的話,完全放的下。
如果已經排好序,放在Redis裡面,那取出串列,翻頁就非常快了。
可以後臺有一個執行緒,異步的初始化和掃清快取,在快取裡面儲存一個時間戳,當有更新的時候,掃清時間戳,異步任務發現時間戳改變了,就掃清快取。
場景3:計數快取
計數對於資料庫來講,是一個非常繁重的工作,需要查詢大量的行,最後得出計數的結論,當資料改變的時候,需要重新刷一遍,非常影響性能。
因此可以有一個計數服務,後端是一個快取,將計數作為結果放在快取裡面,當資料有改變的時候,呼叫計數服務增加或者減少計數,而非通過異步資料庫count來更新快取。
計數服務可以使用Redis進行單個計數,或者hash表進行批量計數
場景4:重構維度快取
有時候資料庫裡面保持的資料的維度是為了寫入方便,而非為了查詢方便的,然而同時查詢過程,也需要處理高併發,因而需要為了查詢方便,將資料重新以另一個維度儲存一遍,或者說將多給資料庫的內容聚合一下,再儲存一遍,從而不用每次查詢的時候都重新聚合,如果還是放在資料庫,比較難維護,放在快取就好一些。
例如一個商品的所有的帖子和帖子的用戶,以及一個用戶發表過的所有的帖子就是屬於兩個維度。
這需要寫入一個維度的時候,同時異步通知,更新快取中的另一個維度。
在這種場景下,資料量相對比較大,因而單純用記憶體快取Memcached或者redis難以支撐,往往會選擇使用levelDB進行儲存,如果levelDB的性能跟不上,可以考慮在levelDB之前,再來一層Memcached。
場景5:較大的詳情內容資料快取
對於評論的詳情,或者帖子的詳細內容,屬於非結構化的,而且內容比較大,因而使用Memcached比較好。

五、快取三大矛盾問題

1、快取實時性和一致性問題:當有了寫入後咋辦?
雖然使用了快取,大家心裡都有一個預期,就是實時性和一致性得不到完全的保證,畢竟資料儲存了多份,資料庫一份,快取中一份,當資料庫中因寫入而產生了新的資料,往往快取是不會和資料庫操作放在一個事務裡面的,如何將新的資料更新到快取裡面,什麼時候更新到快取裡面,不同的策略不一樣。
從用戶體驗角度,當然是越實時越好,用戶體驗越流暢,完全從這個角度出發,就應該有了寫入,馬上廢棄快取,觸發一次資料庫的讀取,從而更新快取。但是這和第三個問題,高併發就矛盾了,如果所有的都實時從資料庫裡面讀取,高併發場景下,資料庫往往受不了。
2、快取的穿透問題:當沒有讀到咋辦?
為什麼會出現快取讀取不到的情況呢?
第一:可能讀取的是冷資料,原來從來沒有訪問過,所以需要到資料庫裡面查詢一下,然後放入快取,再傳回給客戶。
第二:可能資料因為有了寫入,被實時的從快取中刪除了,就如第一個問題中描述的那樣,為了保證實時性,當資料庫中的資料更新了之後,馬上刪除快取中的資料,導致這個時候的讀取讀不到,需要到資料庫裡面查詢後,放入快取,再傳回給客戶。
第三:可能是快取實效了,每個快取資料都會有實效時間,過了一段時間沒有被訪問,就會失效,這個時候資料就訪問不到了,需要訪問資料庫後,再放入快取。
第四:資料被換出,由於快取記憶體是有限的,當使用快滿了的時候,就會使用類似LRU策略,將不經常使用的資料換出,所以也要訪問資料庫。
第五:後端確實也沒有,應用訪問快取沒有,於是查詢資料庫,結果資料庫裡面也沒有,只好傳回客戶為空,但是尷尬的是,每次出現這種情況的時候,都會面臨著一次資料庫的訪問,純屬浪費資源,常用的方法是,講這個key對應的結果為空的事實也進行快取,這樣快取可以命中,但是命中後告訴客戶端沒有,減少了資料庫的壓力。
無論哪種原因導致的讀取快取讀不到的情況,該怎麼辦?是個策略問題。
一種是同步訪問資料庫後,放入快取,再傳回給客戶,這樣實時性最好,但是給資料庫的壓力也最大。
另一種方式就是異步的訪問資料庫,暫且傳回客戶一個fallback值,然後同時觸發一個異步更新,這樣下次就有了,這樣資料庫壓力小很多,但是用戶就訪問不到實時的資料了。
3、快取對資料庫高併發訪問:都來訪問資料庫咋辦?
我們本來使用快取,是來攔截直接訪問資料庫請求的,從而保證資料庫大本營永遠處於健康的狀態。但是如果一遇到不命中,就訪問資料庫的話,平時沒有什麼問題,但是大促情況下,資料庫是受不了的。
一種情況是多個客戶端,併發狀態下,都不命中了,於是併發的都來訪問資料庫,其實只需要訪問一次就好,這種情況可以通過加鎖,只有一個到後端來實現。
另外就是即便採取了上述的策略,依然併發量非常大,後端的資料庫依然受不了,則需要通過降低實時性,將快取攔在資料庫前面,暫且撐住,來解決。


六、解決快取三大矛盾的掃清策略

1、實時策略
所謂的實時策略,是平時快取使用的最常用的策略,也是保持實時性最好的策略。
讀取的過程,應用程式先從cache取資料,沒有得到,則從資料庫中取資料,成功後,放到快取中。如果命中,應用程式從cache中取資料,取到後傳回。
寫入的過程,把資料存到資料庫中,成功後,再讓快取失效,失效後下次讀取的時候,會被寫入快取。那為什麼不直接寫快取呢?因為如果兩個執行緒同時更新資料庫,一個將資料庫改為10,一個將資料庫改為20,資料庫有自己的事務機制,可以保證如果20是後提交的,資料庫裡面改為20,但是回過頭來寫入快取的時候就沒有事務了,如果改為20的執行緒先更新快取,改為10的執行緒後更新快取,於是就會長時間出現快取中是10,但是資料庫中是20的現象。
這種方式實時性好,用戶體驗好,是預設應該使用的策略。
2、異步策略
所謂異步策略,就是當讀取的時候讀不到的時候,不直接訪問資料庫,而是傳回一個fallback資料,然後往訊息佇列裡面放入一個資料加載的事件,在背後有一個任務,收到事件後,會異步的讀取資料庫,由於有佇列的作用,可以實現消峰,緩衝對資料庫的訪問,甚至可以將多個佇列中的任務合併請求,合併更新快取,提高了效率。
當更新的時候,異步策略總是先更新資料庫和快取中的一個,然後異步的更新另一個。
一是先更新資料庫,然後異步更新快取。當資料庫更新後,同樣生成一個異步訊息,放入訊息佇列中,等待背後的任務通過訊息進行快取更新,同樣可以實現消峰和任務合併。缺點就是實時性比較差,估計要過一段時間才能看到更新,好處是資料持久性可以得到保證。
一是先更新快取,然後異步更新資料庫。這種方式讀取和寫入都用快取,將快取完全擋在了資料庫的前面,把快取當成了資料庫在用。所以一般會使用有持久化機制和主備的redis,但是仍然不能保證快取不丟資料,所以這種情況適用於併發量大,但是資料沒有那麼關鍵的情況,好處是實時性好。
在實時策略扛不住大促的時候,可以根據場景,切換到上面的兩種樣式的一個,算是降級策略。
3、定時策略
如果併發量實在太大,資料量也大的情況,異步都難以滿足,可以降級為定時掃清的策略,這種情況下,應用只訪問快取,不訪問資料庫,更新頻率也不高,而且用戶要求也不高,例如詳情,評論等。
這種情況下,由於資料量比較大,建議將一整塊資料拆分成幾部分進行快取,而且區分更新頻繁的和不頻繁的,這樣不用每次更新的時候,所有的都更新,只更新一部分。並且快取的時候,可以進行資料的預整合,因為實時性不高,讀取預整合的資料更快。
有關快取就說到這裡,下一節講分佈式事務。
本文轉載自公眾號:劉超的通俗雲計算,點擊查看原文


Kubernetes入門與進階實戰培訓

本次培訓內容包括:Docker基礎、容器技術、Docker鏡像、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心組件原理分析、Kubernetes服務質量保證、調度詳解與應用場景、網絡、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等,點擊瞭解具體培訓內容

5月11日正式上課,點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂