| 背景

在做系統優化時，想到了將資料進行分級儲存的思路。因為在系統中會存在一些資料，有些資料的實時性要求不高，比如一些配置資訊。

基本上配置了很久才會變一次。而有一些資料實時性要求非常高，比如訂單和流水的資料。所以這裡根據資料要求實時性不同將資料分為三級。

• 第1級：訂單資料和支付流水資料；這兩塊資料對實時性和精確性要求很高，所以不新增任何快取，讀寫操作將直接操作資料庫。
• 第2級：使用者相關資料；這些資料和使用者相關，具有讀多寫少的特徵，所以我們使用redis進行快取。
• 第3級：支付配置資訊；這些資料和使用者無關，具有資料量小，頻繁讀，幾乎不修改的特徵，所以我們使用本地記憶體進行快取。

但是隻要使用到快取，無論是本地記憶體做快取還是使用 redis 做快取，那麼就會存在資料同步的問題，因為配置資訊快取在記憶體中，

而記憶體時無法感知到資料在資料庫的修改。這樣就會造成資料庫中的資料與快取中資料不一致的問題。

接下來就討論一下關於保證快取和資料庫雙寫時的資料一致性。

| 解決方案

那麼我們這裡列出來所有策略，並且討論他們優劣性。

1. 先更新資料庫，後更新快取
2. 先更新資料庫，後刪除快取
3. 先更新快取，後更新資料庫
4. 先刪除快取，後更新資料庫

| 先更新資料庫，後更新快取

這種場景一般是沒有人使用的，主要原因是在更新快取那一步，為什麼呢？因為有的業務需求快取中存在的值並不是直接從資料庫中查出來的，

有的是需要經過一系列計算來的快取值，那麼這時候後你要更新快取的話其實代價是很高的。如果此時有大量的對資料庫進行寫資料的請求，

但是讀請求並不多，那麼此時如果每次寫請求都更新一下快取，那麼效能損耗是非常大的。

舉個例子比如在資料庫中有一個值為 1 的值，此時我們有 10 個請求對其每次加一的操作，但是這期間並沒有讀操作進來，如果用了先更新資料庫的辦法，

那麼此時就會有十個請求對快取進行更新，會有大量的冷資料產生，如果我們不更新快取而是刪除快取，那麼在有讀請求來的時候那麼就會只更新快取一次。

| 先更新快取，後更新資料庫

|先刪除快取，後更新資料庫

該方案也會出問題，具體出現的原因如下。

先刪除快取，後更新資料庫

此時來了兩個請求，請求 A（更新操作） 和請求 B（查詢操作）。

1. 請求 A 會先刪除 Redis 中的資料，然後去資料庫進行更新操作。
2. 此時請求 B 看到 Redis 中的資料時空的，會去資料庫中查詢該值，補錄到 Redis 中。
3. 但是此時請求 A 並沒有更新成功，或者事務還未提交。

那麼這時候就會產生資料庫和 Redis 資料不一致的問題。如何解決呢？其實最簡單的解決辦法就是延時雙刪的策略。

延時雙刪

但是上述的保證事務提交完以後再進行刪除快取還有一個問題，就是如果你使用的是 Mysql 的讀寫分離的架構的話，那麼其實主從同步之間也會有時間差。

主從同步時間差

此時來了兩個請求，請求 A（更新操作） 和請求 B（查詢操作）。

1. 請求 A 更新操作，刪除了 Redis。
2. 請求主庫進行更新操作，主庫與從庫進行同步資料的操作。
3. 請 B 查詢操作，發現 Redis 中沒有資料。
4. 去從庫中拿去資料。
5. 此時同步資料還未完成，拿到的資料是舊資料。

此時的解決辦法就是如果是對 Redis 進行填充資料的查詢資料庫操作，那麼就強制將其指向主庫進行查詢。

從主庫中拿資料

| 先更新資料庫，後刪除快取

問題：這一種情況也會出現問題，比如更新資料庫成功了，但是在刪除快取的階段出錯了沒有刪除成功，那麼此時再讀取快取的時候每次都是錯誤的資料了。

先更新資料庫，後刪除快取

此時解決方案就是利用訊息佇列進行刪除的補償。具體的業務邏輯用語言描述如下：

1. 請求 A 先對資料庫進行更新操作。
2. 在對 Redis 進行刪除操作的時候發現報錯，刪除失敗。
3. 此時將Redis 的 key 作為訊息體傳送到訊息佇列中。
4. 系統接收到訊息佇列傳送的訊息後再次對 Redis 進行刪除操作。

但是這個方案會有一個缺點就是會對業務程式碼造成大量的侵入，深深的耦合在一起，所以這時會有一個優化的方案，

我們知道對 Mysql 資料庫更新操作後再 binlog 日誌中我們都能夠找到相應的操作，那麼我們可以訂閱 Mysql 資料庫的 binlog 日誌對快取進行操作。

利用訂閱binlog 刪除快取

| 總結

每種方案各有利弊，比如在第二種先刪除快取，後更新資料庫這個方案我們最後討論了要更新 Redis 的時候強制走主庫查詢就能解決問題，

那麼這樣的操作會對業務程式碼進行大量的侵入，但是不需要增加的系統，不需要增加整體的服務的複雜度。

最後一種方案我們最後討論了利用訂閱 binlog 日誌進行搭建獨立系統操作 Redis，這樣的缺點其實就是增加了系統複雜度。

其實每一次的選擇都需要我們對於我們的業務進行評估來選擇，沒有一種技術是對於所有業務都通用的。沒有最好的，只有最適合我們的。