[[328476]]

緩存誤用

緩存，是互聯網分層架構中，非常重要的一個部分，通常用它來降低數據庫壓力，提升系統整體性能，縮短訪問時間。

有架構師說“緩存是萬金油，哪里有問題，加個緩存，就能優化”，緩存的濫用，可能會導致一些錯誤用法。

緩存，你真的用對了么?

誤用一：把緩存作為服務與服務之間傳遞數據的媒介

 

 

如上圖：

服務1和服務2約定好key和value，通過緩存傳遞數據

服務1將數據寫入緩存，服務2從緩存讀取數據，達到兩個服務通信的目的

該方案存在的問題是：

1、數據管道，數據通知場景，MQ更加適合

(1)MQ是互聯網常見的邏輯解耦，物理解耦組件，支持1對1，1對多各種模式，非常成熟的數據通道，而cache反而會將service-A/B/C/D耦合在一起，大家要彼此協同約定key的格式，ip地址等

(2)MQ能夠支持push，而cache只能拉取，不實時，有時延

(3)MQ天然支持集群，支持高可用，而cache未必

(4)MQ能支持數據落地，cache具備將數據存在內存里，具有“易失”性，當然，有些cache支持落地，但互聯網技術選型的原則是，讓專業的軟件干專業的事情：nginx做反向代理，db做固化，cache做緩存，mq做通道

2、多個服務關聯同一個緩存實例，會導致服務耦合

(1)大家要彼此協同約定key的格式，ip地址等，耦合

(2)約定好同一個key，可能會產生數據覆蓋，導致數據不一致

(3)不同服務業務模式，數據量，并發量不一樣，會因為一個cache相互影響，例如service-A數據量大，占用了cache的絕大部分內存，會導致service-B的熱數據全部被擠出cache，導致cache失效;又例如service-A并發量高，占用了cache的絕大部分連接，會導致service-B拿不到cache的連接，從而服務異常

誤用二：使用緩存未考慮雪崩

 

 

常規的緩存玩法，如上圖：

服務先讀緩存，緩存命中則返回

緩存不命中，再讀數據庫

什么時候會產生雪崩?

答：如果緩存掛掉，所有的請求會壓到數據庫，如果未提前做容量預估，可能會把數據庫壓垮(在緩存恢復之前，數據庫可能一直都起不來)，導致系統整體不可服務。

如何應對潛在的雪崩?

答：提前做容量預估，如果緩存掛掉，數據庫仍能扛住，才能執行上述方案。

否則，就要進一步設計。

常見方案一：高可用緩存

 

 

如上圖：使用高可用緩存集群，一個緩存實例掛掉后，能夠自動做故障轉移。

常見方案二：緩存水平切分

 

 

如上圖：使用緩存水平切分(推薦使用一致性哈希算法進行切分)，一個緩存實例掛掉后，不至于所有的流量都壓到數據庫上。

誤用三：調用方緩存數據

 

 

如上圖：

服務提供方緩存，向調用方屏蔽數據獲取的復雜性(這個沒問題)

服務調用方，也緩存一份數據，先讀自己的緩存，再決定是否調用服務(這個有問題)

該方案存在的問題是：

1、調用方需要關注數據獲取的復雜性(耦合問題)

2、更嚴重的，服務修改db里的數據，淘汰了服務cache之后，難以通知調用方淘汰其cache里的數據，從而導致數據不一致(帶入一致性問題)

3、有人說，服務可以通過MQ通知調用方淘汰數據，額，難道下游的服務要依賴上游的調用方，分層架構設計不是這么玩的(反向依賴問題)

誤用四：多服務共用緩存實例

 

 

如上圖：服務A和服務B共用一個緩存實例(不是通過這個緩存實例交互數據)

該方案存在的問題是：

1、可能導致key沖突，彼此沖掉對方的數據

畫外音：可能需要服務A和服務B提前約定好了key，以確保不沖突，常見的約定方式是使用namespace:key的方式來做key。

2、不同服務對應的數據量，吞吐量不一樣，共用一個實例容易導致一個服務把另一個服務的熱數據擠出去

3、共用一個實例，會導致服務之間的耦合，與微服務架構的“數據庫，緩存私有”的設計原則是相悖的

