你知道怎么解決DB讀寫分離，導致數據不一致問題嗎？

目錄

1. 前言
2. 為什么產生數據不一致
3. 方案一：利用數據庫自身特性
4. 方案二：不解決
5. 方案三：客戶端保存法
6. 方案四：緩存標記法
7. 方案五：本地緩存標記

前言

在互聯網中大型項目中，讀寫分離應該是我們小伙伴經常聽說的，這個主要解決大流量請求時，提高系統的吞吐量。因為絕大部分互聯網產品都是讀多寫少，大部分都是讀請求，很小部分是寫請求。

上圖：

1.一個主庫負責寫請求，更新數據
2.兩個從庫負責讀請求，可以提高系統吞吐量
3.主庫和從庫之間同步數據

為什么產生數據不一致

上圖中業務流程

1.寫請求A進行數據更新，但寫庫還沒有來得及把更新的數據更新到讀庫
2.讀請求B進行數據查詢，請求B是訪問的讀庫，獲取的是舊值
3.因為寫庫和讀庫之間存在同步延遲，導致數據在不同庫中不一致

這個問題我們如何解決？

方案一：利用數據庫自身特性

我們一般用的數據庫是mysql和oracle，mysql是我們互聯網項目都會用到的，oracle一般大公司用的比較多（很貴啊）。

我們分析一下問題，原因就是在主庫（寫庫）與從庫（讀庫）之間數據同步延遲導致，mysql中有全同步復制機制、半同步復制、異步復制三種復制方案（小伙伴可以自行去了解）。

mysql全同步復制

全同步復制，當A提交更新請求主庫事務之后，不是立即返回，而是等到所有的從庫節點必須收到、APPLY并且提交這些事務，主庫線程才返回請求A結果，才能做后續操作。這樣就解決了數據同步延遲的問題。

問題：但這個同步方案嚴重的問題就是寫請求耗時會很長，而且會隨者從庫數量增加，耗時也會增加。（不推薦）

oracle共享存儲

上圖采用了oracle RAC方案，DB服務其實就代表一個應用服務，所有的數據存儲在同一個地方，所有就不存在數據同步這個問題。當然這個部署方案不是我們嚴格意義上面的讀寫分離，存儲是獨立的。

問題：oracle成本很高，對存儲硬件要求很高。

方案二：不解決

我們設計任何架構方案，都要圍繞著業務，如果業務能夠接受可以不解決；其實很多互聯網產品都有短時間的數據不一致問題。如：58同城，美團，貼吧等。

但有些場景是不允許的。如：

上圖中：

1.用戶寫了一篇文章，點擊保存按鈕
2.系統執行保存方法，提示用戶保存成功
3.保存成功后一般系統就會立即跳轉到文章列表，按照時間倒序，最新的文章排在第一個，這個業務是很正常的，讓用戶可以看到自己的文章列表（我們的頭條號就是這樣的）
4.這樣就是調用獲取文章列表的方法getArticleList，但這個方法是讀請求，走的是從庫。
5.如果出現主庫和從庫同步延遲，就出現了不一致。

這樣用戶就看不到他剛剛提交保存的文章，這個用戶是接受不了的。那我們怎么解決？

方案三：客戶端保存法

這個方案是從一個朋友公司用到的，老顧沒有采用過。一些業務的操作是有前端頁面的，不管是網頁或App等。此方案的思路就是把之前保存的文章緩存到客戶端，在用戶到文章列表時，數據的組成就是（客戶端緩存文章 + 后端讀庫返回的文章數據）。客戶端要做的就是緩存要設置一個時間（這個緩存時間，可以預估主庫同步到從庫的時間延遲）；以及要做文章去重，防止讀庫已經同步完成，客戶端緩存沒有過期。

問題：客戶端邏輯復雜；客戶端有緩存數據大小的限制，不能保存大數據。列表分頁處理復雜。

方案四：緩存標記法

上圖流程：

1.A發起寫請求，更新了主庫，但在緩存中設置一個標記，代表此數據已經更新，標記格式（業務代號：數據庫：表：主鍵ID）根據自己業務場景。
2.設置此標記，要加上過期時間，可以為預估的主庫和從庫同步延遲的時間.
3.B發起讀請求的時候，先判斷此請求的業務在緩存中有沒有更新標記
4.如果存在標記，走主庫；如果沒有走從庫。

這個方案就有效了解決了數據不一致的問題。

但這個方案會有個嚴重的問題，也就是每次的讀請求都要到緩存中去判斷是否存在緩存標記，如果是單機部署用的是jvm緩存，對性能還好；但如果是集群部署緩存肯定用redis，每次讀都要和redis進行交互，這樣肯定會影響系統吞吐量。

那怎么辦？怎么辦？繼續往下看

方案五：本地緩存標記

上圖流程：

1.用戶A發起寫請求，更新了主庫，并在客戶端設置標記，過期時間，如：cookies
2.用戶A再發起讀請求時，帶上這個本地標記在后端
3.后端在處理請求時，獲取請求傳過來的數據，看有沒有這個標記（如：cookies）
4.有這個業務標記，走主庫；沒有走從庫。

這個方案就保證了用戶A的讀請求肯定是數據一致的，而且沒有性能問題，因為標記是本地客戶端傳過去的。

但有寫小伙伴就會問那其他用戶在本地客戶端是沒有這個標記的，他們走的就是從庫了。那其他用戶不就看不到這個數據了嗎？說的對，其他用戶是看不到，但看不到的時間很短，過個1～10秒就能夠看到。

但這個方案解決了當前用戶的數據一致性的問題，如上面舉的例子，寫文章，然后到文章列表，本用戶是能夠看到的。其他用戶暫時看不到是沒有關系的。還是那句話，脫離業務的方案是耍流氓。（推薦）

總結：大家應該按照自己不同的業務場景，選擇不同的方案；方案各有千秋，具體看業務場景