前言：
不管是先寫MySQL數據庫，再刪除Redis緩存；還是先刪除緩存，再寫庫，都有可能出現數據不一致的情況。舉一個例子：
1.如果刪除了緩存Redis，還沒有來得及寫庫MySQL，另一個線程就來讀取，發現緩存爲空，則去數據庫中讀取數據寫入緩存，此時緩存中爲髒數據。
2.如果先寫了庫，在刪除緩存前，寫庫的線程宕機了，沒有刪除掉緩存，則也會出現數據不一致情況。
因爲寫和讀是併發的，沒法保證順序,就會出現緩存和數據庫的數據不一致的問題。
延時雙刪+過期時間
在進行寫庫操作的前後都進行刪緩存的操作
1）先刪除緩存：爲了其他線程讀取數據讀不到，去數據庫取
2）再寫數據庫
3）休眠n毫秒：爲了防止該線程第二次刪除後，而其他線程是在該線程寫數據之前讀取的數據庫內容，導致緩存中的數據是從其他線程寫進來的，這樣就一直是髒數據了。
4）再次刪除緩存
如何確定休眠的毫秒數
需要評估自己的項目的讀數據業務邏輯的耗時。這麼做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的緩存髒數據。
當然這種策略還要考慮redis和數據庫主從同步的耗時。最後的的寫數據的休眠時間：則在讀數據業務邏輯的耗時基礎上，加幾百ms即可。比如：休眠1秒。
弊端
這樣最差的情況就是在超時時間內數據存在不一致（無法避免），而且又增加了寫請求的耗時（延時導致的，可通過開線程進行休眠和第二次刪除，這樣當前請求不會有額外的延時）。
第二次刪除緩存失敗怎麼辦？思路是採用一個重試機制
方案一：直接在上述代碼中的第二次刪除的時候加入重試機制
（1）更新數據庫數據；
（2）緩存因爲種種問題刪除失敗；
（3）將需要刪除的key發送至消息隊列；
（4）自己消費消息，獲得需要刪除的key；
（5）繼續重試刪除操作，直到成功；
缺點：對業務線代碼造成大量的侵入，所以有接下來的“異步更新緩存”的方案
異步更新緩存
1.技術整體思路：
MySQL binlog增量訂閱消費+消息隊列+增量數據更新到redis
（1）更新數據庫數據；
（2）數據庫會將操作信息寫入binlog日誌當中；
（3）訂閱程序提取出所需要的數據以及key；
（4）另起一段非業務代碼，獲得該信息；
（5）嘗試刪除緩存操作，發現刪除失敗；
（6）將這些信息發送至消息隊列；
（7）重新從消息隊列中獲得該數據，重試操作；
2.Redis更新
1）數據操作主要分爲兩大塊：
一個是全量(將全部數據一次寫入到redis)
一個是增量（實時更新）
這裏說的是增量,指的是mysql的update、insert、delate變更數據。
2）讀取binlog後分析 ，利用消息隊列,推送更新各臺的redis緩存數據。
這樣一旦MySQL中產生了新的寫入、更新、刪除等操作，就可以把binlog相關的消息推送至Redis，Redis再根據binlog中的記錄，對Redis進行更新。
其實這種機制，很類似MySQL的主從備份機制，因爲MySQL的主備也是通過binlog來實現的數據一致性。
這裏可以結合使用canal(阿里的一款開源框架)，通過該框架可以對MySQL的binlog進行訂閱，而canal正是模仿了mysql的slave數據庫的備份請求，使得Redis的數據更新達到了相同的效果。
當然，這裏的消息推送工具你也可以採用別的第三方：kafka、rabbitMQ等來實現推送更新Redis。