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

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

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

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

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

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

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

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

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

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

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

互聯(lián)網(wǎng)公司非常喜歡問這道面試題因為緩存在互聯(lián)網(wǎng)公司使用非常頻繁

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

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

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

一、單庫情況下

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

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

B請求發(fā)送一個讀操作，讀cache，因為cache淘汰，所以為空

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

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

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

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

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

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

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

B請求發(fā)送一個讀操作，讀cache，因為cache淘汰，所以為空

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

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

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

根本原因：

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

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