本文主要討論這么幾個問題：

(1)“緩存與數(shù)據(jù)庫”需求緣起

(2)“淘汰緩存”還是“更新緩存”

(3)緩存和數(shù)據(jù)庫的操作時序

(4)緩存和數(shù)據(jù)庫架構簡析

一、需求緣起

場景介紹

緩存是一種提高系統(tǒng)讀性能的常見技術，對于讀多寫少的應用場景，我們經(jīng)常使用緩存來進行優(yōu)化。

例如對于用戶的余額信息表account(uid, money)，業(yè)務上的需求是：

(1)查詢用戶的余額，SELECT money FROM account WHERE uid=XXX，占99%的請求

(2)更改用戶余額，UPDATE account SET money=XXX WHERE uid=XXX，占1%的請求

由于大部分的請求是查詢，我們在緩存中建立uid到money的鍵值對，能夠極大降低數(shù)據(jù)庫的壓力。

讀操作流程

有了數(shù)據(jù)庫和緩存兩個地方存放數(shù)據(jù)之后(uid->money)，每當需要讀取相關數(shù)據(jù)時(money)，操作流程一般是這樣的：

(1)讀取緩存中是否有相關數(shù)據(jù)，uid->money

(2)如果緩存中有相關數(shù)據(jù)money，則返回【這就是所謂的數(shù)據(jù)***“hit”】

(3)如果緩存中沒有相關數(shù)據(jù)money，則從數(shù)據(jù)庫讀取相關數(shù)據(jù)money【這就是所謂的數(shù)據(jù)未***“miss”】，放入緩存中uid->money，再返回

緩存的***率 = ***緩存請求個數(shù)/總緩存訪問請求個數(shù) = hit/(hit+miss)

上面舉例的余額場景，99%的讀，1%的寫，這個緩存的***率是非常高的，會在95%以上。

那么問題來了

當數(shù)據(jù)money發(fā)生變化的時候：

(1)是更新緩存中的數(shù)據(jù)，還是淘汰緩存中的數(shù)據(jù)呢?

(2)是先操縱數(shù)據(jù)庫中的數(shù)據(jù)再操縱緩存中的數(shù)據(jù)，還是先操縱緩存中的數(shù)據(jù)再操縱數(shù)據(jù)庫中的數(shù)據(jù)呢?

(3)緩存與數(shù)據(jù)庫的操作，在架構上是否有優(yōu)化的空間呢?

這是本文關注的三個核心問題。

二、更新緩存 VS 淘汰緩存

什么是更新緩存：數(shù)據(jù)不但寫入數(shù)據(jù)庫，還會寫入緩存

什么是淘汰緩存：數(shù)據(jù)只會寫入數(shù)據(jù)庫，不會寫入緩存，只會把數(shù)據(jù)淘汰掉

更新緩存的優(yōu)點：緩存不會增加一次miss，***率高

淘汰緩存的優(yōu)點：簡單(我去，更新緩存我也覺得很簡單呀，樓主你太敷衍了吧)

那到底是選擇更新緩存還是淘汰緩存呢，主要取決于“更新緩存的復雜度”。

例如，上述場景，只是簡單的把余額money設置成一個值，那么：

(1)淘汰緩存的操作為deleteCache(uid)

(2)更新緩存的操作為setCache(uid, money)

更新緩存的代價很小，此時我們應該更傾向于更新緩存，以保證更高的緩存***率

如果余額是通過很復雜的數(shù)據(jù)計算得出來的，例如業(yè)務上除了賬戶表account，還有商品表product，折扣表discount

account(uid, money)

product(pid, type, price, pinfo)

discount(type, zhekou)

業(yè)務場景是用戶買了一個商品product，這個商品的價格是price，這個商品從屬于type類商品，type類商品在做促銷活動要打折扣zhekou，購買了商品過后，這個余額的計算就復雜了，需要：

(1)先把商品的品類，價格取出來：SELECT type, price FROM product WHERE pid=XXX

(2)再把這個品類的折扣取出來：SELECT zhekou FROM discount WHERE type=XXX

(3)再把原有余額從緩存中查詢出來money = getCache(uid)