建議的玩法是

 

 

如上圖：各個服務私有化自己的數據存儲，對上游屏蔽底層的復雜性。

總結

1、服務與服務之間不要通過緩存傳遞數據

2、如果緩存掛掉，可能導致雪崩，此時要做高可用緩存，或者水平切分

3、調用方不宜再單獨使用緩存存儲服務底層的數據，容易出現數據不一致，以及反向依賴

4、不同服務，緩存實例要做垂直拆分

緩存，究竟是淘汰，還是修改?

KV緩存都緩存了一些什么數據?

答：

(1)樸素類型的數據，例如：int

(2)序列化后的對象，例如：User實體，本質是binary

(3)文本數據，例如：json或者html

(4)...

淘汰緩存中的這些數據，修改緩存中的這些數據，有什么差別?

答：

(1)淘汰某個key，操作簡單，直接將key置為無效，但下一次該key的訪問會cache miss

(2)修改某個key的內容，邏輯相對復雜，但下一次該key的訪問仍會cache hit

可以看到，差異僅僅在于一次cache miss。

緩存中的value數據一般是怎么修改的?

答：

(1)樸素類型的數據，直接set修改后的值即可

(2)序列化后的對象：一般需要先get數據，反序列化成對象，修改其中的成員，再序列化為binary，再set數據

(3)json或者html數據：一般也需要先get文本，parse成dom樹對象，修改相關元素，序列化為文本，再set數據

結論：對于對象類型，或者文本類型，修改緩存value的成本較高，一般選擇直接淘汰緩存。

問：對于樸素類型的數據，究竟應該修改緩存，還是淘汰緩存?

答：仍然視情況而定。

案例1：

假設，緩存里存了某一個用戶uid=123的余額是money=100元，業務場景是，購買了一個商品pid=456。

分析：如果修改緩存，可能需要：

(1)去db查詢pid的價格是50元

(2)去db查詢活動的折扣是8折(商品實際價格是40元)

(3)去db查詢用戶的優惠券是10元(用戶實際要支付30元)

(4)從cache查詢get用戶的余額是100元

(5)計算出剩余余額是100 - 30 = 70

(6)到cache設置set用戶的余額是70

為了避免一次cache miss，需要額外增加若干次db與cache的交互，得不償失。

結論：此時，應該淘汰緩存，而不是修改緩存。

案例2：

假設，緩存里存了某一個用戶uid=123的余額是money=100元，業務場景是，需要扣減30元。

分析：如果修改緩存，需要：

(1)從cache查詢get用戶的余額是100元

(2)計算出剩余余額是100 - 30 = 70

(3)到cache設置set用戶的余額是70

為了避免一次cache miss，需要額外增加若干次cache的交互，以及業務的計算，得不償失。

結論：此時，應該淘汰緩存，而不是修改緩存。

案例3：

假設，緩存里存了某一個用戶uid=123的余額是money=100元，業務場景是，余額要變為70元。

分析：如果修改緩存，需要：

修改緩存成本很低。

結論：此時，可以選擇修改緩存。當然，如果選擇淘汰緩存，只會額外增加一次cache miss，成本也不高。

總結：

大部分情況，修改value成本會高于“增加一次cache miss”，因此應該淘汰緩存

先操作數據庫，還是先操作緩存?

這里分了兩種觀點，Cache Aside Pattern的觀點、沈老師的觀點。下面兩種觀點分析一下。

Cache Aside Pattern

什么是“Cache Aside Pattern”?

對于讀請求

 

 

(1)先從cache中嘗試get數據，結果miss了

(2)再從db中讀取數據，從庫，讀寫分離

(3)最后把數據set回cache，方便下次讀命中

對于寫請求

 

 

如上圖：

(2)緩存，采用delete淘汰，而不是set更新

Cache Aside Pattern為什么建議淘汰緩存，而不是更新緩存?

 

 

如上圖所示，如果采用set緩存。

在1和2兩個并發寫發生時，由于無法保證時序，此時不管先操作緩存還是先操作數據庫，都可能出現：

(2)請求2先set了緩存，請求1后set了緩存

