面試題
如何保證緩存與數(shù)據(jù)庫的雙寫一致性？
面試官心理分析
你只要用緩存译打，就可能會涉及到緩存與數(shù)據(jù)庫雙存儲雙寫耗拓，你只要是雙寫，就一定會有數(shù)據(jù)一致性的問題奏司，那么你如何解決一致性問題乔询？
面試題剖析
一般來說，如果允許緩存可以稍微的跟數(shù)據(jù)庫偶爾有不一致的情況韵洋，也就是說如果你的系統(tǒng)不是嚴(yán)格要求 “緩存+數(shù)據(jù)庫” 必須保持一致性的話竿刁，最好不要做這個方案黄锤，即：讀請求和寫請求串行化，串到一個內(nèi)存隊列里去食拜。
串行化可以保證一定不會出現(xiàn)不一致的情況鸵熟，但是它也會導(dǎo)致系統(tǒng)的吞吐量大幅度降低，用比正常情況下多幾倍的機器去支撐線上的一個請求负甸。
Cache Aside Pattern
最經(jīng)典的緩存+數(shù)據(jù)庫讀寫的模式流强，就是 Cache Aside Pattern。
- 讀的時候呻待，先讀緩存打月，緩存沒有的話，就讀數(shù)據(jù)庫蚕捉，然后取出數(shù)據(jù)后放入緩存奏篙，同時返回響應(yīng)。
- 更新的時候迫淹，先更新數(shù)據(jù)庫秘通，然后再刪除緩存。
為什么是刪除緩存敛熬，而不是更新緩存肺稀？
原因很簡單，很多時候荸型，在復(fù)雜點的緩存場景盹靴，緩存不單單是數(shù)據(jù)庫中直接取出來的值。
比如可能更新了某個表的一個字段瑞妇，然后其對應(yīng)的緩存稿静，是需要查詢另外兩個表的數(shù)據(jù)并進(jìn)行運算，才能計算出緩存最新的值的辕狰。
另外更新緩存的代價有時候是很高的改备。是不是說，每次修改數(shù)據(jù)庫的時候蔓倍，都一定要將其對應(yīng)的緩存更新一份悬钳？也許有的場景是這樣，但是對于比較復(fù)雜的緩存數(shù)據(jù)計算的場景偶翅，就不是這樣了默勾。如果你頻繁修改一個緩存涉及的多個表，緩存也頻繁更新聚谁。但是問題在于母剥，這個緩存到底會不會被頻繁訪問到？
舉個栗子，一個緩存涉及的表的字段环疼，在 1 分鐘內(nèi)就修改了 20 次习霹，或者是 100 次，那么緩存更新 20 次炫隶、100 次淋叶；但是這個緩存在 1 分鐘內(nèi)只被讀取了 1 次，有大量的冷數(shù)據(jù)伪阶。實際上煞檩，如果你只是刪除緩存的話，那么在 1 分鐘內(nèi)望门，這個緩存不過就重新計算一次而已形娇，開銷大幅度降低。用到緩存才去算緩存筹误。
其實刪除緩存，而不是更新緩存癣缅，就是一個 lazy 計算的思想厨剪，不要每次都重新做復(fù)雜的計算，不管它會不會用到友存，而是讓它到需要被使用的時候再重新計算祷膳。像 mybatis，hibernate屡立，都有懶加載思想直晨。查詢一個部門，部門帶了一個員工的 list膨俐，沒有必要說每次查詢部門勇皇，都把里面的 1000 個員工的數(shù)據(jù)也同時查出來啊。80% 的情況焚刺，查這個部門敛摘，就只是要訪問這個部門的信息就可以了。先查部門乳愉，同時要訪問里面的員工兄淫，那么這個時候只有在你要訪問里面的員工的時候，才會去數(shù)據(jù)庫里面查詢 1000 個員工蔓姚。
最初級的緩存不一致問題及解決方案
問題：先更新數(shù)據(jù)庫捕虽，再刪除緩存。如果刪除緩存失敗了坡脐，那么會導(dǎo)致數(shù)據(jù)庫中是新數(shù)據(jù)泄私，緩存中是舊數(shù)據(jù)，數(shù)據(jù)就出現(xiàn)了不一致。
解決思路：先刪除緩存挖滤，再更新數(shù)據(jù)庫崩溪。如果數(shù)據(jù)庫更新失敗了，那么數(shù)據(jù)庫中是舊數(shù)據(jù)斩松，緩存中是空的伶唯，那么數(shù)據(jù)不會不一致。因為讀的時候緩存沒有惧盹，所以去讀了數(shù)據(jù)庫中的舊數(shù)據(jù)乳幸，然后更新到緩存中。
比較復(fù)雜的數(shù)據(jù)不一致問題分析
數(shù)據(jù)發(fā)生了變更钧椰，先刪除了緩存粹断，然后要去修改數(shù)據(jù)庫，此時還沒修改嫡霞。一個請求過來瓶埋，去讀緩存，發(fā)現(xiàn)緩存空了诊沪，去查詢數(shù)據(jù)庫养筒，查到了修改前的舊數(shù)據(jù)，放到了緩存中端姚。隨后數(shù)據(jù)變更的程序完成了數(shù)據(jù)庫的修改晕粪。完了，數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一樣了...
為什么上億流量高并發(fā)場景下渐裸，緩存會出現(xiàn)這個問題巫湘？
只有在對一個數(shù)據(jù)在并發(fā)的進(jìn)行讀寫的時候，才可能會出現(xiàn)這種問題昏鹃。其實如果說你的并發(fā)量很低的話尚氛，特別是讀并發(fā)很低，每天訪問量就 1 萬次盆顾，那么很少的情況下怠褐，會出現(xiàn)剛才描述的那種不一致的場景。但是問題是您宪，如果每天的是上億的流量奈懒，每秒并發(fā)讀是幾萬，每秒只要有數(shù)據(jù)更新的請求宪巨，就可能會出現(xiàn)上述的數(shù)據(jù)庫+緩存不一致的情況磷杏。
解決方案如下：
更新數(shù)據(jù)的時候，根據(jù)數(shù)據(jù)的唯一標(biāo)識捏卓，將操作路由之后极祸，發(fā)送到一個 jvm 內(nèi)部隊列中慈格。讀取數(shù)據(jù)的時候，如果發(fā)現(xiàn)數(shù)據(jù)不在緩存中遥金，那么將重新執(zhí)行“讀取數(shù)據(jù)+更新緩存”的操作浴捆，根據(jù)唯一標(biāo)識路由之后，也發(fā)送到同一個 jvm 內(nèi)部隊列中稿械。
一個隊列對應(yīng)一個工作線程选泻，每個工作線程串行拿到對應(yīng)的操作，然后一條一條的執(zhí)行美莫。這樣的話页眯，一個數(shù)據(jù)變更的操作，先刪除緩存厢呵，然后再去更新數(shù)據(jù)庫窝撵，但是還沒完成更新。此時如果一個讀請求過來襟铭，沒有讀到緩存碌奉，那么可以先將緩存更新的請求發(fā)送到隊列中，此時會在隊列中積壓寒砖，然后同步等待緩存更新完成道批。
這里有一個優(yōu)化點，一個隊列中入撒，其實多個更新緩存請求串在一起是沒意義的，因此可以做過濾椭岩，如果發(fā)現(xiàn)隊列中已經(jīng)有一個更新緩存的請求了茅逮，那么就不用再放個更新請求操作進(jìn)去了，直接等待前面的更新操作請求完成即可判哥。
待那個隊列對應(yīng)的工作線程完成了上一個操作的數(shù)據(jù)庫的修改之后献雅，才會去執(zhí)行下一個操作，也就是緩存更新的操作塌计，此時會從數(shù)據(jù)庫中讀取最新的值挺身，然后寫入緩存中。
如果請求還在等待時間范圍內(nèi)锌仅，不斷輪詢發(fā)現(xiàn)可以取到值了章钾，那么就直接返回；如果請求等待的時間超過一定時長热芹，那么這一次直接從數(shù)據(jù)庫中讀取當(dāng)前的舊值贱傀。
高并發(fā)的場景下，該解決方案要注意的問題：
- 讀請求長時阻塞
由于讀請求進(jìn)行了非常輕度的異步化伊脓，所以一定要注意讀超時的問題府寒，每個讀請求必須在超時時間范圍內(nèi)返回。
該解決方案，最大的風(fēng)險點在于說株搔，可能數(shù)據(jù)更新很頻繁剖淀，導(dǎo)致隊列中積壓了大量更新操作在里面，然后讀請求會發(fā)生大量的超時纤房，最后導(dǎo)致大量的請求直接走數(shù)據(jù)庫纵隔。務(wù)必通過一些模擬真實的測試，看看更新數(shù)據(jù)的頻率是怎樣的帆卓。
另外一點巨朦，因為一個隊列中，可能會積壓針對多個數(shù)據(jù)項的更新操作剑令，因此需要根據(jù)自己的業(yè)務(wù)情況進(jìn)行測試糊啡，可能需要部署多個服務(wù)，每個服務(wù)分?jǐn)傄恍?shù)據(jù)的更新操作吁津。如果一個內(nèi)存隊列里居然會擠壓 100 個商品的庫存修改操作棚蓄，每個庫存修改操作要耗費 10ms 去完成，那么最后一個商品的讀請求碍脏，可能等待 10 * 100 = 1000ms = 1s 后梭依，才能得到數(shù)據(jù)耻陕，這個時候就導(dǎo)致讀請求的長時阻塞扩灯。
一定要做根據(jù)實際業(yè)務(wù)系統(tǒng)的運行情況淹魄，去進(jìn)行一些壓力測試筑公，和模擬線上環(huán)境忘古，去看看最繁忙的時候球涛，內(nèi)存隊列可能會擠壓多少更新操作珍促，可能會導(dǎo)致最后一個更新操作對應(yīng)的讀請求锨匆，會 hang 多少時間褥紫，如果讀請求在 200ms 返回姜性，如果你計算過后，哪怕是最繁忙的時候髓考，積壓 10 個更新操作部念，最多等待 200ms，那還可以的氨菇。
如果一個內(nèi)存隊列中可能積壓的更新操作特別多儡炼，那么你就要加機器，讓每個機器上部署的服務(wù)實例處理更少的數(shù)據(jù)门驾，那么每個內(nèi)存隊列中積壓的更新操作就會越少射赛。
其實根據(jù)之前的項目經(jīng)驗，一般來說奶是，數(shù)據(jù)的寫頻率是很低的楣责，因此實際上正常來說竣灌，在隊列中積壓的更新操作應(yīng)該是很少的。像這種針對讀高并發(fā)秆麸、讀緩存架構(gòu)的項目初嘹，一般來說寫請求是非常少的，每秒的 QPS 能到幾百就不錯了沮趣。
我們來實際粗略測算一下屯烦。
如果一秒有 500 的寫操作，如果分成 5 個時間片房铭，每 200ms 就 100 個寫操作驻龟，放到 20 個內(nèi)存隊列中，每個內(nèi)存隊列缸匪，可能就積壓 5 個寫操作翁狐。每個寫操作性能測試后，一般是在 20ms 左右就完成凌蔬，那么針對每個內(nèi)存隊列的數(shù)據(jù)的讀請求露懒，也就最多 hang 一會兒，200ms 以內(nèi)肯定能返回了砂心。
經(jīng)過剛才簡單的測算懈词，我們知道，單機支撐的寫 QPS 在幾百是沒問題的辩诞，如果寫 QPS 擴大了 10 倍坎弯，那么就擴容機器，擴容 10 倍的機器译暂，每個機器 20 個隊列荞怒。
- 讀請求并發(fā)量過高
這里還必須做好壓力測試，確保恰巧碰上上述情況的時候秧秉，還有一個風(fēng)險，就是突然間大量讀請求會在幾十毫秒的延時 hang 在服務(wù)上衰抑，看服務(wù)能不能扛的住象迎，需要多少機器才能扛住最大的極限情況的峰值。
但是因為并不是所有的數(shù)據(jù)都在同一時間更新呛踊，緩存也不會同一時間失效砾淌，所以每次可能也就是少數(shù)數(shù)據(jù)的緩存失效了，然后那些數(shù)據(jù)對應(yīng)的讀請求過來谭网，并發(fā)量應(yīng)該也不會特別大汪厨。
- 多服務(wù)實例部署的請求路由
可能這個服務(wù)部署了多個實例，那么必須保證說愉择，執(zhí)行數(shù)據(jù)更新操作劫乱，以及執(zhí)行緩存更新操作的請求织中，都通過 Nginx 服務(wù)器路由到相同的服務(wù)實例上。
比如說衷戈，對同一個商品的讀寫請求狭吼，全部路由到同一臺機器上≈掣荆可以自己去做服務(wù)間的按照某個請求參數(shù)的 hash 路由刁笙，也可以用 Nginx 的 hash 路由功能等等。
- 熱點商品的路由問題谦趣，導(dǎo)致請求的傾斜
萬一某個商品的讀寫請求特別高疲吸，全部打到相同的機器的相同的隊列里面去了，可能會造成某臺機器的壓力過大前鹅。就是說摘悴，因為只有在商品數(shù)據(jù)更新的時候才會清空緩存，然后才會導(dǎo)致讀寫并發(fā)嫡纠，所以其實要根據(jù)業(yè)務(wù)系統(tǒng)去看烦租，如果更新頻率不是太高的話，這個問題的影響并不是特別大除盏，但是的確可能某些機器的負(fù)載會高一些叉橱。
關(guān)注我的微信公眾號，第一時間獲得我的博客的更新提醒,更有驚喜等著你喲~
掃一掃下方二維碼或搜索微信號shenshan_laoyuan關(guān)注
深山老猿
本篇文章由一文多發(fā)平臺ArtiPub自動發(fā)布
