在處理一個手工發(fā)放批次任務(wù)的線上反饋時，我們發(fā)現(xiàn)瀏覽器在創(chuàng)建任務(wù)后會卡死，尤其是在涉及超過1000人時。然而，后端的創(chuàng)建接口會迅速返回一個任務(wù)ID，顯示創(chuàng)建任務(wù)本身并沒有性能問題。因此，我們決定先讓前端同事進(jìn)行排查。
經(jīng)過前端同事的測試，發(fā)現(xiàn)問題出現(xiàn)在任務(wù)創(chuàng)建完成后，前端會查詢批次任務(wù)，其中包括發(fā)放成員列表。這個列表本應(yīng)支持分頁功能，但在批次狀態(tài)為“初始化”時，接口返回速度異常緩慢，數(shù)據(jù)會持續(xù)返回。這條信息本該引起注意，但我卻忽略了，沒考慮到查詢過程中批次狀態(tài)的重要性（需要反思在溝通中忽視了這個問題）。
批次任務(wù)創(chuàng)建后會立即異步執(zhí)行充值操作，狀態(tài)很快從“初始化”變?yōu)椤耙淹瓿伞?。過去由于數(shù)據(jù)庫配置較高，任務(wù)執(zhí)行迅速，所以前端查詢時批次大多處于“已完成”狀態(tài)。然而，現(xiàn)在由于配置降低，執(zhí)行速度變慢，查詢時批次常處于“初始化”狀態(tài)。更糟糕的是，列表接口在未初始化時沒有分頁功能，導(dǎo)致返回數(shù)據(jù)過多，從而使瀏覽器卡死。
在自己測試時，定位問題困難的原因如下：
- 查詢?nèi)罩救笔?/strong>：在查詢初始化狀態(tài)時，沒有記錄日志。由于數(shù)據(jù)量過大，日志被忽略且未打印出來。
- 數(shù)據(jù)傳輸瓶頸：雖然在鏈路中SQL執(zhí)行時間很短，但中間存在大段空白時間。這段時間應(yīng)該是數(shù)據(jù)傳輸造成的延遲，但因?yàn)槿鄙偃罩荆艺`以為是網(wǎng)絡(luò)連接的問題，而未意識到是數(shù)據(jù)量過大導(dǎo)致。
- 未重視批次狀態(tài)：自己測試時沒有考慮到請求執(zhí)行時的批次狀態(tài)，未意識到問題的嚴(yán)重性。
教訓(xùn)總結(jié)：
- 重視關(guān)鍵信息：在溝通時要特別注意關(guān)鍵性信息，不能主觀臆斷，尤其是對于他人認(rèn)真反饋的重要信息。
- 完善日志記錄：對于關(guān)鍵接口，需增加日志記錄，確保日志信息完整且不會被忽略。
- 實(shí)現(xiàn)接口分頁：列表接口必須添加分頁功能，以防止因數(shù)據(jù)量過大導(dǎo)致性能問題。