Cache Aside Pattern為什么建議先操作數據庫，再操作緩存?

 

 

如上圖所示，如果先操作緩存。

在1和2并發讀寫發生時，由于無法保證時序，可能出現：

(2)寫請求操作了數據庫(主從同步沒有完成)

(3)讀請求讀了緩存(cache miss)

(4)讀請求讀了從庫(讀了一個舊數據)

(5)讀請求set回緩存(set了一個舊數據)

(6)數據庫主從同步完成

所以，Cache Aside Pattern建議，先操作數據庫，再操作緩存。

Cache Aside Pattern方案存在什么問題?

(2)淘汰緩存失敗了

導致，數據庫與緩存的數據不一致。

個人見解：這里個人覺得可以使用重試的方法，在淘汰緩存的時候，如果失敗，則重試一定的次數。如果失敗一定次數還不行，那就是其他原因了。比如說redis故障、內網出了問題。

關于這個問題，沈老師的解決方案是，使用先操作緩存(delete)，再操作數據庫。假如刪除緩存成功，更新數據庫失敗了。緩存里沒有數據，數據庫里是之前的數據，數據沒有不一致，對業務無影響。只是下一次讀取，會多一次cache miss。這里我覺得沈老師可能忽略了并發的問題，比如說以下情況：

如圖：

 

 

不一致解決場景及解決方案

答：發生寫請求后(不管是先操作DB，還是先淘汰Cache)，在主從數據庫同步完成之前，如果有讀請求，都可能發生讀Cache Miss，讀從庫把舊數據存入緩存的情況。此時怎么辦呢?

一、數據庫主從不一致

先回顧下，無緩存時，數據庫主從不一致問題。

 

 

如上圖，發生的場景是，寫后立刻讀：

(1)主庫一個寫請求(主從沒同步完成)

(2)從庫接著一個讀請求，讀到了舊數據

(3)最后，主從同步完成

導致的結果是：主動同步完成之前，會讀取到舊數據。

可以看到，主從不一致的影響時間很短，在主從同步完成后，就會讀到新數據。

二、緩存與數據庫不一致

再看，引入緩存后，緩存和數據庫不一致問題。

 

 

如上圖，發生的場景也是，寫后立刻讀：

(1+2)先一個寫請求，淘汰緩存，寫數據庫

(3+4+5)接著立刻一個讀請求，讀緩存，cache miss，讀從庫，寫緩存放入數據，以便后續的讀能夠cache hit(主從同步沒有完成，緩存中放入了舊數據)

(6)最后，主從同步完成

導致的結果是：舊數據放入緩存，即使主從同步完成，后續仍然會從緩存一直讀取到舊數據。

可以看到，加入緩存后，導致的不一致影響時間會很長，并且最終也不會達到一致。

三、問題分析

可以看到，這里提到的緩存與數據庫數據不一致，根本上是由數據庫主從不一致引起的。當主庫上發生寫操作之后，從庫binlog同步的時間間隔內，讀請求，可能導致有舊數據入緩存。

思路：那能不能寫操作記錄下來，在主從時延的時間段內，讀取修改過的數據的話，強制讀主，并且更新緩存，這樣子緩存內的數據就是最新。在主從時延過后，這部分數據繼續讀從庫，從而繼續利用從庫提高讀取能力。

四、不一致解決方案

選擇性讀主

可以利用一個緩存記錄必須讀主的數據。

 

 

如上圖，當寫請求發生時：

(1)寫主庫

(2)將哪個庫，哪個表，哪個主鍵三個信息拼裝一個key設置到cache里，這條記錄的超時時間，設置為“主從同步時延”

PS：key的格式為“db:table:PK”，假設主從延時為1s，這個key的cache超時時間也為1s。

 

 

如上圖，當讀請求發生時：

這是要讀哪個庫，哪個表，哪個主鍵的數據呢，也將這三個信息拼裝一個key，到cache里去查詢，如果，

(1)cache里有這個key，說明1s內剛發生過寫請求，數據庫主從同步可能還沒有完成，此時就應該去主庫查詢。并且把主庫的數據set到緩存中，防止下一次cahce miss。

(2)cache里沒有這個key，說明最近沒有發生過寫請求，此時就可以去從庫查詢

以此，保證讀到的一定不是不一致的臟數據。

PS：如果系統可以接收短時間的不一致，建議建議定時更新緩存就可以了。避免系統過于復雜。

進程內緩存

除了常見的redis/memcache等進程外緩存服務，緩存還有一種常見的玩法，進程內緩存。

什么是進程內緩存?

答：將一些數據緩存在站點，或者服務的進程內，這就是進程內緩存。

進程內緩存的實現載體，最簡單的，可以是一個帶鎖的Map。又或者，可以使用第三方庫，例如leveldb、guave本地緩存

進程內緩存能存儲啥?

答：redis/memcache等進程外緩存服務能存什么，進程內緩存就能存什么。

 

 

如上圖，可以存儲json數據，可以存儲html頁面，可以存儲對象。

進程內緩存有什么好處?

答：與沒有緩存相比，進程內緩存的好處是，數據讀取不再需要訪問后端，例如數據庫。

 

 

如上圖，整個訪問流程要經過1,2,3,4四個步驟。

如果引入進程內緩存，

 

 

如上圖，整個訪問流程只要經過1,2兩個步驟。

與進程外緩存相比(例如redis/memcache)，進程內緩存省去了網絡開銷，所以一來節省了內網帶寬，二來響應時延會更低。

進程內緩存有什么缺點?

答：統一緩存服務雖然多一次網絡交互，但仍是統一存儲。

 

 

如上圖，站點和服務中的多個節點訪問統一的緩存服務，數據統一存儲，容易保證數據的一致性。

 

 

而進程內緩存，如上圖，如果數據緩存在站點和服務的多個節點內，數據存了多份，一致性比較難保障。

如何保證進程內緩存的數據一致性?

答：保障進程內緩存一致性，有三種方案。

第一種方案

可以通過單節點通知其他節點。如上圖：寫請求發生在server1，在修改完自己內存數據與數據庫中的數據之后，可以主動通知其他server節點，也修改內存的數據。如下圖：

 

 

這種方案的缺點是：同一功能的一個集群的多個節點，相互耦合在一起，特別是節點較多時，網狀連接關系極其復雜。

第二種方案

可以通過MQ通知其他節點。如上圖，寫請求發生在server1，在修改完自己內存數據與數據庫中的數據之后，給MQ發布數據變化通知，其他server節點訂閱MQ消息，也修改內存數據。

 

 

這種方案雖然解除了節點之間的耦合，但引入了MQ，使得系統更加復雜。

前兩種方案，節點數量越多，數據冗余份數越多，數據同時更新的原子性越難保證，一致性也就越難保證。

第三種方案

為了避免耦合，降低復雜性，干脆放棄了“實時一致性”，每個節點啟動一個timer，定時從后端拉取最新的數據，更新內存緩存。在有節點更新后端數據，而其他節點通過timer更新數據之間，會讀到臟數據。

 

 

為什么不能頻繁使用進程內緩存?

答：分層架構設計，有一條準則：站點層、服務層要做到無數據無狀態，這樣才能任意的加節點水平擴展，數據和狀態盡量存儲到后端的數據存儲服務，例如數據庫服務或者緩存服務。

可以看到，站點與服務的進程內緩存，實際上違背了分層架構設計的無狀態準則，故一般不推薦使用。

什么時候可以使用進程內緩存?

答：以下情況，可以考慮使用進程內緩存。

情況一

只讀數據，可以考慮在進程啟動時加載到內存。

畫外音：此時也可以把數據加載到redis / memcache，進程外緩存服務也能解決這類問題。

情況二

極其高并發的，如果透傳后端壓力極大的場景，可以考慮使用進程內緩存。

例如，秒殺業務，并發量極高，需要站點層擋住流量，可以使用內存緩存。

情況三

一定程度上允許數據不一致業務。

例如，有一些計數場景，運營場景，頁面對數據一致性要求較低，可以考慮使用進程內頁面緩存。

再次強調，進程內緩存的適用場景并不如redis/memcache廣泛，不要為了炫技而使用。更多的時候，還是老老實實使用redis/mc吧。