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

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

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

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

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

22、如何保證緩存與數據庫雙寫時的數據一致性

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

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

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

最經典的緩存＋數據庫讀寫的模式，就是 預留緩存模式Cache Aside Pattern。

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

互聯網公司非常喜歡問這道面試題因為緩存在互聯網公司使用非常頻繁

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

23、數據為什么會出現不一致的情況？

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

一、單庫情況下

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

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

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

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

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

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

臟數據是指源系統中的數據不在給定的范圍內或對于實際業(yè)務毫無意義，或是數據格式非法，以及在源系統中存在不規(guī)范的編碼和含糊的業(yè)務邏輯。

二、主從同步，讀寫分離的情況下，讀從庫而產生臟數據

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

A請求寫主數據庫，寫了最新的數據。

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

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

最后數據庫主從同步完成

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

根本原因：

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

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