參考：
如何保證緩存與數(shù)據(jù)庫的雙寫一致性？

一般來說，如果允許緩存可以稍微的跟數(shù)據(jù)庫偶爾有不一致的情況，也就是說如果你的系統(tǒng)不是嚴(yán)格要求 “緩存+數(shù)據(jù)庫” 必須保持一致性的話，最好不要做這個(gè)方案，即：讀請(qǐng)求和寫請(qǐng)求串行化，串到一個(gè)內(nèi)存隊(duì)列里去。
串行化可以保證一定不會(huì)出現(xiàn)不一致的情況，但是它也會(huì)導(dǎo)致系統(tǒng)的吞吐量大幅度降低，用比正常情況下多幾倍的機(jī)器去支撐線上的一個(gè)請(qǐng)求。

1.Cache Aside Pattern

最經(jīng)典的緩存+數(shù)據(jù)庫讀寫的模式，就是 Cache Aside Pattern。

• 讀的時(shí)候，先讀緩存，緩存沒有的話，就讀數(shù)據(jù)庫，然后取出數(shù)據(jù)后放入緩存，同時(shí)返回響應(yīng)。
• 更新的時(shí)候，先更新數(shù)據(jù)庫，然后再刪除緩存。

A.為什么是刪除緩存，而不是更新緩存？

原因很簡單，很多時(shí)候，在復(fù)雜點(diǎn)的緩存場景，緩存不單單是數(shù)據(jù)庫中直接取出來的值。比如可能更新了某個(gè)表的一個(gè)字段，然后其對(duì)應(yīng)的緩存，是需要查詢另外兩個(gè)表的數(shù)據(jù)并進(jìn)行運(yùn)算，才能計(jì)算出緩存最新的值的。
另外更新緩存的代價(jià)有時(shí)候是很高的。每次修改數(shù)據(jù)庫的時(shí)候，都一定要將其對(duì)應(yīng)的緩存更新一份？這個(gè)緩存到底會(huì)不會(huì)被頻繁訪問到？

其實(shí)刪除緩存，而不是更新緩存，就是一個(gè) lazy 計(jì)算的思想，不要每次都重新做復(fù)雜的計(jì)算，不管它會(huì)不會(huì)用到，而是讓它到需要被使用的時(shí)候再重新計(jì)算。像 mybatis，hibernate，都有懶加載思想。

2.最初級(jí)的緩存不一致問題及解決方案

先更新數(shù)據(jù)庫，再刪除緩存。如果刪除緩存失敗了，那么會(huì)導(dǎo)致數(shù)據(jù)庫中是新數(shù)據(jù)，緩存中是舊數(shù)據(jù)，數(shù)據(jù)就出現(xiàn)了不一致。

解決思路：
先刪除緩存，再更新數(shù)據(jù)庫。如果數(shù)據(jù)庫更新失敗了，那么數(shù)據(jù)庫中是舊數(shù)據(jù)，緩存中是空的，那么數(shù)據(jù)不會(huì)不一致。
因?yàn)樽x的時(shí)候緩存沒有，所以去讀了數(shù)據(jù)庫中的舊數(shù)據(jù)，然后更新到緩存中。

3.比較復(fù)雜的數(shù)據(jù)不一致問題分析

數(shù)據(jù)發(fā)生了變更，先刪除了緩存，然后要去修改數(shù)據(jù)庫，此時(shí)還沒修改。一個(gè)請(qǐng)求過來，去讀緩存，發(fā)現(xiàn)緩存空了，去查詢數(shù)據(jù)庫，查到了修改前的舊數(shù)據(jù)，放到了緩存中。隨后數(shù)據(jù)變更的程序完成了數(shù)據(jù)庫的修改。完了，數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一樣了...

A.為什么上億流量高并發(fā)場景下，緩存會(huì)出現(xiàn)這個(gè)問題？

只有在對(duì)一個(gè)數(shù)據(jù)在并發(fā)的進(jìn)行讀寫的時(shí)候，才可能會(huì)出現(xiàn)這種問題。如果并發(fā)量很低的情況下，不會(huì)出現(xiàn)剛才描述的那種不一致的場景。
如果每天的是上億的流量，每秒并發(fā)讀是幾萬，每秒只要有數(shù)據(jù)更新的請(qǐng)求，就可能會(huì)出現(xiàn)上述的數(shù)據(jù)庫+緩存不一致的情況。

B.解決方案如下：

