（1）「快取與資料庫」需求緣起
（2）「淘汰快取」還是「更新快取」
（3）快取和資料庫的操作時序
（4）快取和資料庫架構簡析
一、需求緣起
場景介紹
快取是一種提高系統讀效能的常見技術，對於讀多寫少的應用場景，我們經常使用快取來進行優化。
例如對於使用者的餘額資訊表account(uid, money)，業務上的需求是：
（1）查詢使用者的餘額，select money from account where uid=***，佔99%的請求
（2）更改使用者餘額，update account set money=*** where uid=***，佔1%的請求
[img]
由於大部分的請求是查詢，我們在快取中建立uid到money的鍵值對，能夠極大降低資料庫的壓力。
讀操作流程
（1）讀取快取中是否有相關資料，uid->money
（2）如果快取中有相關資料money，則返回【這就是所謂的資料命中「hit」】
（3）如果快取中沒有相關資料money，則從資料庫讀取相關資料money【這就是所謂的資料未命中「miss」】，放入快取中uid->money，再返回
快取的命中率 = 命中快取請求個數/總快取訪問請求個數 = hit/(hit+miss)
上面舉例的餘額場景，99%的讀，1%的寫，這個快取的命中率是非常高的，會在95%以上。
那麼問題來了
當資料money發生變化的時候：
（1）是更新快取中的資料，還是淘汰快取中的資料呢？
（2）是先操縱資料庫中的資料再操縱快取中的資料，還是先操縱快取中的資料再操縱資料庫中的資料呢？
（3）快取與資料庫的操作，在架構上是否有優化的空間呢？
這是本文關注的三個核心問題。
二、更新快取 vs 淘汰快取
什麼是更新快取：資料不但寫入資料庫，還會寫入快取
什麼是淘汰快取：資料只會寫入資料庫，不會寫入快取，只會把資料淘汰掉
更新快取的優點：快取不會增加一次miss，命中率高
淘汰快取的優點：簡單（我去，更新快取我也覺得很簡單呀，樓主你太敷衍了吧）
那到底是選擇更新快取還是淘汰快取呢，主要取決於「更新快取的複雜度」。
例如，上述場景，只是簡單的把餘額money設定成乙個值，那麼：
（1）淘汰快取的操作為deletecache(uid)
（2）更新快取的操作為setcache(uid, money)
更新快取的代價很小，此時我們應該更傾向於更新快取，以保證更高的快取命中率
如果餘額是通過很複雜的資料計算得出來的，例如業務上除了賬戶表account，還有商品表product，折扣表discount
account(uid, money)
product(pid, type, price, pinfo)
discount(type, zhekou)
業務場景是使用者買了乙個商品product，這個商品的**是price，這個商品從屬於type類商品，type類商品在做**活動要打折扣zhekou，購買了商品過後，這個餘額的計算就複雜了，需要：
（1）先把商品的品類，**取出來：select type, price from product where pid=***
（2）再把這個品類的折扣取出來：select zhekou from discount where type=***
（3）再把原有餘額從快取中查詢出來money = getcache(uid)
（4）再把新的餘額寫入到快取中去setcache(uid, money-price*zhekou)
更新快取的代價很大，此時我們應該更傾向於淘汰快取。
however，淘汰快取操作簡單，並且帶來的***只是增加了一次cache miss，建議作為通用的處理方式。
三、先運算元據庫 vs 先操作快取
ok，當寫操作發生時，假設淘汰快取作為對快取通用的處理方式，又面臨兩種抉擇：
（1）先寫資料庫，再淘汰快取
（2）先淘汰快取，再寫資料庫
究竟採用哪種時序呢？
對於乙個不能保證事務性的操作，一定涉及「哪個任務先做，哪個任務後做」的問題，解決這個問題的方向是：
如果出現不一致，誰先做對業務的影響較小，就誰先執行。
由於寫資料庫與淘汰快取不能保證原子性，誰先誰後同樣要遵循上述原則。
[img]
假設先寫資料庫，再淘汰快取：第一步寫資料庫操作成功，第二步淘汰快取失敗，則會出現db中是新資料，cache中是舊資料，資料不一致。
[img]
假設先淘汰快取，再寫資料庫：第一步淘汰快取成功，第二步寫資料庫失敗，則只會引發一次cache miss。
結論：資料和快取的操作時序，結論是清楚的：先淘汰快取，再寫資料庫。
四、快取架構優化
[img]
上述快取架構有乙個缺點：業務方需要同時關注快取與db，有沒有進一步的優化空間呢？有兩種常見的方案，一種主流方案，一種非主流方案（一家之言，勿拍）。
[img]
主流優化方案是服務化：加入乙個服務層，向上游提供帥氣的資料訪問介面，向上游遮蔽底層資料儲存的細節，這樣業務線不需要關注資料是來自於cache還是db。
非主流方案是非同步快取更新：業務線所有的寫操作都走資料庫，所有的讀操作都總快取，由乙個非同步的工具來做資料庫與快取之間資料的同步，具體細節是：
（1）要有乙個init cache的過程，將需要快取的資料全量寫入cache
（2）如果db有寫操作，非同步更新程式讀取binlog，更新cache
在（1）和（2）的合作下，cache中有全部的資料，這樣：
（a）業務線讀cache，一定能夠hit（很短的時間內，可能有髒資料），無需關注資料庫
（b）業務線寫db，cache中能得到非同步更新，無需關注快取
這樣將大大簡化業務線的呼叫邏輯，存在的缺點是，如果快取的資料業務邏輯比較複雜，async-update非同步更新的邏輯可能也會比較複雜。
五、其他未盡事宜
六、結論強調
（1）淘汰快取是一種通用的快取處理方式
（2）先淘汰快取，再寫資料庫的時序是毋庸置疑的
（3）服務化是向業務方遮蔽底層資料庫與快取複雜性的一種通用方式
快取架構設計細節二三事
本文主要討論這麼幾個問題 1 快取與資料庫 需求緣起 2 淘汰快取 還是 更新快取 3 快取和資料庫的操作時序 4 快取和資料庫架構簡析 一 需求緣起 場景介紹 快取是一種提高系統讀效能的常見技術，對於讀多寫少的應用場景，我們經常使用快取來進行優化。例如對於使用者的餘額資訊表account uid,...
快取架構設計
快取架構設計 需求分析 快取是一種提高系統讀效能的常見技術，對於讀多寫少的應用場景，我們經常使用快取來進行優化。例如對於使用者的餘額資訊表account uid,money 業務上的需求是 查詢使用者的餘額，select money from account where uid 佔99 的請求 更改...
快取架構設計
1 快取技術和框架的重要性 網際網路的一些高併發，高效能的專案和系統中，快取技術是起著功不可沒的作用。快取不僅僅是key value的簡單訪問，它在具體的業務場景中，還是很複雜的，需要很強的架構設計能力。我曾經就遇到過因為快取架構設計不到位，導致了系統崩潰的案例。2 快取的技術方案分類 1 是做實時...