如何保證mongodb和資料庫雙寫資料一致性？

前言

最近在我的技術群裡，有位小夥伴問了大家一個問題：如何保證Mongodb和資料庫雙寫的資料一致性？

群友們針對這個技術點討論的內容，引起了我的興趣。

其實我在實際工作中的有些業務場景，也在使用Mongodb，也遇到過雙寫的資料一致性問題。

今天跟大家一起分享一下，這類問題的解決辦法，希望對你會有所幫助。

1 常見誤區

很多小夥伴看到雙寫資料一致性問題，首先會想到的是Redis和資料庫的資料雙寫一致性問題。

有些小夥伴認為，Redis和資料庫的資料雙寫一致性問題，跟Mongodb和資料庫的資料雙寫一致性問題，是同一個問題。

但如果你仔細想想它們的使用場景，就會發現有一些差異。

1.1 我們是如何用快取的？

Redis快取能提升我們系統的效能。

一般情況下，如果有使用者請求過來，先查快取，如果快取中存在資料，則直接返回。如果快取中不存在，則再查資料庫，如果資料庫中存在，則將資料放入快取，然後返回。如果資料庫中也不存在，則直接返回失敗。

流程圖如下：有了快取之後，能夠減輕資料庫的壓力，提升系統效能。

通常情況下，保證快取和資料雙寫資料一致性，最常用的技術方案是：延遲雙刪。

感興趣的小夥伴，可以看看我的另一篇文章《如何保證資料庫和快取雙寫一致性？》，裡面有非常詳細的介紹。

1.2 我們是如何用MongoDB的？

MongoDB是一個高可用、分散式的文件資料庫，用於大容量資料儲存。文件儲存一般用類似json的格式儲存，儲存的內容是文件型的。

通常情況下，我們用來儲存大資料或者json格式的資料。

使用者寫資料的請求，核心資料會被寫入資料庫，json格式的非核心資料，可能會寫入MongoDB。

流程圖如下：此外，在資料庫的表中，儲存了MongoDB相關文件的id。

使用者讀資料的請求，會先讀資料庫中的資料，然後透過文件的id，讀取MongoDB中的資料。

流程圖如下：這樣可以保證核心屬性不會丟失，同時儲存使用者傳入的較大的資料，兩全其美。

Redis和MongoDB在我們實際工作中的用途不一樣，導致了它們雙寫資料一致性問題的解決方案是不一樣的。

接下來我們一起看看，如何保證MongoDB和資料庫的雙寫的資料一致性？

2 如何保證雙寫一致性？

目前雙寫MongoDB和資料庫的資料，用的最多的就是下面這兩種方案。

2.1 先寫資料庫，再寫MongoDB

該方案最簡單，先在資料庫中寫入核心資料，再在MongoDB中寫入非核心資料。

流程圖如下：如果有些業務場景，對資料的完整性要求不高，即非核心資料可有可無，使用該方案也是可以的。

但如果有些業務場景，對資料完整性要求比較高，用這套方案可能會有問題。

當資料庫剛儲存了核心資料，此時網路出現異常，程式儲存MongoDB的非核心資料時失敗了。

但MongoDB並沒有丟擲異常，資料庫中已經儲存的資料沒法回滾，這樣會出現資料庫中儲存了資料，而MongoDB中沒儲存資料的情況，從而導致MongoDB中的非核心資料丟失的問題。

所以這套方案，在實際工作中使用不多。

2.2 先寫MongoDB，再寫資料庫

在該方案中，先在MongoDB中寫入非核心資料，再在資料庫中寫入核心資料。

流程圖如下：關鍵問題來了：如果MongoDB中非核心資料寫入成功了，但資料庫中的核心資料寫入失敗了怎麼辦？

這時候MongoDB中非核心資料不會回滾，可能存在MongoDB中儲存了資料，而資料庫中沒儲存資料的問題，同樣會出現資料不一致的問題。

答：我們忘了一個前提，查詢MongoDB文件中的資料，必須透過資料庫的表中儲存的mongo id。但如果這個mongo id在資料庫中都沒有儲存成功，那麼，在MongoDB文件中的資料是永遠都查詢不到的。

也就是說，這種情況下MongoDB文件中儲存的是垃圾資料，但對實際業務並沒有影響。

這套方案可以解決雙寫資料一致性問題，但它同時也帶來了兩個新問題：

1. 使用者修改操作如何儲存資料？
2. 如何清理垃圾資料？