(4)再把新的余額寫入到緩存中去setCache(uid, money-price*zhekou)

更新緩存的代價很大，此時我們應該更傾向于淘汰緩存。

however，淘汰緩存操作簡單，并且?guī)淼母弊饔弥皇窃黾恿艘淮蝐ache miss，建議作為通用的處理方式。

三、先操作數(shù)據(jù)庫 vs 先操作緩存

OK，當寫操作發(fā)生時，假設淘汰緩存作為對緩存通用的處理方式，又面臨兩種抉擇：

(1)先寫數(shù)據(jù)庫，再淘汰緩存

(2)先淘汰緩存，再寫數(shù)據(jù)庫

究竟采用哪種時序呢?

還記得在《冗余表如何保證數(shù)據(jù)一致性》文章(點擊查看)里“究竟先寫正表還是先寫反表”的結論么?

對于一個不能保證事務性的操作，一定涉及“哪個任務先做，哪個任務后做”的問題，解決這個問題的方向是：

如果出現(xiàn)不一致，誰先做對業(yè)務的影響較小，就誰先執(zhí)行。

由于寫數(shù)據(jù)庫與淘汰緩存不能保證原子性，誰先誰后同樣要遵循上述原則。

假設先寫數(shù)據(jù)庫，再淘汰緩存：***步寫數(shù)據(jù)庫操作成功，第二步淘汰緩存失敗，則會出現(xiàn)DB中是新數(shù)據(jù)，Cache中是舊數(shù)據(jù)，數(shù)據(jù)不一致。

假設先淘汰緩存，再寫數(shù)據(jù)庫：***步淘汰緩存成功，第二步寫數(shù)據(jù)庫失敗，則只會引發(fā)一次Cache miss。

結論：數(shù)據(jù)和緩存的操作時序，結論是清楚的：先淘汰緩存，再寫數(shù)據(jù)庫。

四、緩存架構優(yōu)化

上述緩存架構有一個缺點：業(yè)務方需要同時關注緩存與DB，有沒有進一步的優(yōu)化空間呢?有兩種常見的方案，一種主流方案，一種非主流方案(一家之言，勿拍)。

主流優(yōu)化方案是服務化：加入一個服務層，向上游提供帥氣的數(shù)據(jù)訪問接口，向上游屏蔽底層數(shù)據(jù)存儲的細節(jié)，這樣業(yè)務線不需要關注數(shù)據(jù)是來自于cache還是DB。

非主流方案是異步緩存更新：業(yè)務線所有的寫操作都走數(shù)據(jù)庫，所有的讀操作都總緩存，由一個異步的工具來做數(shù)據(jù)庫與緩存之間數(shù)據(jù)的同步，具體細節(jié)是：

(1)要有一個init cache的過程，將需要緩存的數(shù)據(jù)全量寫入cache

(2)如果DB有寫操作，異步更新程序讀取binlog，更新cache

在(1)和(2)的合作下，cache中有全部的數(shù)據(jù)，這樣：

(a)業(yè)務線讀cache，一定能夠hit(很短的時間內(nèi)，可能有臟數(shù)據(jù))，無需關注數(shù)據(jù)庫

(b)業(yè)務線寫DB，cache中能得到異步更新，無需關注緩存

這樣將大大簡化業(yè)務線的調用邏輯，存在的缺點是，如果緩存的數(shù)據(jù)業(yè)務邏輯比較復雜，async-update異步更新的邏輯可能也會比較復雜。

五、其他未盡事宜

本文只討論了緩存架構設計中需要注意的幾個細節(jié)點，如果數(shù)據(jù)庫架構采用了一主多從，讀寫分離的架構，在特殊時序下，還很可能引發(fā)數(shù)據(jù)庫與緩存的不一致，這個不一致如何優(yōu)化，后續(xù)的文章再討論吧。

六、結論強調

(1)淘汰緩存是一種通用的緩存處理方式

(2)先淘汰緩存，再寫數(shù)據(jù)庫的時序是毋庸置疑的

(3)服務化是向業(yè)務方屏蔽底層數(shù)據(jù)庫與緩存復雜性的一種通用方式

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】