一. 現狀·問題 針對現如今高併發場景的業務系統，“併發問題” 終歸是必不可少的一類（佔比接近10%），每次出現問題和事故後，需要耗費大量人力成本排查分析並修復。那如果能在事前儘可能避免豈不是很香？ 二. 分析原因 當前併發測試多數依賴測試人員進行腳本測試，同時還依賴了研發和產品識別出併發操作的場景用例。 對於併發測試，大概兩條路子： 所有修改同樣數據的命令式接口都測一遍？【耗費巨大
背景介紹 最近，我們發起了一個在線圖書管理系統的項目。我負責的一個關鍵模塊包括三個主要後台接口： 實現對books數據的檢索。 實施對likes數據的獲取。 通過collections端點訪問數據。 應對高流量的挑戰 在設計並部署接口時，我們不可避免地需要考慮關鍵的問題： 你製作的產品會不會面臨大量的訪問需求？ 你的接口和服務器是否能夠處理如此高的用户訪問量？ 歸根結底，問題是：