3 使用者修改操作如何儲存資料？

我之前聊的先寫MongoDB，再寫資料庫，這套方案中的流程圖，其實主要說的是新增資料的場景。

但如果在使用者修改資料的操作中，使用者先修改MongoDB文件中的資料，再修改資料庫表中的資料。

流程圖如下：如果出現MongoDB文件中的資料修改成功了，但資料庫表中的資料修改失敗了，不也出現問題了？

那麼，使用者修改操作時如何儲存資料呢？

這就需要把流程調整一下，在修改MongoDB文件時，還是新增一條資料，不直接修改，生成一個新的mongo id。然後在修改資料庫表中的資料時，同時更新mongo id欄位為這個新值。

流程圖如下：這樣如果新增MongoDB文件中的資料成功了，但修改資料庫表中的資料失敗了，也沒有關係，因為資料庫中老的資料，儲存的是老的mongo id。透過該id，依然能從MongoDB文件中查詢出資料。

使用該方案能夠解決修改資料時，資料一致性問題，但同樣會存在垃圾資料。

其實這個垃圾資料是可以即使刪除的，具體流程圖如下：在之前的流程中，修改完資料庫，更新了mongo id為新值，接下來，就把MongoDB文件中的那條老資料直接刪了。

該方案可以解決使用者修改操作中，99%的的垃圾資料，但還有那1%的情況，即如果最後刪除失敗該怎麼辦？

答：這就需要加重試機制了。

我們可以使用job或者mq進行重試，優先推薦使用mq增加重試功能。特別是想RocketMQ，自帶了失敗重試機制，有專門的重試佇列，我們可以設定重試次數。

流程圖最佳化如下：將之前刪除MongoDB文件中的資料操作，改成傳送mq訊息，有個專門的mq消費者，負責刪除資料工作，可以做成共用的功能。它包含了失敗重試機制，如果刪除5次還是失敗，則會把該訊息儲存到死信佇列中。

然後專門有個程式監控死信佇列中的資料，如果發現有資料，則發報警郵件。

這樣基本可以解決修改刪除垃圾資料失敗的問題。

4 如何清理新增的垃圾資料？

還有一種垃圾資料還沒處理，即在使用者新增資料時，如果寫入MongoDB文件成功了，但寫入資料庫表失敗了。由於MongoDB不會回滾資料，這時候MongoDB文件就儲存了垃圾資料，那麼這種資料該如何清理呢？

4.1 定時刪除

我們可以使用job定時掃描，比如：每天掃描一次MongoDB文件，將mongo id取出來，到資料庫查詢資料，如果能查出資料，則保留MongoDB文件中的資料。

如果在資料庫中該mongo id不存在，則刪除MongoDB文件中的資料。

如果MongoDB文件中的資料量不多，是可以這樣處理的。但如果資料量太大，這樣處理會有效能問題。

這就需要做最佳化，常見的做法是：縮小掃描資料的範圍。

比如：掃描MongoDB文件資料時，根據建立時間，只查最近24小時的資料，查出來之後，用mongo id去資料庫查詢資料。

如果直接查最近24小時的資料，會有問題，會把剛寫入MongoDB文件，但還沒來得及寫入資料庫的資料也查出來，這種資料可能會被誤刪。

可以把時間再整體提前一小時，例如：

in_time < 當前時間-1 and in_time >= 當前時間-25

獲取25小時前到1小時前的資料。

這樣可以解決大部分系統中，因為資料量過多，在一個定時任務的執行週期內，job處理不完的問題。

但如果根據時間縮小範圍之後，資料量還是太大，job還是處理不完該怎麼辦？

答：我們可以在job用多執行緒刪除資料。

當然我們還可以將job的執行時間縮短，根據實際情況而定，比如每隔12小時，查詢建立時間是13小時前到1小時前的資料。

或者每隔6小時，查詢建立時間是7小時前到1小時前的資料。

或者每隔1小時，查詢建立時間是2小時前到1小時前的資料等等。

4.2 隨機刪除

其實刪除垃圾資料還有另外一種思路。

不知道你瞭解過Redis刪除資料的策略嗎？它在處理大批次資料時，為了防止使用過多的CPU資源，用了一種隨機刪除的策略。

我們在這裡可以借鑑一下。

有另外一個job，每隔500ms隨機獲取10條資料進行批次處理，當然獲取的資料也是根據時間縮小範圍的。