redis使用啥的就不說了，網(wǎng)上資料很多吩翻，本文主要講使用緩存的一些設(shè)計(jì)模式兜看；
以下幾個(gè)緩存模式，本身是微軟用在操作系統(tǒng)中的仿野，此處借用來用于微服務(wù)中也是合適的铣减；文末有微軟的鏈接；
緩存的重要性：磁盤一次操作10 ms左右脚作，內(nèi)存一次操作65 ns左右葫哗，1 ms = 10^6 ns，差了好幾個(gè)量級(jí)
1.read-through讀穿透模式
應(yīng)用讀取數(shù)據(jù)球涛，只讀取緩存數(shù)據(jù)劣针；緩存自己保證與數(shù)據(jù)庫(kù)的同步性
2.write-through寫穿透
應(yīng)用數(shù)據(jù)只寫入緩存体箕，由緩存自身保證同步到數(shù)據(jù)庫(kù)姜性；
3.write-behind
應(yīng)用數(shù)據(jù)只寫入緩存，緩存自身保證但是不立即同步到數(shù)據(jù)庫(kù)大州，會(huì)有一定延時(shí)从祝，批量寫入
參考write-behind
4.cache-aside
這種模式襟己，是用在沒有緩存框架保證上述三種模式時(shí)，用來模仿上述三種模式牍陌；
也是平常業(yè)務(wù)系統(tǒng)最常用的模式擎浴；
增：寫數(shù)據(jù)庫(kù)；
刪：刪數(shù)據(jù)庫(kù)毒涧，然后失效緩存贮预；
改：更新數(shù)據(jù)庫(kù)，然后失效緩存
查：命中緩存則返回契讲；不命中數(shù)據(jù)庫(kù)仿吞，則查詢數(shù)據(jù)庫(kù)，同時(shí)更新緩存捡偏；
注：緩存設(shè)計(jì)要注意緩存雪崩唤冈、緩存穿透、緩存擊穿問題
5.實(shí)例一
背景：業(yè)務(wù)中有一批和門店相關(guān)數(shù)據(jù)银伟，每天只更新1-2次你虹，但是查詢QPS極高
模式：低頻更新凉当、高頻查詢的數(shù)據(jù)，cache-aside售葡；
6.實(shí)例二
背景：業(yè)務(wù)中有一批動(dòng)態(tài)數(shù)據(jù)忠藤，一批用戶實(shí)時(shí)產(chǎn)生挟伙，一批用戶在app上實(shí)時(shí)查詢，增刪改查QPS都非常高模孩；
模式：高頻更新尖阔、高頻查詢的數(shù)據(jù)，采用write-behind + read-through模式
使用兩個(gè)緩存:寫緩存榨咐、讀緩存
7.實(shí)例一+實(shí)例二
背景：一般業(yè)務(wù)系統(tǒng)，實(shí)例一和實(shí)例二都是同時(shí)存在的块茁；
方案：緩存設(shè)計(jì)兩個(gè)齿坷，一個(gè)讀緩存+一個(gè)寫緩存，同時(shí)滿足實(shí)例一和實(shí)例二中數(shù)據(jù)数焊；數(shù)據(jù)庫(kù)可以分別寫到不同的業(yè)務(wù)系統(tǒng)中去永淌；
當(dāng)然，上面的設(shè)計(jì)模式是存在很多并發(fā)問題的：
比如高頻更新模式佩耳，某條數(shù)據(jù)遂蛀，緩存已失效，這會(huì)如果讀數(shù)據(jù)并且更新緩存干厚，不是一個(gè)原子性操作李滴，中間有個(gè)GC停頓啥的就更久了；這兩個(gè)操作中間蛮瞄，如果數(shù)據(jù)庫(kù)中數(shù)據(jù)被更新所坯，那么最終更新到緩存的是過期數(shù)據(jù)；
當(dāng)然裕坊，概率不大包竹，當(dāng)時(shí)必須要考慮到這點(diǎn)；
那是要去解決這個(gè)問題嗎籍凝？雖然你可能通過更復(fù)雜的事務(wù)模式周瞎，鬼斧神工地去保證事務(wù)性，但是復(fù)雜度太高饵蒂，做一次容易声诸，業(yè)務(wù)一直保持正確難，不太建議那么干退盯；我建議你避開它彼乌，上述模式使用必須進(jìn)行業(yè)務(wù)判斷是否允許少量此種情況出現(xiàn)泻肯；
有些業(yè)務(wù)場(chǎng)景強(qiáng)依賴數(shù)據(jù)正確性比如金額計(jì)算啥的，就不能用緩存來做慰照；
而應(yīng)該使用強(qiáng)事務(wù)性的數(shù)據(jù)庫(kù)灶挟；
金融行業(yè)推薦螞蟻的OceanBase
當(dāng)然，還有個(gè)更好用的工具去更新緩存：databus了解下毒租，追數(shù)據(jù)庫(kù)日志稚铣，并解析操作；
參考資料：
https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside
