一、背景

某天下午，上游系統同一時間突然下了三個大合同數據，平均每個合同數據實例在6萬以上的量級，短短幾分鐘內瞬間有20萬左右的流量涌入系統。
而在正常情況下，系統1天處理的流量也不過2千量級，當時數據庫指標監控告警，數據庫會話直線上升，CPU毛刺增多，達到了80%。

二、排查措施

1：數據管家平臺查看慢SQL執行情況，并分析出現慢SQL原因
2：查看消息平臺的業務報錯記錄日志，根據報錯來看，數據庫無法獲取連接，標識當時數據庫的處理能力已經達到上線，無法同時處理這么多會話
3：分析docker運行情況，無大的波動，基于此，定位到影響業務的瓶頸在數據庫

三、整改措施

大批量的信息消費，如果通過升級數據庫規格，增大連接數等手段雖然短時間內可以解決問題，但是增加了機器成本，無法徹底解決問題。
1：控制事務的粒度
在進行事務處理時候，盡量減少事務的范圍，避免長時間占用數據庫連接。可以將多個大的數據庫操作拆分成介個小事務或者無事務，這樣就可以釋放更多的數據連接，提升并發處理能力。評估了核銷這塊邏輯事務影響不大，最終改成無事務操作數據庫。

2：優化代碼結構，減少數據庫交互
優化代碼，優化SQL等手段，比如循環單個處理改成批處理等等。

3：削峰填谷(主要措施)
1）通過設置消息消費配置降低服務消息速度
目前交付單系統服務生產環境部署8臺服務器，每臺機器配置的消費線程是4，從機器運行指標情況來看，docker無壓力，可以分析得出服務消費消息速度過快，數據庫處理能力跟不上。比如我們定義consumer參數為

//拉取批次消息個數，保持不變
setPullBatchSize(32);
//緩存消息個數，指單個queue，默認1個topic對應8個queue，1個消費者最大會緩存8000條，保持不變
setPullThresholdForQueue(1000)
//消費線程最小數，可以降低配置到4
setConsumerThreadMin(8)

2）使用任務Job進行削峰
上游OMS系統瞬時下發的消息，統一先落入集成的數據庫表，落入表之后不立即觸發世間處理，而是由1個ischeduler定時調度任務，按照恒定的速率取固定size數量數據進行撈取進行處理。這樣保證上游無論
瞬時數據多大的并發，我們數據庫都不會因為壓力過大而丟失數據