京東雲開發者｜mysql基於binlake同步ES積壓解決方案

1 背景與目標

1.1 背景

國際財務泰國每月月初賬單任務生成，或者重算賬單資料，資料同步方案為 mysql 透過 binlake 同步 ES 資料，在同步過程中發現計費事件表，計費結果表均有延遲，ES 資料與 Mysql 資料不一致，導致業務頁面查詢資料不準確，部分核心計算透過 ES 校驗失敗

1.2 目標

解決 binlake 到 JMQ 積壓同步 ES 延遲問題

2 當前業務流程

2.1 流程圖

現有業務基本流程如下圖，包含運營端和外部資料接入，整體操作到資料儲存流程

2.2 資料流

3 問題分析

3.1 問題現象

jmq 積壓，報警
國內站截圖如下

3.2 篩查分析

普及：JMQ 預設生產者傳送訊息 QPS 受到主題的 broker 數量影響，(8w/s)/broker

3.2.1 MQ 積壓分析

1）分析原因一、ES 寫入量大，導致 ES 寫入 QPS 瓶頸

ES 寫入瓶頸需要進行壓測，才能確定實際是否達到瓶頸；
透過查詢叢集負載，寫入佇列有無積壓，cpu 高不高，來定位
以下為調整 MQ 批次消費大小後的 ES 監控
寫入佇列無積壓，CPU 不高，寫入 QPS 沒有達到瓶頸

2）分析原因二、ES 寫入慢導致消費積壓

ES 解析服務解析慢，瓶頸在 ES 解析處
根據當前系統 CPU、負載資訊定位是否伺服器效能滿負荷，是否擴容
無報警資訊，整體執行平穩，基本排除業務資源達到瓶頸問題引起寫入慢

MQ 消費端消費慢，瓶頸在消費併發處
當前主題分片數 3，佇列數為 15，預設最大併發數為 15*10，報警當時入隊數 500~700/s
定位問題，為 MQ 消費慢，其根本原因為受到 ES-Parse 業務系統處理速度影響

3.3 臨時處理方案

開啟 mq 並行消費策略，寫入 QPS 顯著增加

4 如何提升消費速率，提升寫入 ES 速率

造成問題原因核心點是 MQ 積壓，業務系統消費慢，MQ 入隊數大於出隊數，導致積壓

4.1 原理分析

4.1.1 儲存流程解析

第一步：binlake 訂閱 mysql binlog
第二步：發 MQ，JMQ 資料傳輸
第三步：消費 JMQ 資料，ES Paser 資料解析，
第四步：資料儲存

4.1.2 binlake 基本原理

4.1.3 binlake 傳送 MQ 過程

4.1.4 JMQ 消費原理

JMQ 消費預設就是批次消費
消費原理如下圖

批次消費與並行消費原理如下圖

透過分析，在未開啟並行消費前提下，當前主題最大處併發的消費處理能力即是佇列數

4.2 提升消費速率的幾種方案

4.2.1MQ 增加消費速度方法

擴容，增加併發消費能力
針對 MQ 預設情況下，一切擴容都能解決問題，增大分片數，增加佇列數
需要額外資源，申請擴容新的 broker，同時考慮增加消費端例項

增加批次大小
首先保證，業務系統 (ES-Parse) 消費 MQ 訊息，處理 10 條和處理 100 條速度基本一樣
實踐：國際財務針對此方法進行程式碼邏輯改造

開啟並行數
理論上增加（並行數 / 批次數）的倍數併發處理能力
要求資料無序，針對亂序，資料儲存，不影響業務

4.2.2 並行有序的方案

1）實現資料冪等性，增加快取，並行消費策略

方案流程

基礎實現流程：

1）根據 binlake 傳送 mq，在 mq 端開啟並行消費，確保並行消費
2）根據業務單號對，單號加鎖（如麥哲倫對運單號加鎖，即對單號加分散式鎖），根據對應的 ID 獲取 ES 資料。
3）校驗資料是否有效，若查詢無資料，則直接新增；若查詢的資料狀態大於當前資料狀態，則直接拋棄，若查詢狀態小於當前資料狀態，則直接更新資料
4）更新快取並釋放鎖

優點

• 指定資源情況下，增大消費端併發
• 可以開啟並行消費，且保證順序消費
• 可以使得資源充分利用，增加消費效能

缺點

• 增加毫秒級快取額外開銷

實踐：麥哲倫運單中心針對此方案實現 binlake 資料同步 ES

2）binlake 主題分發子主題，顯示增大併發策略

優點：

• 邏輯相對簡單，不需要開發複雜邏輯，無需引入額外中介軟體
• 預估轉發訊息速率即是實際處理速率

提升速率計算:

• 原主題單執行緒處理一條資料儲存到 ES 時間為 es_time，舉例為 50ms，每秒吞吐量是 20 條
• 現單執行緒轉發 MQ 一條資料時間為 trans_time，舉例為 20ms，每秒轉發吞吐量 50 條
• 假設轉發 topic 為 N 個子主題，則吞吐量理論為 n*20 實際小於轉發吞吐量 50，此處多子主題對 cpu 核數競爭
• 提升吞吐量為 =(1000ms/trans_time) 轉發吞吐量 - (1000ms/es_time) 原有吞吐量

缺點

• 擴充套件性不好，實際結果有待驗證，小於預估值

實踐：跨境赤道分發中心實現類似功能實踐，訊息轉發，其他 MQ 實現

3）倆種方案對比

主題較少一個倆個主題情況下，且業務處理比較耗時情況下，不想額外開發，可選方案二
長期方案選擇方案一，並行消費策略，可伸縮性，可擴充套件，支援動態擴容

5. 總結

針對 MQ 積壓問題，並行消費可以是解決問題的一大利器，本文從 binlake 同步 ES 進行分析，同時針對積壓推薦倆種方案，並從效能合理利用及擴充套件性分析，簡要介紹方案二並行有序消費策略，希望能夠幫助大家，如有問題，請隨時指出！

作者：任洪波