馬上開始去開發(fā)業(yè)務(wù)系統(tǒng)

從哪一步開始做，從比較簡單的那一塊開始做，實(shí)時(shí)性要求比較高的那塊數(shù)據(jù)的緩存去做

實(shí)時(shí)性比較高的數(shù)據(jù)緩存，選擇的就是庫存的服務(wù)

庫存可能會(huì)修改，每次修改都要去更新這個(gè)緩存數(shù)據(jù); 每次庫存的數(shù)據(jù)，在緩存中一旦過期，或者是被清理掉了，前端的nginx服務(wù)都會(huì)發(fā)送請求給庫存服務(wù)，去獲取相應(yīng)的數(shù)據(jù)

庫存這一塊，寫數(shù)據(jù)庫的時(shí)候，直接更新redis緩存

實(shí)際上沒有這么的簡單，這里，其實(shí)就涉及到了一個(gè)問題，數(shù)據(jù)庫與緩存雙寫，數(shù)據(jù)不一致的問題

圍繞和結(jié)合實(shí)時(shí)性較高的庫存服務(wù)，把數(shù)據(jù)庫與緩存雙寫不一致問題以及其解決方案，給大家講解一下

數(shù)據(jù)庫與緩存雙寫不一致，很常見的問題，大型的緩存架構(gòu)中，第一個(gè)解決方案

大型的緩存架構(gòu)全部講解完了以后，整套架構(gòu)是非常復(fù)雜，架構(gòu)可以應(yīng)對各種各樣奇葩和極端的情況

也有一種可能，不是說，來講課的就是超人，萬能的

講課，就跟寫書一樣，很可能會(huì)寫錯(cuò)，也可能有些方案里的一些地方，我沒考慮到

也可能說，有些方案只是適合某些場景，在某些場景下，可能需要你進(jìn)行方案的優(yōu)化和調(diào)整才能適用于你自己的項(xiàng)目

大家覺得對這些方案有什么疑問或者見解，都可以找我，溝通一下

如果的確我覺得是我講解的不對，或者有些地方考慮不周，那么我可以在視頻里補(bǔ)錄，更新到網(wǎng)站上面去

多多包涵

1、最初級的緩存不一致問題以及解決方案

問題：先修改數(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ù)，然后更新到緩存中

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

數(shù)據(jù)發(fā)生了變更，先刪除了緩存，然后要去修改數(shù)據(jù)庫，此時(shí)還沒修改

一個(gè)請求過來，去讀緩存，發(fā)現(xiàn)緩存空了，去查詢數(shù)據(jù)庫，查到了修改前的舊數(shù)據(jù)，放到了緩存中

數(shù)據(jù)變更的程序完成了數(shù)據(jù)庫的修改

完了，數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一樣了。。。。

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

只有在對一個(gè)數(shù)據(jù)在并發(fā)的進(jìn)行讀寫的時(shí)候，才可能會(huì)出現(xiàn)這種問題

其實(shí)如果說你的并發(fā)量很低的話，特別是讀并發(fā)很低，每天訪問量就1萬次，那么很少的情況下，會(huì)出現(xiàn)剛才描述的那種不一致的場景

但是問題是，如果每天的是上億的流量，每秒并發(fā)讀是幾萬，每秒只要有數(shù)據(jù)更新的請求，就可能會(huì)出現(xiàn)上述的數(shù)據(jù)庫+緩存不一致的情況

高并發(fā)了以后，問題是很多的

4、數(shù)據(jù)庫與緩存更新與讀取操作進(jìn)行異步串行化

更新數(shù)據(jù)的時(shí)候，根據(jù)數(shù)據(jù)的唯一標(biāo)識(shí)，將操作路由之后，發(fā)送到一個(gè)jvm內(nèi)部的隊(duì)列中

讀取數(shù)據(jù)的時(shí)候，如果發(fā)現(xiàn)數(shù)據(jù)不在緩存中，那么將重新讀取數(shù)據(jù)+更新緩存的操作，根據(jù)唯一標(biāo)識(shí)路由之后，也發(fā)送同一個(gè)jvm內(nèi)部的隊(duì)列中

一個(gè)隊(duì)列對應(yīng)一個(gè)工作線程

每個(gè)工作線程串行拿到對應(yīng)的操作，然后一條一條的執(zhí)行

