業務背景
在大型網站中，為了減少DB壓力、讓數據更精准、速度更快，將讀拆分出來采用搜索引擎來為DB分擔讀的壓力，ElasticSearch就是目前市面上比較流行的搜索引擎，他的檢索速度奇快、支持各種復雜的全文檢索，在各種場景下對比其他的搜索引擎的檢索速度都顯得尤為出眾。這篇就先不介紹ElasticSearch了，后續我會出一個ElasticSearch的教程，目前已經寫的查不多了，mq相信大家應該最熟悉就不過多介紹了。
使用搜索引擎，我們需要將DB中的數據同步到搜索引擎中，為了保證讓用戶看見最優質的數據所以講搜索引擎中的數據進行優化，簡稱：搜索池。將一些不達標的數據不展示出給用戶。將不同種類的數據類型，添加進入搜索池的條件，如果添加修改搜索池為同步操作，操作頻繁並且如果處理時間過長可能會引發超時等等一些問題，影響了核心業務的操作。所以講同步搜索池數據的操作采用mq異步執行同步數據任務，這樣數據的同步就不會影響核心業務的操作。但是雖然解決了保證核心業務的處理但是有時也會有許多坑，這里作者就分享一次踩坑經歷。
問題背景
在批量同步數據的時候，每次執行了一遍刪除數據的個數與添加一遍后的個數對不上，例如：一共有20條數據，刪除一批數據剩10條，同樣的添加了這批數據還剩18條，這2條數據就丟了。這時候就比較苦惱了，檢查了業務與另一個線程的業務也沒有發現報錯或者邏輯出現問題。偽代碼：
public Integer 方法名（參數）{ //批量修改操作 DAO 參數集合.forEash(s->{ //遍歷將變更數據唯一id發送mq }); }
問題分析
這里是修改完數據后發送mq請求，根據傳參的不同添加或者刪除 搜索引擎中的數據。按邏輯來說這樣子寫是沒有什么問題的。但是經過層層的調試，終於發現了問題所在。在我們的系統中這個類是被加上事物的，因為是update數據所以這些操作都是會加上事物的。那事物為什么會影響呢？看下圖
很明顯的看到在沒有真正修改數據之前先發送了mq請求，而mq拿到請求去查詢這些數據的時候這些數據的狀態還沒有被真正修改。所以先發送mq請求和真正修改數據之間的短時間變差，導致了優先被發送mq請求的前幾條數據出現問題。所以在批量發送mq請求的時候一定要注意事物控制的問題，單量操作一般不會出現問題，因為單量的速度是很快的。提醒大家在提高性能的同時，一定要仔細評估方案細節。