1 背景與目標1.1 背景國際財務泰國每月月初賬單任務生成 ， 或者重算賬單數據 ， 數據同步方案為mysql通過binlake同步ES數據，在同步過程中發現計費事件表 ， 計費結果表均有延遲，ES數據與Mysql數據不一致，導致業務頁面查詢數據不準確，部分核心計算通過ES校驗失敗
1.2目標解決binlake到JMQ積壓同步ES延遲問題
2 當前業務流程2.1 流程圖【京東云開發者｜mysql基于binlake同步ES積壓解決方案】現有業務基本流程如下圖，包含運營端和外部數據接入，整體操作到數據存儲流程
文章插圖
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）更新緩存并釋放鎖
推薦閱讀
- 京東云開發者｜軟件架構可視化及C4模型：架構設計不僅僅是UML
- 最新蘋果iOS個人開發者賬號注冊申請流程 申請蘋果id賬號注冊
- 奧比島:夢想國度暗夜襲擊魔藥店失竊疑云答案是什么
- 云原生之旅 - 9）云原生時代網關的后起之秀Envoy Proxy 和基于Envoy 的 Emissary Ingress
- 華為云 MRS 基于 Apache Hudi 極致查詢優化的探索實踐
- 棲云異夢金屬星球怎么擺放順序
- 云原生之旅 - 8）云原生時代的網關 Ingress Nginx
- 華為開發者大會HDC2022：HMS Core 持續創新，與開發者共創美好數智生活
- 云原生之旅 - 7）部署Terrform基礎設施代碼的自動化利器 Atlantis
- 華為開發者大會2022：HMS Core 3D建模服務再升級，萬物皆可驅動