接到現場報告，MongoDB向ES同步資料延遲越來越大，有的已經超過10個小時，造成客戶新加入的用戶無法被搜索出來，由于在系統中ES類似于數倉，很多統計和第三方接系統都需要從ES獲取資料，所以也影響了一些其他依賴ES資料的功能和業務，
架構簡圖
tomcat------日志資料----->logstash-------日志資料--->| E S
mongodb---業務資料--->mongoshake---業務資料 -->| 集群
日志通過logstash同步到ES，業務資料通過mongoshake自己實作的ES推送組件推送到ES，ES 5臺構成一個集群，
問題現象
- 延遲只發生在第二條通路，第一條通路雖然也有較大并發，但不發生延遲；
- 且延遲在業務峰期才會出現，非高峰期延遲不嚴重或沒有延遲；
- 通過上面的描述可以確定此延遲于業務相關，且與mongoshake推送的實作方式相關；
初步分析
這個結構在兩個異地機房各有一套，中間通過同步機制同步，由于業務資料是從本地mongodb同步到本地ES發生延遲，首先排除是雙機房間傳輸帶寬問題，
會不會是ES在業務高峰期負載過高，造成推送延遲：可能性有，但是較低，因為如果是ES查詢并不慢，且如果是由此造成，logstash 推送也應該受到影響，對ES的性能監控也可以印證這個問題，
會不會是兩種資料業務的不同造成的性能差異：logstash的資料主要是日志，插入為主，mongoshake的資料是業務資料，涉及到對以前的資料進行修改：確實有可能，但比較起來延遲不應該有如此之大，一個秒級延遲，一個天級延遲，還是首先考慮實作機制問題，
同步機制
mongoshake向ES同步機制，是將需要在ES存放的幾張表的oplog在ES回放，此程式由我們的開發人員擴展的mongoshake ES組件完成，
oplog ----- mongoshake----- oplog replay----->ES
聯合高峰期延遲增加的現象，可以猜測高峰期業務資料操作造成的oplog有大量增加，由于mongoshake本身（除非修改原始碼）只能篩選表，不能篩選哪些表的具體日志，只要是這幾張包的oplog都會同步，所以造成延遲，到底是oplog過多需要篩選，還是同步能力太低需要改進，我們需要進一步查證，
推送能力統計
現場人員查看了一段時間的同步量，對現有機制的oplog處理及回放能力進行統計，
第一次統計：130秒同步 2186
第二次統計：180秒同步 2714
可見平均每秒能力不足20條日志，肯定是過低，那么客戶現場實際業務每秒到底要產生多少條資料？這個問題要查清楚，作為推送性能優化的底線，
實際業務oplog情況分析
對客戶業務能力進行統計，需要將一整天的oplog匯出，oplog由于沒有索引，雖然可以直接通過find，并給出ts 查詢，但由于有40G資料，查詢及其緩慢 ，所以我們選擇將資料匯出到文本檔案，進行分析
start=$(date +%s -d "2020-03-24 08:00:00")
end=$(date +%s -d "2020-03-24 10:00:00")
mongodump -h localhost -d local -c oplog.rs -q '{"ts":{$gt:Timestamp('$start',1),$lt:Timestamp('$end',1)}}' -o /home/backup
cd /home/backup/local
bsondump oplog.rs.bson > oplog.rs.txt
進一步對oplog進行分析，在vim中分別統計每個小時的日志數量，可以得到下表：橫軸是北京時間24個小時，縱軸是oplog數量，其中灰色是oplog中需要同步到ES的
?
可以看出高峰期oplog大量增長，需要同步的日志超過150000，平均每秒42條oplog需要同步，而處理能力不到20，所以高峰期一個小時的資料往往需要2-3個小時才能同步完成，且從8點開始，一直都下午18點，實際oplog產生都超過處理能力，
往下的優化方向，一個是減少日志，一個是增加處理能力，高峰期每秒42條日志已經不高，雖然可以優化，但可優化范圍有限，增加處理能力才是關鍵，
開發查看ES同步代碼，原有代碼使用逐條同步模式，同步一條，獲取一條，同時采用性能較低的腳本同步方式，現在使用批量處理（實作參照mongoshake 向mongodb同步的 direct writer實作，批量呼叫elastic Client 提供的bulk api進行操作）
bulkRequest := bw.client.Bulk()
for _, log := range oplogs {
......
bulkRequest.Add(elastic.NewBulkDeleteRequest().Index(index).Type(doc_type).Id(id))
}
bulkResponse, err := bulkRequest.Do(context.Background())
對update 中的unset（洗掉欄位） 進行處理，因為unset執行有速度有瓶頸，所以根據實際情況直接改為將欄位置空；
for _, v := range unsets {
doc[v] = nil
}
效果
在進行上述操作后，單執行緒情況下資料處理的速度超過每秒1000條（未嚴格測驗），新同步代碼幾分鐘就能同步一個小時的oplog，完全達到性能要求，
討論
oplog優化
由于ES同步性能大幅提高，所以可以不用繼續優化oplog，但是oplog可以反映關鍵業務對資料庫的訪問情況，特別是寫入，在mongodb replica set中只能在primary 節點完成，即使增加節點也無法分擔流量，所以對oplog的進一步分析依然必要，同時oplog中包含數量的大小，也對replicaset 的同步帶寬有影響，特別是出現跨機房同步的情況時，
所以更進一步，我們還對業務oplog進行了分析，此分析我們會在別的文章中討論，
多執行緒執行
注意這里ES同步沒有使用多執行緒處理，主要是考慮業務資料多執行緒操作的事務性，要實作此種事務，需要對mongodb本身進行一定改造，對mongodb原始碼改造實作雙向同步和多執行緒寫入會在其他文章中討論，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/4603.html
標籤：NoSQL