21、如何解決Redis的并發(fā)競爭Key問題

所謂 Redis 的并發(fā)競爭 Key 的問題也就是多個(gè)系統(tǒng)同時(shí)對一個(gè) key 進(jìn)行操作，但是最后執(zhí)行的順序和我們期望的順序不同，這樣也就導(dǎo)致了結(jié)果的不同！

推薦一種方案：分布式鎖（zookeeper 和 Redis 都可以實(shí)現(xiàn)分布式鎖）。（如果不存在 Redis 的并發(fā)競爭 Key 問 題，不要使用分布式鎖，這樣會影響性能）

基于zookeeper臨時(shí)有序節(jié)點(diǎn)可以實(shí)現(xiàn)的分布式鎖。大致思想為：每個(gè)客戶端對某個(gè)方法加鎖時(shí)，在zookeeper上的 與該方法對應(yīng)的指定節(jié)點(diǎn)的目錄下，生成一個(gè)唯一的瞬時(shí)有序節(jié)點(diǎn)。判斷是否獲取鎖的方式很簡單，只需要判斷有 序節(jié)點(diǎn)中序號最小的一個(gè)。當(dāng)釋放鎖的時(shí)候，只需將這個(gè)瞬時(shí)節(jié)點(diǎn)刪除即可。同時(shí)，其可以避免服務(wù)宕機(jī)導(dǎo)致的鎖 無法釋放，而產(chǎn)生的死鎖問題。完成業(yè)務(wù)流程后，刪除對應(yīng)的子節(jié)點(diǎn)釋放鎖。

在實(shí)踐中，當(dāng)然是從以可靠性為主。所以首推Zookeeper。

22、如何保證緩存與數(shù)據(jù)庫雙寫時(shí)的數(shù)據(jù)一致性

首先說一句，你只要用緩存，就可能會涉及到緩存與數(shù)據(jù)庫雙存儲雙寫，你只要是雙寫，就一定會有數(shù)據(jù)一致性的問題，那么你如 何解決一致性問題？

一般來說，就是如果你的系統(tǒng)不是嚴(yán)格要求緩存＋數(shù)據(jù)庫必須一致性的話，緩存可以稍微的跟數(shù)據(jù)庫偶爾有不一致的 情況，最好不要做這個(gè)方案，最好將讀請求和寫請求串行化，串到一個(gè)內(nèi)存隊(duì)列里去，這樣就可以保證一定不會出現(xiàn)不一致的情況。

串行化之后，就會導(dǎo)致系統(tǒng)的吞吐量會大幅度的降低，用比正常情況下多幾倍的機(jī)器去支撐線上的一個(gè)請求。

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

讀的時(shí)候，先讀緩存，緩存沒有的話，就讀數(shù)據(jù)庫，然后取出數(shù)據(jù)后放入緩存，同時(shí)返回響應(yīng)。更新的時(shí)候，先刪除緩存，然后再更新數(shù)據(jù)庫，這樣讀的時(shí)候就會發(fā)現(xiàn)緩存中沒有數(shù)據(jù)而直接去數(shù)據(jù)庫中拿數(shù)據(jù)了。（因?yàn)橐獎(jiǎng)h除，狗日的編輯器可能會背著你做一些優(yōu)化，要徹底將緩存中的數(shù)據(jù)進(jìn)行刪除才行）

互聯(lián)網(wǎng)公司非常喜歡問這道面試題因?yàn)榫彺嬖诨ヂ?lián)網(wǎng)公司使用非常頻繁

在高并發(fā)的業(yè)務(wù)場景下，數(shù)據(jù)庫的性能瓶頸往往都是用戶并發(fā)訪問過大。所以，一般都使用Redis做一個(gè)緩沖操作，讓請求先訪問到Redis，而不是直接去訪問MySQL等數(shù)據(jù)庫，從而減少網(wǎng)絡(luò)請求的延遲響應(yīng)。

23、數(shù)據(jù)為什么會出現(xiàn)不一致的情況？

這樣的問題主要是在并發(fā)讀寫訪問的時(shí)候，緩存和數(shù)據(jù)相互交叉執(zhí)行。

一、單庫情況下

同一時(shí)刻發(fā)生了并發(fā)讀寫請求，例如為A（寫） B （讀）2個(gè)請求

A請求發(fā)送一個(gè)寫操作到服務(wù)端，第一步會淘汰cache，然后因?yàn)楦鞣N原因卡主了，不在執(zhí)行后面業(yè)務(wù)（例：大量的業(yè)務(wù)操作、調(diào)用其他服務(wù)處理消耗了1s）。

B請求發(fā)送一個(gè)讀操作，讀cache，因?yàn)閏ache淘汰，所以為空

B請求繼續(xù)讀DB，讀出一個(gè)臟數(shù)據(jù)，并寫入cache

A請求終于執(zhí)行完全，在寫入數(shù)據(jù)到DB

總結(jié)：因最后才把寫操作數(shù)據(jù)入DB，并沒同步。cache里面一直保持臟數(shù)據(jù)

臟數(shù)據(jù)是指源系統(tǒng)中的數(shù)據(jù)不在給定的范圍內(nèi)或?qū)τ趯?shí)際業(yè)務(wù)毫無意義，或是數(shù)據(jù)格式非法，以及在源系統(tǒng)中存在不規(guī)范的編碼和含糊的業(yè)務(wù)邏輯。

二、主從同步，讀寫分離的情況下，讀從庫而產(chǎn)生臟數(shù)據(jù)

A請求發(fā)送一個(gè)寫操作到服務(wù)端，第一步會淘汰cache

A請求寫主數(shù)據(jù)庫，寫了最新的數(shù)據(jù)。

B請求發(fā)送一個(gè)讀操作，讀cache，因?yàn)閏ache淘汰，所以為空

B請求繼續(xù)讀DB，讀的是從庫，此時(shí)主從同步還沒同步成功。讀出臟數(shù)據(jù)，然后臟數(shù)據(jù)入cache

最后數(shù)據(jù)庫主從同步完成

總結(jié)：這種情況下請求A和請求B操作時(shí)序沒問題，是主從同步的時(shí)延問題（假設(shè)1s），導(dǎo)致讀請求讀取從庫讀到臟數(shù)據(jù)導(dǎo)致的數(shù)據(jù)不一致

根本原因：

單庫下，邏輯處理中消耗1s，可能讀到舊數(shù)據(jù)入緩存

主從＋讀寫分離，在1s的主從同步時(shí)延中，到從庫的舊數(shù)據(jù)入緩存