緩存三連問：項(xiàng)目中如何使用、為什么要使用、使用不當(dāng)會(huì)造成什么后果？
點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號(hào)”
優(yōu)質(zhì)文章，第一時(shí)間送達(dá)
問題
項(xiàng)目中緩存是如何使用的？為什么要用緩存？緩存使用不當(dāng)會(huì)造成什么后果？
分析
這個(gè)問題，互聯(lián)網(wǎng)公司必問，要是一個(gè)人連緩存都不太清楚，那確實(shí)比較尷尬。
只要問到緩存，上來(lái)第一個(gè)問題，肯定是先問問你項(xiàng)目哪里用了緩存？為啥要用？不用行不行？如果用了以后可能會(huì)有什么不良的后果？
這就是看看你對(duì)緩存這個(gè)東西背后有沒有思考，如果你就是傻乎乎的瞎用，沒法給面試官一個(gè)合理的解答，那面試官對(duì)你印象肯定不太好，覺得你平時(shí)思考太少，就知道干活兒。
面試題剖析
項(xiàng)目中緩存是如何使用的？
這個(gè)，需要結(jié)合自己項(xiàng)目的業(yè)務(wù)來(lái)。
為什么要用緩存？
用緩存，主要有兩個(gè)用途：高性能、高并發(fā)。
高性能
假設(shè)這么個(gè)場(chǎng)景，你有個(gè)操作，一個(gè)請(qǐng)求過來(lái)，吭哧吭哧你各種亂七八糟操作 mysql，半天查出來(lái)一個(gè)結(jié)果，耗時(shí) 600ms。但是這個(gè)結(jié)果可能接下來(lái)幾個(gè)小時(shí)都不會(huì)變了，或者變了也可以不用立即反饋給用戶。那么此時(shí)咋辦？
緩存啊，折騰 600ms 查出來(lái)的結(jié)果，扔緩存里，一個(gè) key 對(duì)應(yīng)一個(gè) value，下次再有人查，別走 mysql 折騰 600ms 了，直接從緩存里，通過一個(gè) key 查出來(lái)一個(gè) value，2ms 搞定。性能提升 300 倍。
就是說對(duì)于一些需要復(fù)雜操作耗時(shí)查出來(lái)的結(jié)果，且確定后面不怎么變化，但是有很多讀請(qǐng)求，那么直接將查詢出來(lái)的結(jié)果放在緩存中，后面直接讀緩存就好。
高并發(fā)
mysql 這么重的數(shù)據(jù)庫(kù)，壓根兒設(shè)計(jì)不是讓你玩兒高并發(fā)的，雖然也可以玩兒，但是天然支持不好。mysql 單機(jī)支撐到 2000QPS 也開始容易報(bào)警了。
所以要是你有個(gè)系統(tǒng)，高峰期一秒鐘過來(lái)的請(qǐng)求有 1萬(wàn)，那一個(gè) mysql 單機(jī)絕對(duì)會(huì)死掉。你這個(gè)時(shí)候就只能上緩存，把很多數(shù)據(jù)放緩存，別放 mysql。緩存功能簡(jiǎn)單，說白了就是 key-value 式操作，單機(jī)支撐的并發(fā)量輕松一秒幾萬(wàn)十幾萬(wàn)，支撐高并發(fā) so easy。單機(jī)承載并發(fā)量是 mysql 單機(jī)的幾十倍。
緩存是走內(nèi)存的，內(nèi)存天然就支撐高并發(fā)。
用了緩存之后會(huì)有什么不良后果？
常見的緩存問題有以下幾個(gè)：
緩存與數(shù)據(jù)庫(kù)雙寫不一致 緩存雪崩、緩存穿透 緩存并發(fā)競(jìng)爭(zhēng)
問題1：如何保證緩存與數(shù)據(jù)庫(kù)的雙寫一致性？
分析
你只要用緩存，就可能會(huì)涉及到緩存與數(shù)據(jù)庫(kù)雙存儲(chǔ)雙寫，你只要是雙寫，就一定會(huì)有數(shù)據(jù)一致性的問題，那么你如何解決一致性問題？
面試題剖析
一般來(lái)說，如果允許緩存可以稍微的跟數(shù)據(jù)庫(kù)偶爾有不一致的情況，也就是說如果你的系統(tǒng)不是嚴(yán)格要求 “緩存+數(shù)據(jù)庫(kù)” 必須保持一致性的話，最好不要做這個(gè)方案，即：讀請(qǐng)求和寫請(qǐng)求串行化，串到一個(gè)內(nèi)存隊(duì)列里去。
串行化可以保證一定不會(huì)出現(xiàn)不一致的情況，但是它也會(huì)導(dǎo)致系統(tǒng)的吞吐量大幅度降低，用比正常情況下多幾倍的機(jī)器去支撐線上的一個(gè)請(qǐng)求。
Cache Aside Pattern
最經(jīng)典的緩存+數(shù)據(jù)庫(kù)讀寫的模式，就是 Cache Aside Pattern。
讀的時(shí)候，先讀緩存，緩存沒有的話，就讀數(shù)據(jù)庫(kù)，然后取出數(shù)據(jù)后放入緩存，同時(shí)返回響應(yīng)。 更新的時(shí)候，先更新數(shù)據(jù)庫(kù)，然后再刪除緩存。
為什么是刪除緩存，而不是更新緩存？
原因很簡(jiǎn)單，很多時(shí)候，在復(fù)雜點(diǎn)的緩存場(chǎng)景，緩存不單單是數(shù)據(jù)庫(kù)中直接取出來(lái)的值。
比如可能更新了某個(gè)表的一個(gè)字段，然后其對(duì)應(yīng)的緩存，是需要查詢另外兩個(gè)表的數(shù)據(jù)并進(jìn)行運(yùn)算，才能計(jì)算出緩存最新的值的。
另外更新緩存的代價(jià)有時(shí)候是很高的。是不是說，每次修改數(shù)據(jù)庫(kù)的時(shí)候，都一定要將其對(duì)應(yīng)的緩存更新一份？也許有的場(chǎng)景是這樣，但是對(duì)于比較復(fù)雜的緩存數(shù)據(jù)計(jì)算的場(chǎng)景，就不是這樣了。如果你頻繁修改一個(gè)緩存涉及的多個(gè)表，緩存也頻繁更新。但是問題在于，這個(gè)緩存到底會(huì)不會(huì)被頻繁訪問到？
舉個(gè)栗子，一個(gè)緩存涉及的表的字段，在 1 分鐘內(nèi)就修改了 20 次，或者是 100 次，那么緩存更新 20 次、100 次；但是這個(gè)緩存在 1 分鐘內(nèi)只被讀取了 1 次，有大量的冷數(shù)據(jù)。實(shí)際上，如果你只是刪除緩存的話，那么在 1 分鐘內(nèi)，這個(gè)緩存不過就重新計(jì)算一次而已，開銷大幅度降低。用到緩存才去算緩存。
其實(shí)刪除緩存，而不是更新緩存，就是一個(gè) lazy 計(jì)算的思想，不要每次都重新做復(fù)雜的計(jì)算，不管它會(huì)不會(huì)用到，而是讓它到需要被使用的時(shí)候再重新計(jì)算。像 mybatis，hibernate，都有懶加載思想。查詢一個(gè)部門，部門帶了一個(gè)員工的 list，沒有必要說每次查詢部門，都里面的 1000 個(gè)員工的數(shù)據(jù)也同時(shí)查出來(lái)啊。80% 的情況，查這個(gè)部門，就只是要訪問這個(gè)部門的信息就可以了。先查部門，同時(shí)要訪問里面的員工，那么這個(gè)時(shí)候只有在你要訪問里面的員工的時(shí)候，才會(huì)去數(shù)據(jù)庫(kù)里面查詢 1000 個(gè)員工。
最初級(jí)的緩存不一致問題及解決方案
問題：先更新數(shù)據(jù)庫(kù)，再刪除緩存。如果刪除緩存失敗了，那么會(huì)導(dǎo)致數(shù)據(jù)庫(kù)中是新數(shù)據(jù)，緩存中是舊數(shù)據(jù)，數(shù)據(jù)就出現(xiàn)了不一致。
解決思路：先刪除緩存，再更新數(shù)據(jù)庫(kù)。如果數(shù)據(jù)庫(kù)更新失敗了，那么數(shù)據(jù)庫(kù)中是舊數(shù)據(jù)，緩存中是空的，那么數(shù)據(jù)不會(huì)不一致。因?yàn)樽x的時(shí)候緩存沒有，所以去讀了數(shù)據(jù)庫(kù)中的舊數(shù)據(jù)，然后更新到緩存中。
比較復(fù)雜的數(shù)據(jù)不一致問題分析
數(shù)據(jù)發(fā)生了變更，先刪除了緩存，然后要去修改數(shù)據(jù)庫(kù)，此時(shí)還沒修改。一個(gè)請(qǐng)求過來(lái)，去讀緩存，發(fā)現(xiàn)緩存空了，去查詢數(shù)據(jù)庫(kù)，查到了修改前的舊數(shù)據(jù)，放到了緩存中。隨后數(shù)據(jù)變更的程序完成了數(shù)據(jù)庫(kù)的修改。完了，數(shù)據(jù)庫(kù)和緩存中的數(shù)據(jù)不一樣了...
為什么上億流量高并發(fā)場(chǎng)景下，緩存會(huì)出現(xiàn)這個(gè)問題？
只有在對(duì)一個(gè)數(shù)據(jù)在并發(fā)的進(jìn)行讀寫的時(shí)候，才可能會(huì)出現(xiàn)這種問題。其實(shí)如果說你的并發(fā)量很低的話，特別是讀并發(fā)很低，每天訪問量就 1 萬(wàn)次，那么很少的情況下，會(huì)出現(xiàn)剛才描述的那種不一致的場(chǎng)景。但是問題是，如果每天的是上億的流量，每秒并發(fā)讀是幾萬(wàn)，每秒只要有數(shù)據(jù)更新的請(qǐng)求，就可能會(huì)出現(xiàn)上述的數(shù)據(jù)庫(kù)+緩存不一致的情況。
解決方案如下：
更新數(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ì)列對(duì)應(yīng)一個(gè)工作線程，每個(gè)工作線程串行拿到對(duì)應(yīng)的操作，然后一條一條的執(zhí)行。這樣的話，一個(gè)數(shù)據(jù)變更的操作，先刪除緩存，然后再去更新數(shù)據(jù)庫(kù)，但是還沒完成更新。此時(shí)如果一個(gè)讀請(qǐng)求過來(lái)，沒有讀到緩存，那么可以先將緩存更新的請(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ù)庫(kù)的修改之后，才會(huì)去執(zhí)行下一個(gè)操作，也就是緩存更新的操作，此時(shí)會(huì)從數(shù)據(jù)庫(kù)中讀取最新的值，然后寫入緩存中。
如果請(qǐng)求還在等待時(shí)間范圍內(nèi)，不斷輪詢發(fā)現(xiàn)可以取到值了，那么就直接返回；如果請(qǐng)求等待的時(shí)間超過一定時(shí)長(zhǎng)，那么這一次直接從數(shù)據(jù)庫(kù)中讀取當(dāng)前的舊值。
高并發(fā)的場(chǎng)景下，該解決方案要注意的問題：
讀請(qǐng)求長(zhǎ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ù)庫(kù)。務(wù)必通過一些模擬真實(shí)的測(cè)試，看看更新數(shù)據(jù)的頻率是怎樣的。
另外一點(diǎn)，因?yàn)橐粋€(gè)隊(duì)列中，可能會(huì)積壓針對(duì)多個(gè)數(shù)據(jù)項(xiàng)的更新操作，因此需要根據(jù)自己的業(yè)務(wù)情況進(jìn)行測(cè)試，可能需要部署多個(gè)服務(wù)，每個(gè)服務(wù)分?jǐn)傄恍?shù)據(jù)的更新操作。如果一個(gè)內(nèi)存隊(duì)列里居然會(huì)擠壓 100 個(gè)商品的庫(kù)存修改操作，每隔庫(kù)存修改操作要耗費(fèi) 10ms 去完成，那么最后一個(gè)商品的讀請(qǐng)求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到數(shù)據(jù)，這個(gè)時(shí)候就導(dǎo)致讀請(qǐng)求的長(zhǎng)時(shí)阻塞。
一定要做根據(jù)實(shí)際業(yè)務(wù)系統(tǒng)的運(yùn)行情況，去進(jìn)行一些壓力測(cè)試，和模擬線上環(huán)境，去看看最繁忙的時(shí)候，內(nèi)存隊(duì)列可能會(huì)擠壓多少更新操作，可能會(huì)導(dǎo)致最后一個(gè)更新操作對(duì)應(yīng)的讀請(qǐng)求，會(huì) hang 多少時(shí)間，如果讀請(qǐng)求在 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)，一般來(lái)說，數(shù)據(jù)的寫頻率是很低的，因此實(shí)際上正常來(lái)說，在隊(duì)列中積壓的更新操作應(yīng)該是很少的。像這種針對(duì)讀高并發(fā)、讀緩存架構(gòu)的項(xiàng)目，一般來(lái)說寫請(qǐng)求是非常少的，每秒的 QPS 能到幾百就不錯(cuò)了。
我們來(lái)實(shí)際粗略測(cè)算一下。
如果一秒有 500 的寫操作，如果分成 5 個(gè)時(shí)間片，每 200ms 就 100 個(gè)寫操作，放到 20 個(gè)內(nèi)存隊(duì)列中，每個(gè)內(nèi)存隊(duì)列，可能就積壓 5 個(gè)寫操作。每個(gè)寫操作性能測(cè)試后，一般是在 20ms 左右就完成，那么針對(duì)每個(gè)內(nèi)存隊(duì)列的數(shù)據(jù)的讀請(qǐng)求，也就最多 hang 一會(huì)兒，200ms 以內(nèi)肯定能返回了。
經(jīng)過剛才簡(jiǎn)單的測(cè)算，我們知道，單機(jī)支撐的寫 QPS 在幾百是沒問題的，如果寫 QPS 擴(kuò)大了 10 倍，那么就擴(kuò)容機(jī)器，擴(kuò)容 10 倍的機(jī)器，每個(gè)機(jī)器 20 個(gè)隊(duì)列。
讀請(qǐng)求并發(fā)量過高
這里還必須做好壓力測(cè)試，確保恰巧碰上上述情況的時(shí)候，還有一個(gè)風(fēng)險(xiǎn)，就是突然間大量讀請(qǐng)求會(huì)在幾十毫秒的延時(shí) hang 在服務(wù)上，看服務(wù)能不能扛的住，需要多少機(jī)器才能扛住最大的極限情況的峰值。
但是因?yàn)椴⒉皇撬械臄?shù)據(jù)都在同一時(shí)間更新，緩存也不會(huì)同一時(shí)間失效，所以每次可能也就是少數(shù)數(shù)據(jù)的緩存失效了，然后那些數(shù)據(jù)對(duì)應(yīng)的讀請(qǐng)求過來(lái)，并發(fā)量應(yīng)該也不會(huì)特別大。
多服務(wù)實(shí)例部署的請(qǐng)求路由
可能這個(gè)服務(wù)部署了多個(gè)實(shí)例，那么必須保證說，執(zhí)行數(shù)據(jù)更新操作，以及執(zhí)行緩存更新操作的請(qǐng)求，都通過 Nginx 服務(wù)器路由到相同的服務(wù)實(shí)例上。
比如說，對(duì)同一個(gè)商品的讀寫請(qǐng)求，全部路由到同一臺(tái)機(jī)器上?？梢宰约喝プ龇?wù)間的按照某個(gè)請(qǐng)求參數(shù)的 hash 路由，也可以用 Nginx 的 hash 路由功能等等。
熱點(diǎn)商品的路由問題，導(dǎo)致請(qǐng)求的傾斜
萬(wàn)一某個(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ì)高一些。
問題2：了解什么是 redis 的雪崩、穿透和擊穿？redis 崩潰之后會(huì)怎么樣？系統(tǒng)該如何應(yīng)對(duì)這種情況？如何處理 redis 的穿透？
分析
其實(shí)這是問到緩存必問的，因?yàn)榫彺嫜┍篮痛┩?，是緩存最大的兩個(gè)問題，要么不出現(xiàn)，一旦出現(xiàn)就是致命性的問題，所以面試官一定會(huì)問你。
面試題剖析
緩存雪崩
對(duì)于系統(tǒng) A，假設(shè)每天高峰期每秒 5000 個(gè)請(qǐng)求，本來(lái)緩存在高峰期可以扛住每秒 4000 個(gè)請(qǐng)求，但是緩存機(jī)器意外發(fā)生了全盤宕機(jī)。緩存掛了，此時(shí) 1 秒 5000 個(gè)請(qǐng)求全部落數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)必然扛不住，它會(huì)報(bào)一下警，然后就掛了。此時(shí)，如果沒有采用什么特別的方案來(lái)處理這個(gè)故障，DBA 很著急，重啟數(shù)據(jù)庫(kù)，但是數(shù)據(jù)庫(kù)立馬又被新的流量給打死了。
這就是緩存雪崩。
大約在 3 年前，國(guó)內(nèi)比較知名的一個(gè)互聯(lián)網(wǎng)公司，曾因?yàn)榫彺媸鹿?，?dǎo)致雪崩，后臺(tái)系統(tǒng)全部崩潰，事故從當(dāng)天下午持續(xù)到晚上凌晨 3~4 點(diǎn)，公司損失了幾千萬(wàn)。
緩存雪崩的事前事中事后的解決方案如下。
事前：redis 高可用，主從+哨兵，redis cluster，避免全盤崩潰。 事中：本地 ehcache 緩存 + hystrix 限流&降級(jí)，避免 MySQL 被打死。 事后：redis 持久化，一旦重啟，自動(dòng)從磁盤上加載數(shù)據(jù)，快速恢復(fù)緩存數(shù)據(jù)。
用戶發(fā)送一個(gè)請(qǐng)求，系統(tǒng) A 收到請(qǐng)求后，先查本地 ehcache 緩存，如果沒查到再查 redis。如果 ehcache 和 redis 都沒有，再查數(shù)據(jù)庫(kù)，將數(shù)據(jù)庫(kù)中的結(jié)果，寫入 ehcache 和 redis 中。
限流組件，可以設(shè)置每秒的請(qǐng)求，有多少能通過組件，剩余的未通過的請(qǐng)求，怎么辦？走降級(jí)！可以返回一些默認(rèn)的值，或者友情提示，或者空白的值。
好處：
數(shù)據(jù)庫(kù)絕對(duì)不會(huì)死，限流組件確保了每秒只有多少個(gè)請(qǐng)求能通過。 只要數(shù)據(jù)庫(kù)不死，就是說，對(duì)用戶來(lái)說，2/5 的請(qǐng)求都是可以被處理的。 只要有 2/5 的請(qǐng)求可以被處理，就意味著你的系統(tǒng)沒死，對(duì)用戶來(lái)說，可能就是點(diǎn)擊幾次刷不出來(lái)頁(yè)面，但是多點(diǎn)幾次，就可以刷出來(lái)一次。
緩存穿透
對(duì)于系統(tǒng)A，假設(shè)一秒 5000 個(gè)請(qǐng)求，結(jié)果其中 4000 個(gè)請(qǐng)求是黑客發(fā)出的惡意攻擊。
黑客發(fā)出的那 4000 個(gè)攻擊，緩存中查不到，每次你去數(shù)據(jù)庫(kù)里查，也查不到。
舉個(gè)栗子。數(shù)據(jù)庫(kù) id 是從 1 開始的，結(jié)果黑客發(fā)過來(lái)的請(qǐng)求 id 全部都是負(fù)數(shù)。這樣的話，緩存中不會(huì)有，請(qǐng)求每次都“視緩存于無(wú)物”，直接查詢數(shù)據(jù)庫(kù)。這種惡意攻擊場(chǎng)景的緩存穿透就會(huì)直接把數(shù)據(jù)庫(kù)給打死。
解決方式很簡(jiǎn)單，每次系統(tǒng) A 從數(shù)據(jù)庫(kù)中只要沒查到，就寫一個(gè)空值到緩存里去，比如 set -999 UNKNOWN。然后設(shè)置一個(gè)過期時(shí)間，這樣的話，下次有相同的 key 來(lái)訪問的時(shí)候，在緩存失效之前，都可以直接從緩存中取數(shù)據(jù)。
緩存擊穿
緩存擊穿，就是說某個(gè) key 非常熱點(diǎn)，訪問非常頻繁，處于集中式高并發(fā)訪問的情況，當(dāng)這個(gè) key 在失效的瞬間，大量的請(qǐng)求就擊穿了緩存，直接請(qǐng)求數(shù)據(jù)庫(kù)，就像是在一道屏障上鑿開了一個(gè)洞。
解決方式也很簡(jiǎn)單，可以將熱點(diǎn)數(shù)據(jù)設(shè)置為永遠(yuǎn)不過期；或者基于 redis or zookeeper 實(shí)現(xiàn)互斥鎖，等待第一個(gè)請(qǐng)求構(gòu)建完緩存之后，再釋放鎖，進(jìn)而其它請(qǐng)求才能通過該 key 訪問數(shù)據(jù)。
問題3：redis 的并發(fā)競(jìng)爭(zhēng)問題是什么？如何解決這個(gè)問題？了解 redis 事務(wù)的 CAS 方案嗎？
分析
這個(gè)也是線上非常常見的一個(gè)問題，就是多客戶端同時(shí)并發(fā)寫一個(gè) key，可能本來(lái)應(yīng)該先到的數(shù)據(jù)后到了，導(dǎo)致數(shù)據(jù)版本錯(cuò)了；或者是多客戶端同時(shí)獲取一個(gè) key，修改值之后再寫回去，只要順序錯(cuò)了，數(shù)據(jù)就錯(cuò)了。
而且 redis 自己就有天然解決這個(gè)問題的 CAS 類的樂觀鎖方案。
面試題剖析
某個(gè)時(shí)刻，多個(gè)系統(tǒng)實(shí)例都去更新某個(gè) key。可以基于 zookeeper 實(shí)現(xiàn)分布式鎖。每個(gè)系統(tǒng)通過 zookeeper 獲取分布式鎖，確保同一時(shí)間，只能有一個(gè)系統(tǒng)實(shí)例在操作某個(gè) key，別人都不允許讀和寫。
你要寫入緩存的數(shù)據(jù)，都是從 mysql 里查出來(lái)的，都得寫入 mysql 中，寫入 mysql 中的時(shí)候必須保存一個(gè)時(shí)間戳，從 mysql 查出來(lái)的時(shí)候，時(shí)間戳也查出來(lái)。
每次要寫之前，先判斷一下當(dāng)前這個(gè) value 的時(shí)間戳是否比緩存里的 value 的時(shí)間戳要新。如果是的話，那么可以寫，否則，就不能用舊的數(shù)據(jù)覆蓋新的數(shù)據(jù)。
來(lái)源：https://github.com/doocs/advanced-java
加鋒哥微信:?java1239?? 圍觀鋒哥朋友圈，每天推送Java干貨！