快取架構設計二三事
本文主要討論這麼幾個問題：
1. “快取與資料庫”需求緣起
2. “淘汰快取”還是“更新快取”
3. 快取和資料庫的操作時序
4. 快取和資料庫架構簡析
一、需求緣起
場景介紹
快取是一種提高系統讀效能的常見技術，對於讀多寫少的應用場景，我們經常使用快取來進行優化。
錄入對於使用者的餘額資訊表account(uid,money)，業務上的需求是：
（1）查詢使用者的餘額，SELECT money FROM account WHERE uid=XXX，佔99%的請求
（2）更改使用者餘額，UPDATE account SET money=XXX WHERE uid=XXX，佔1%的請求
由於大部分的請求時查詢，我們在快取中建立uid到money的鍵值對，能夠極大降低資料庫的壓力。
讀操作流程
有了資料庫和快取兩個地方存放資料之後（uid->money）,每當需要讀取相關資料時（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）更新快取的操作為detCache(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=XXX
（2）再把這個品類的折扣取出來：SELECT zhekou FROM discount WHERE type=XXX
（3）再把原有餘額從快取中查詢出來money = getCache(uid)
（4）再把新的餘額寫入到快取中去setCache(uid, money-price*zhekou)
更新快取的代價很大，此時我們應該更傾向於淘汰快取。
however，淘汰快取操作簡單，並且帶來的副作用只是增加了一次cache miss，建議作為通用的處理方式。
## 三、先操作資料庫 VS 先操作快取
OK，當寫操作發生時，假設淘汰快取作為對快取通用的處理方式，又面臨兩種抉擇：
（1）先寫資料庫，再淘汰快取
（2）先淘汰快取，再寫資料庫
究竟採用哪種時序呢？
對於一個不能保證事務性的操作，一定涉及“哪個任務先做，哪個任務後做”的問題，解決這個問題的方向是：
如果出現不一致，誰先做對業務的影響較小，就誰先執行。
由於寫資料庫與淘汰快取不能保證原子性，誰先誰後同樣要遵守上述原則。
假設先寫資料庫，再淘汰快取：第一步寫資料庫操作成功，第二步淘汰快取失敗，則會出現DB中是新資料，Cache中是舊資料，資料不一致。
假設先淘汰快取，再寫資料庫：第一步淘汰快取成功，第二步寫資料庫失敗，則只會引發一次Cache miss。
結論：資料和快取的操作時序，結論是清楚的：先淘汰快取，再寫資料庫。
四、快取架構優化
上述快取架構有一個缺點：業務方需要同時關注快取與DB，有沒有進一步的優化空間呢？有兩種常見的方案，一種主流方案，一種非主流方案。
主流優化方案是服務化：加入一個服務層，向上遊提供帥氣的資料訪問介面，向上遊遮蔽底層資料儲存的細節，這樣業務線不需要關注資料是來自於cache還是DB。
非主流方案是非同步快取更新： 業務線所有的寫操作都走資料庫，所有的都操作都走快取，有一個非同步的工具來做資料庫與快取之間資料的同步，具體細節是：
（1）要有一個 init cache 的過程，將需要快取的資料全量寫入cache
（2）如果DB有寫操作，非同步更新程式讀取binlog，更新cache
在（1）和（2）的合作下，cache中有全部的資料，這樣：
（a）業務線讀cache，一定能夠hit（很短的時間內，可能有髒資料），無需關注資料庫
（b）業務線寫DB，cache中能得到非同步更新，無需關注快取
這樣將大大簡化業務線的呼叫邏輯，存在的缺點是，如果快取的資料業務邏輯比較複雜，async-update非同步更新的邏輯可能也會比較複雜。
五、其他未盡事宜
本文只討論了快取架構設計中需要注意的幾個細節點，如果資料庫架構採用了一主多從，讀寫分離的架構在特殊時序下，還很可能引發資料庫與快取的不一致，這個不一致如何優化，後續的文章再討論吧。
六、結論強調
（1）淘汰快取是一種通用的快取處理方式
（2）先淘汰快取，再寫資料庫的時序是毋庸置疑的
（3）服務化是想業務方遮蔽底層資料庫與快取複雜性的一種通用方式·