更新數(shù)據(jù)的時(shí)候，根據(jù)數(shù)據(jù)的唯一標(biāo)識(shí)，將操作路由之后，發(fā)送到一個(gè) jvm 內(nèi)部隊(duì)列中。讀取數(shù)據(jù)的時(shí)候，如果發(fā)現(xiàn)數(shù)據(jù)不在緩存中，那么將重新執(zhí)行“讀取數(shù)據(jù)+更新緩存”的操作，根據(jù)唯一標(biāo)識(shí)路由之后，也發(fā)送到同一個(gè) jvm 內(nèi)部隊(duì)列中。
一個(gè)隊(duì)列對(duì)應(yīng)一個(gè)工作線程，每個(gè)工作線程串行拿到對(duì)應(yīng)的操作，然后一條一條的執(zhí)行。這樣的話，一個(gè)數(shù)據(jù)變更的操作，先刪除緩存，然后再去更新數(shù)據(jù)庫，但是還沒完成更新。此時(shí)如果一個(gè)讀請(qǐng)求過來，沒有讀到緩存，那么可以先將緩存更新的請(qǐng)求發(fā)送到隊(duì)列中，此時(shí)會(huì)在隊(duì)列中積壓，然后同步等待緩存更新完成。
這里有一個(gè)優(yōu)化點(diǎn)，一個(gè)隊(duì)列中，其實(shí)多個(gè)更新緩存請(qǐng)求串在一起是沒意義的，因此可以做過濾，如果發(fā)現(xiàn)隊(duì)列中已經(jīng)有一個(gè)更新緩存的請(qǐng)求了，那么就不用再放個(gè)更新請(qǐng)求操作進(jìn)去了，直接等待前面的更新操作請(qǐng)求完成即可。
待那個(gè)隊(duì)列對(duì)應(yīng)的工作線程完成了上一個(gè)操作的數(shù)據(jù)庫的修改之后，才會(huì)去執(zhí)行下一個(gè)操作，也就是緩存更新的操作，此時(shí)會(huì)從數(shù)據(jù)庫中讀取最新的值，然后寫入緩存中。
如果請(qǐng)求還在等待時(shí)間范圍內(nèi)，不斷輪詢發(fā)現(xiàn)可以取到值了，那么就直接返回；如果請(qǐng)求等待的時(shí)間超過一定時(shí)長，那么這一次直接從數(shù)據(jù)庫中讀取當(dāng)前的舊值。

C.高并發(fā)的場景下，該解決方案要注意的問題：

m.讀請(qǐng)求長時(shí)阻塞

由于讀請(qǐng)求進(jìn)行了非常輕度的異步化，所以一定要注意讀超時(shí)的問題，每個(gè)讀請(qǐng)求必須在超時(shí)時(shí)間范圍內(nèi)返回。
該解決方案，最大的風(fēng)險(xiǎn)點(diǎn)在于說，可能數(shù)據(jù)更新很頻繁，導(dǎo)致隊(duì)列中積壓了大量更新操作在里面，然后讀請(qǐng)求會(huì)發(fā)生大量的超時(shí)，最后導(dǎo)致大量的請(qǐng)求直接走數(shù)據(jù)庫。

m.讀請(qǐng)求并發(fā)量過高

突然間大量讀請(qǐng)求會(huì)在幾十毫秒的延時(shí)行在服務(wù)上，看服務(wù)能不能扛的住，需要多少機(jī)器才能扛住最大的極限情況的峰值。

m.多服務(wù)實(shí)例部署的請(qǐng)求路由

可能這個(gè)服務(wù)部署了多個(gè)實(shí)例，那么必須保證說，執(zhí)行數(shù)據(jù)更新操作，以及執(zhí)行緩存更新操作的請(qǐng)求，都通過 Nginx 服務(wù)器路由到相同的服務(wù)實(shí)例上。

m.熱點(diǎn)商品的路由問題，導(dǎo)致請(qǐng)求的傾斜

萬一某個(gè)商品的讀寫請(qǐng)求特別高，全部打到相同的機(jī)器的相同的隊(duì)列里面去了，可能會(huì)造成某臺(tái)機(jī)器的壓力過大。就是說，因?yàn)橹挥性谏唐窋?shù)據(jù)更新的時(shí)候才會(huì)清空緩存，然后才會(huì)導(dǎo)致讀寫并發(fā)，所以其實(shí)要根據(jù)業(yè)務(wù)系統(tǒng)去看，如果更新頻率不是太高的話，這個(gè)問題的影響并不是特別大，但是的確可能某些機(jī)器的負(fù)載會(huì)高一些。