如何保證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文檔中保存的是垃圾數據，但對實際業務并沒有影響。
這套方案可以解決雙寫數據一致性問題，但它同時也帶來了兩個新問題：
用戶修改操作如何保存數據？
如何清理垃圾數據？
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文檔，但還沒來得及寫入數據庫的數據也查出來，這種數據可能會被誤刪。
可以把時間再整體提前一小時，例如：
獲取25小時前到1小時前的數據。
這樣可以解決大部分系統中，因為數據量過多，在一個定時任務的執行周期內，job處理不完的問題。
但如果根據時間縮小范圍之后，數據量還是太大，job還是處理不完該怎么辦？
答：我們可以在job用多線程刪除數據。
當然我們還可以將job的執行時間縮短，根據實際情況而定，比如每隔12小時，查詢創建時間是13小時前到1小時前的數據。
或者每隔6小時，查詢創建時間是7小時前到1小時前的數據。
或者每隔1小時，查詢創建時間是2小時前到1小時前的數據等等。
4.2 隨機刪除
其實刪除垃圾數據還有另外一種思路。
不知道你了解過Redis?刪除數據的策略?嗎？它在處理大批量數據時，為了防止使用過多的CPU資源，用了一種隨機刪除的策略。
我們在這里可以借鑒一下。
有另外一個job，每隔500ms隨機獲取10條數據進行批量處理，當然獲取的數據也是根據時間縮小范圍的。
