本文章為《網際網路高併發微服務化架構實踐》系列文章的第五篇，前四篇為：
在高併發場景下，需要透過快取來減少資料庫的壓力，使得大量的訪問進來能夠命中快取，只有少量的需要到資料庫層。由於快取基於記憶體，可支援的併發量遠遠大於基於硬碟的資料庫。所以對於高併發設計，快取的設計時必不可少的一環。
為什麼要使用快取呢？源於人類的一個夢想，就是多快好省的建設社會主義。
多快好省？很多客戶都這麼要求，但是作為具體做技術的你，當然知道，好就不能快，多就沒法省。
-
這個能不能便宜一點，你咋這麼貴呀，你看人家都很便宜的。（您好，這種打折的房間比較靠裡，是不能面向大海的）
-
你們的效能怎麼這麼差啊，用你這個系統跑的這麼慢，你看人家廣告中說速度能達到多少多少。（您好，你如果買一個頂配的，我們也是有這種效能的）
-
你們服務不行啊，你就不能彬彬有禮，穿著整齊，送點水果瓜子啥的？（您好，我們蘭州拉麵館沒有這項服務，可以去對面的俏江南看一下）
-
這麼貴的菜，一盤就這麼一點點，都吃不飽，就不能上一大盤麼。（您好，對面的蘭州拉麵10塊錢一大碗）
怎麼辦呢？勞動人民還是很有智慧的，就是聚焦核心需求，讓最最核心的部分享用好和快，而非核心的部門就多和省就可以了。
你可以大部分時間住在公司旁邊的出租屋裡面，但是出去度假的一個星期，選一個面朝大海，春暖花開的五星級酒店。
你可以大部分時間都擠地鐵，擠公交，跋涉2個小時從北五環到南五環，但是有急事的時候，你可以打車，想旅遊的時候，可以租車。
你可以大部分時間都吃普通的餐館，而朋友來了，就去高階飯店裡面搓一頓。
越是快的裝置，儲存量越小，越貴，而越是慢的裝置，儲存量越大，越便宜。
對於一家電商來講，我們既希望儲存越來越多的資料，因為資料將來就是資產，就是財富，只有有了資料，我們才知道使用者需要什麼，同時又希望當我想訪問這些資料的時候，能夠快速的得到，雙十一拼的就是速度和使用者體驗，要讓使用者有流暢的感覺。
所以我們要講大量的資料都儲存下來，放在便宜的儲存裡面，同時將經常訪問的，放在貴的，小的儲存裡面，當然貴的快的往往比較資源有限，因而不能長時間被某些資料長期霸佔，所以要大家輪著用，所以叫快取，也就是暫時存著。
當一個應用剛開始的時候，架構比較簡單，往往就是一個Tomcat，後面跟著一個資料庫。
然而資料庫相當於我們應用的中軍大帳，是我們整個架構中最最關鍵的一部分，也是最不能掛，也最不能會被攻破的一部分，因而所有對資料庫的訪問都需要一道屏障來進行保護，常用的就是快取。
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裡面扔，同時統一開啟了持久化。
這樣某一層的快取掛了，還有另一層可以撐著，等待快取的修複，例如分散式快取因為某種原因掛了，因為持久化的原因，同步機制的原因，記憶體過大的原因等，修複需要一段時間，在這段時間內，至少本地快取可以抗一陣，不至於一下子就擊穿資料庫。而且對於特別特別熱的資料，熱到導致集中式的快取處理不過來，網絡卡也被打滿的情況，由於本地快取不需要遠端呼叫，也是分佈在應用層的，可以緩解這種問題。
到底要解決什麼問題，可以選擇不同的快取。是要儲存大的無格式的資料，還是要儲存小的有格式的資料，還是要儲存一定需要持久化的資料。具體的場景下一節詳細談。
使得每一個快取實體都不大，但是實體數目比較多，這樣一方面可以實現負載均衡，防止單個實體稱為瓶頸或者熱點，另一方面如果一個實體掛了，影響面會小很多，高可用性大大增強。分片的機制可以在客戶端實現，可以使用中介軟體實現，也可以使用Redis的Cluster的方式，分片的演演算法往往都是雜湊取模，或者一致性雜湊。
當你的應用扛不住，知道要使用快取了，應該怎麼做呢？
這種場景是最常見的場景，也是很多架構使用快取的適合，最先涉及到的場景。
基本就是資料庫裡面啥樣，我快取也啥樣，資料庫裡面有商品資訊，快取裡面也放商品資訊，唯一不同的是，資料庫裡面是全量的商品資訊，快取裡面是最熱的商品資訊。
每當應用要查詢商品資訊的時候，先查快取，快取沒有就查資料庫，查出來的結果放入快取，從而下次就查到了。
這個是快取最最經典的更新流程。這種方式簡單，直觀，很多快取的庫都預設支援這種方式。
有時候我們需要獲得一些串列資料，並對這些資料進行排序和分頁。
例如我們想獲取點贊最多的評論，或者最新的評論，然後列出來，一頁一頁的翻下去。
在這種情況下，快取裡面的資料結構和資料庫裡面完全不一樣。
如果完全使用資料庫進行實現，則按照某種條件將所有的行查詢出來，然後按照某個欄位進行排序，然後進行分頁，一頁一頁的展示。
但是當資料量比較大的時候，這種方式往往成為瓶頸，首先涉及的資料庫行數比較多，而且排序也是個很慢的活，儘管可能有索引，分頁也是翻頁到最後，越是慢。
在快取裡面，就沒必要每行一個key了，而是可以使用Redis的串列方式進行儲存，當然串列的長短是有限制的，肯定放不下資料庫裡面這麼多，但是大家會發現其實對於所有的串列，使用者往往沒有耐心看個十頁八頁的，例如百度上搜個東西，也是有排序和分頁的，但是你每次都往後翻了嗎，每頁就十條，就算是十頁，或者一百頁，也就一千條資料，如果保持ID的話，完全放的下。
如果已經排好序，放在Redis裡面，那取出串列，翻頁就非常快了。
可以後臺有一個執行緒，非同步的初始化和掃清快取，在快取裡面儲存一個時間戳，當有更新的時候，掃清時間戳，非同步任務發現時間戳改變了，就掃清快取。
計數對於資料庫來講，是一個非常繁重的工作，需要查詢大量的行，最後得出計數的結論，當資料改變的時候，需要重新刷一遍，非常影響效能。
因此可以有一個計數服務，後端是一個快取，將計數作為結果放在快取裡面，當資料有改變的時候，呼叫計數服務增加或者減少計數，而非透過非同步資料庫count來更新快取。
計數服務可以使用Redis進行單個計數，或者hash表進行批次計數
有時候資料庫裡面保持的資料的維度是為了寫入方便，而非為了查詢方便的，然而同時查詢過程，也需要處理高併發，因而需要為了查詢方便，將資料重新以另一個維度儲存一遍，或者說將多給資料庫的內容聚合一下，再儲存一遍，從而不用每次查詢的時候都重新聚合，如果還是放在資料庫，比較難維護，放在快取就好一些。
例如一個商品的所有的帖子和帖子的使用者，以及一個使用者發表過的所有的帖子就是屬於兩個維度。
這需要寫入一個維度的時候，同時非同步通知，更新快取中的另一個維度。
在這種場景下，資料量相對比較大，因而單純用記憶體快取Memcached或者redis難以支撐，往往會選擇使用levelDB進行儲存，如果levelDB的效能跟不上，可以考慮在levelDB之前，再來一層Memcached。
對於評論的詳情，或者帖子的詳細內容，屬於非結構化的，而且內容比較大，因而使用Memcached比較好。
雖然使用了快取，大家心裡都有一個預期，就是實時性和一致性得不到完全的保證，畢竟資料儲存了多份，資料庫一份，快取中一份，當資料庫中因寫入而產生了新的資料，往往快取是不會和資料庫操作放在一個事務裡面的，如何將新的資料更新到快取裡面，什麼時候更新到快取裡面，不同的策略不一樣。
從使用者體驗角度，當然是越實時越好，使用者體驗越流暢，完全從這個角度出發，就應該有了寫入，馬上廢棄快取，觸發一次資料庫的讀取，從而更新快取。但是這和第三個問題，高併發就矛盾了，如果所有的都實時從資料庫裡面讀取，高併發場景下，資料庫往往受不了。
第一：可能讀取的是冷資料，原來從來沒有訪問過，所以需要到資料庫裡面查詢一下，然後放入快取，再傳回給客戶。
第二：可能資料因為有了寫入，被實時的從快取中刪除了，就如第一個問題中描述的那樣，為了保證實時性，當資料庫中的資料更新了之後，馬上刪除快取中的資料，導致這個時候的讀取讀不到，需要到資料庫裡面查詢後，放入快取，再傳回給客戶。
第三：可能是快取實效了，每個快取資料都會有實效時間，過了一段時間沒有被訪問，就會失效，這個時候資料就訪問不到了，需要訪問資料庫後，再放入快取。
第四：資料被換出，由於快取記憶體是有限的，當使用快滿了的時候，就會使用類似LRU策略，將不經常使用的資料換出，所以也要訪問資料庫。
第五：後端確實也沒有，應用訪問快取沒有，於是查詢資料庫，結果資料庫裡面也沒有，只好傳回客戶為空，但是尷尬的是，每次出現這種情況的時候，都會面臨著一次資料庫的訪問，純屬浪費資源，常用的方法是，講這個key對應的結果為空的事實也進行快取，這樣快取可以命中，但是命中後告訴客戶端沒有，減少了資料庫的壓力。
無論哪種原因導致的讀取快取讀不到的情況，該怎麼辦？是個策略問題。
一種是同步訪問資料庫後，放入快取，再傳回給客戶，這樣實時性最好，但是給資料庫的壓力也最大。
另一種方式就是非同步的訪問資料庫，暫且傳回客戶一個fallback值，然後同時觸發一個非同步更新，這樣下次就有了，這樣資料庫壓力小很多，但是使用者就訪問不到實時的資料了。
我們本來使用快取，是來攔截直接訪問資料庫請求的，從而保證資料庫大本營永遠處於健康的狀態。但是如果一遇到不命中，就訪問資料庫的話，平時沒有什麼問題，但是大促情況下，資料庫是受不了的。
一種情況是多個客戶端，併發狀態下，都不命中了，於是併發的都來訪問資料庫，其實只需要訪問一次就好，這種情況可以透過加鎖，只有一個到後端來實現。
另外就是即便採取了上述的策略，依然併發量非常大，後端的資料庫依然受不了，則需要透過降低實時性，將快取攔在資料庫前面，暫且撐住，來解決。
所謂的實時策略，是平時快取使用的最常用的策略，也是保持實時性最好的策略。
讀取的過程，應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。如果命中，應用程式從cache中取資料，取到後傳回。
寫入的過程，把資料存到資料庫中，成功後，再讓快取失效，失效後下次讀取的時候，會被寫入快取。那為什麼不直接寫快取呢？因為如果兩個執行緒同時更新資料庫，一個將資料庫改為10，一個將資料庫改為20，資料庫有自己的事務機制，可以保證如果20是後提交的，資料庫裡面改為20，但是回過頭來寫入快取的時候就沒有事務了，如果改為20的執行緒先更新快取，改為10的執行緒後更新快取，於是就會長時間出現快取中是10，但是資料庫中是20的現象。
這種方式實時性好，使用者體驗好，是預設應該使用的策略。
所謂非同步策略，就是當讀取的時候讀不到的時候，不直接訪問資料庫，而是傳回一個fallback資料，然後往訊息佇列裡面放入一個資料載入的事件，在背後有一個任務，收到事件後，會非同步的讀取資料庫，由於有佇列的作用，可以實現消峰，緩衝對資料庫的訪問，甚至可以將多個佇列中的任務合併請求，合併更新快取，提高了效率。
當更新的時候，非同步策略總是先更新資料庫和快取中的一個，然後非同步的更新另一個。
一是先更新資料庫，然後非同步更新快取。當資料庫更新後，同樣生成一個非同步訊息，放入訊息佇列中，等待背後的任務透過訊息進行快取更新，同樣可以實現消峰和任務合併。缺點就是實時性比較差，估計要過一段時間才能看到更新，好處是資料永續性可以得到保證。
一是先更新快取，然後非同步更新資料庫。這種方式讀取和寫入都用快取，將快取完全擋在了資料庫的前面，把快取當成了資料庫在用。所以一般會使用有持久化機制和主備的redis，但是仍然不能保證快取不丟資料，所以這種情況適用於併發量大，但是資料沒有那麼關鍵的情況，好處是實時性好。
在實時策略扛不住大促的時候，可以根據場景，切換到上面的兩種樣式的一個，算是降級策略。
如果併發量實在太大，資料量也大的情況，非同步都難以滿足，可以降級為定時掃清的策略，這種情況下，應用只訪問快取，不訪問資料庫，更新頻率也不高，而且使用者要求也不高，例如詳情，評論等。
這種情況下，由於資料量比較大，建議將一整塊資料拆分成幾部分進行快取，而且區分更新頻繁的和不頻繁的，這樣不用每次更新的時候，所有的都更新，只更新一部分。並且快取的時候，可以進行資料的預整合，因為實時性不高，讀取預整合的資料更快。
本次培訓內容包括：Docker基礎、容器技術、Docker映象、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心元件原理分析、Kubernetes服務質量保證、排程詳解與應用場景、網路、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