這樣的話，一個(gè)數(shù)據(jù)變更的操作，先執(zhí)行，刪除緩存，然后再去更新數(shù)據(jù)庫，但是還沒完成更新

此時(shí)如果一個(gè)讀請求過來，讀到了空的緩存，那么可以先將緩存更新的請求發(fā)送到隊(duì)列中，此時(shí)會(huì)在隊(duì)列中積壓，然后同步等待緩存更新完成

這里有一個(gè)優(yōu)化點(diǎn)，一個(gè)隊(duì)列中，其實(shí)多個(gè)更新緩存請求串在一起是沒意義的，因此可以做過濾，如果發(fā)現(xiàn)隊(duì)列中已經(jīng)有一個(gè)更新緩存的請求了，那么就不用再放個(gè)更新請求操作進(jìn)去了，直接等待前面的更新操作請求完成即可

待那個(gè)隊(duì)列對應(yīng)的工作線程完成了上一個(gè)操作的數(shù)據(jù)庫的修改之后，才會(huì)去執(zhí)行下一個(gè)操作，也就是緩存更新的操作，此時(shí)會(huì)從數(shù)據(jù)庫中讀取最新的值，然后寫入緩存中

如果請求還在等待時(shí)間范圍內(nèi)，不斷輪詢發(fā)現(xiàn)可以取到值了，那么就直接返回; 如果請求等待的時(shí)間超過一定時(shí)長，那么這一次直接從數(shù)據(jù)庫中讀取當(dāng)前的舊值

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

（1）讀請求長時(shí)阻塞

由于讀請求進(jìn)行了非常輕度的異步化，所以一定要注意讀超時(shí)的問題，每個(gè)讀請求必須在超時(shí)時(shí)間范圍內(nèi)返回

該解決方案，最大的風(fēng)險(xiǎn)點(diǎn)在于說，可能數(shù)據(jù)更新很頻繁，導(dǎo)致隊(duì)列中積壓了大量更新操作在里面，然后讀請求會(huì)發(fā)生大量的超時(shí)，最后導(dǎo)致大量的請求直接走數(shù)據(jù)庫

務(wù)必通過一些模擬真實(shí)的測試，看看更新數(shù)據(jù)的頻繁是怎樣的

另外一點(diǎn)，因?yàn)橐粋€(gè)隊(duì)列中，可能會(huì)積壓針對多個(gè)數(shù)據(jù)項(xiàng)的更新操作，因此需要根據(jù)自己的業(yè)務(wù)情況進(jìn)行測試，可能需要部署多個(gè)服務(wù)，每個(gè)服務(wù)分?jǐn)傄恍?shù)據(jù)的更新操作

如果一個(gè)內(nèi)存隊(duì)列里居然會(huì)擠壓100個(gè)商品的庫存修改操作，每隔庫存修改操作要耗費(fèi)10ms區(qū)完成，那么最后一個(gè)商品的讀請求，可能等待10 * 100 = 1000ms = 1s后，才能得到數(shù)據(jù)

這個(gè)時(shí)候就導(dǎo)致讀請求的長時(shí)阻塞

一定要做根據(jù)實(shí)際業(yè)務(wù)系統(tǒng)的運(yùn)行情況，去進(jìn)行一些壓力測試，和模擬線上環(huán)境，去看看最繁忙的時(shí)候，內(nèi)存隊(duì)列可能會(huì)擠壓多少更新操作，可能會(huì)導(dǎo)致最后一個(gè)更新操作對應(yīng)的讀請求，會(huì)hang多少時(shí)間，如果讀請求在200ms返回，如果你計(jì)算過后，哪怕是最繁忙的時(shí)候，積壓10個(gè)更新操作，最多等待200ms，那還可以的

如果一個(gè)內(nèi)存隊(duì)列可能積壓的更新操作特別多，那么你就要加機(jī)器，讓每個(gè)機(jī)器上部署的服務(wù)實(shí)例處理更少的數(shù)據(jù)，那么每個(gè)內(nèi)存隊(duì)列中積壓的更新操作就會(huì)越少

其實(shí)根據(jù)之前的項(xiàng)目經(jīng)驗(yàn)，一般來說數(shù)據(jù)的寫頻率是很低的，因此實(shí)際上正常來說，在隊(duì)列中積壓的更新操作應(yīng)該是很少的

