高併發系統之大忌 慢查詢

2022-07-05 17:30:16 字數 1222 閱讀 5307

最近又遇到了一次慢查把db(mariadb10)幾乎打掛的案例,作為乙個核心支付系統的技術負責人,真是每日如履薄冰。因為之前支付系統經常出問題,現在各個bg對支付系統都盯得很緊。這次要不是我及時讓db給暴力清理資料,沒準又提乙個p2故障;

抱怨歸抱怨,事後覆盤,一絲都不能馬虎。首先,描述一下故障的全過程。起因是我們支付系統有乙個非同步佇列,這個佇列使用的一張mysql表儲存,非同步**業務線的任務(姑且表名稱叫task),都會首先放這裡。同時這個task表還有其他的非同步任務,不同的任務使用task_type欄位來進行區分。然後應用系統有乙個定時任務,掃瞄這張表是否有待消費的任務,如果有,則會取出來進行消費;典型的生產者消費者模型;

這裡的task說的再具體一點:

1、所有的非同步任務都在這張表,有支付成功通知業務線訊息,有給結算系統推送支付資訊的任務;

2、消費者在任務處理成功後,則會把任務從task表刪除。所以這張表經常是空的;

消費者根據不同的任務,呼叫不同的上游訂單系統和結算系統。出故障時,是因為推送支付資訊的結算系統介面超時,出了問題,導致任務被積壓到了task表。

任務積壓之後,消費者執行緒池很快就被積壓的任務佔滿,導致應該通知bg訂單支付成功的任務也被block住,進而影響到訂單支付成功率。

當時我已經意識到,我們的消費者執行緒池隔離沒有做到位,立刻找dba將推送給結算系統的任務進行了備份並清理。並且囑咐dba定時清理推送結算任務的資料。這樣才化解支付成功率繼續下滑的趨勢。

危機解除後,我們和dba配合進一步排查問題,找出了事情的根本原因。

原來是推送結算資訊的邏輯中,有乙個對task表的查詢,而這個查詢的sql,沒有建索引。這樣當這類任務數量積壓的比較多時,查詢會越來越慢,慢查導致mysql堵塞。堵塞導致消費者無法拉取任務,進而影響到其他通知bg的任務的消費;我們分析了一下日誌,其實我們的程式查詢數量當時3分鐘大概查詢了1萬多次,可以說qps不多。但是問題出現在sql無法命中索引,把mysql的worker thread都用完了。給我們研發的感覺,mysql是如此的脆弱,2w多條資料,查詢沒有索引,幾千個select,就能把它打掛。

遇到類似問題如何解決?

1、讀寫分離。

2、提前消滅慢查詢;

3、對非同步任務做好執行緒隔離;

高併發系統設計

高併發系統主要是為了解決在有限的資源下解決最核心的問題,並發現以後可能會出現的問題。高併發原則一般遵守如下幾個設計原則 1.無狀態 指的是應用在處理業務邏輯期間盡量減少鎖的使用 降低網路通訊延遲 無資料持久化操作等,以此來增加應用系統的效能。2.拆分 大而全的系統,可根據實際的訪問量來拆分系統,來實...

高併發高負載系統架構

一 為什麼要進行高併發和高負載的研究 1 產品發展的需要 2 公司發展的需要 3 當前形式決定的 二 高併發和高負載的約束條件 1 硬體 2 部署 3 作業系統 4 web 伺服器 5 php 6 mysql 7 測試 三 解決之道 硬體篇 處理能力的提公升 部署多顆cpu,選擇多核心 具備更高運算...

高併發高負載系統架構

首先呢,我羅列一下文章的目錄,讓大家有個整體輪廓的了解!1 為什麼要進行高併發和高負載的研究 2 高併發和高負載的約束條件 3 解決之道 硬體篇 4 解決之道 部署篇 5 解決之道 環境篇 6 解決之道 siteengine篇 7 解決之道 測試篇 8 結尾 1 為什麼要進行高併發和高負載的研究 1...