針對讀高并發(fā)，讀緩存架構(gòu)的項(xiàng)目，一般寫請求相對讀來說，是非常非常少的，每秒的QPS能到幾百就不錯(cuò)了

一秒，500的寫操作，5份，每200ms，就100個(gè)寫操作

單機(jī)器，20個(gè)內(nèi)存隊(duì)列，每個(gè)內(nèi)存隊(duì)列，可能就積壓5個(gè)寫操作，每個(gè)寫操作性能測試后，一般在20ms左右就完成

那么針對每個(gè)內(nèi)存隊(duì)列中的數(shù)據(jù)的讀請求，也就最多hang一會(huì)兒，200ms以內(nèi)肯定能返回了

寫QPS擴(kuò)大10倍，但是經(jīng)過剛才的測算，就知道，單機(jī)支撐寫QPS幾百?zèng)]問題，那么就擴(kuò)容機(jī)器，擴(kuò)容10倍的機(jī)器，10臺(tái)機(jī)器，每個(gè)機(jī)器20個(gè)隊(duì)列，200個(gè)隊(duì)列

大部分的情況下，應(yīng)該是這樣的，大量的讀請求過來，都是直接走緩存取到數(shù)據(jù)的

少量情況下，可能遇到讀跟數(shù)據(jù)更新沖突的情況，如上所述，那么此時(shí)更新操作如果先入隊(duì)列，之后可能會(huì)瞬間來了對這個(gè)數(shù)據(jù)大量的讀請求，但是因?yàn)樽隽巳ブ氐膬?yōu)化，所以也就一個(gè)更新緩存的操作跟在它后面

等數(shù)據(jù)更新完了，讀請求觸發(fā)的緩存更新操作也完成，然后臨時(shí)等待的讀請求全部可以讀到緩存中的數(shù)據(jù)

（2）讀請求并發(fā)量過高

這里還必須做好壓力測試，確保恰巧碰上上述情況的時(shí)候，還有一個(gè)風(fēng)險(xiǎn)，就是突然間大量讀請求會(huì)在幾十毫秒的延時(shí)hang在服務(wù)上，看服務(wù)能不能抗的住，需要多少機(jī)器才能抗住最大的極限情況的峰值

但是因?yàn)椴⒉皇撬械臄?shù)據(jù)都在同一時(shí)間更新，緩存也不會(huì)同一時(shí)間失效，所以每次可能也就是少數(shù)數(shù)據(jù)的緩存失效了，然后那些數(shù)據(jù)對應(yīng)的讀請求過來，并發(fā)量應(yīng)該也不會(huì)特別大

按1:99的比例計(jì)算讀和寫的請求，每秒5萬的讀QPS，可能只有500次更新操作

如果一秒有500的寫QPS，那么要測算好，可能寫操作影響的數(shù)據(jù)有500條，這500條數(shù)據(jù)在緩存中失效后，可能導(dǎo)致多少讀請求，發(fā)送讀請求到庫存服務(wù)來，要求更新緩存

一般來說，1:1，1:2，1:3，每秒鐘有1000個(gè)讀請求，會(huì)hang在庫存服務(wù)上，每個(gè)讀請求最多hang多少時(shí)間，200ms就會(huì)返回

在同一時(shí)間最多hang住的可能也就是單機(jī)200個(gè)讀請求，同時(shí)hang住

單機(jī)hang200個(gè)讀請求，還是ok的

1:20，每秒更新500條數(shù)據(jù)，這500秒數(shù)據(jù)對應(yīng)的讀請求，會(huì)有20 * 500 = 1萬

1萬個(gè)讀請求全部hang在庫存服務(wù)上，就死定了

（3）多服務(wù)實(shí)例部署的請求路由

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

（4）熱點(diǎn)商品的路由問題，導(dǎo)致請求的傾斜

萬一某個(gè)商品的讀寫請求特別高，全部打到相同的機(jī)器的相同的隊(duì)列里面去了，可能造成某臺(tái)機(jī)器的壓力過大

就是說，因?yàn)橹挥性谏唐窋?shù)據(jù)更新的時(shí)候才會(huì)清空緩存，然后才會(huì)導(dǎo)致讀寫并發(fā)，所以更新頻率不是太高的話，這個(gè)問題的影響并不是特別大

但是的確可能某些機(jī)器的負(fù)載會(huì)高一些