最近在專案中遇到乙個特殊情況，某個客戶通過https訪問公司的公網服務，有較大概率出現響應超時的問題。
經過排查定位，確認以下資訊：
1、客服伺服器訪問其他公司服務，均沒有出現大概率的超時問題。
2、公司服務，壓力測試正常，且沒有其他客戶反饋此類問題。
3、客戶公網出口，三大運營商各有一條。
根據以上資訊，初步定位是運營商網路，到公司阿里雲服務期間的路由問題。以下是檢測過程：
1、執行traceroute進行路由追蹤，確認出口是移動運營商，但還無法確認具體問題。
2、使用mtr命令，發現請求報文在區域運營商網路**到阿里雲伺服器期間，丟包嚴重。
解決方案：因為阿里雲伺服器部署在杭州地區，為解區域運營商路由問題，在西南區重新購買伺服器進行部署，問題解決。
記一次mysql鎖超時問題
排查過程 select from information schema.innodb lock waits select from information schema.innodb trx show engine innodb status show variables like autocomm...
記一次nginx超時404
想用php請求數個介面,花費時間較長,導致超時 起初只是使用set time limit 0 等方式在php內操作,未能解決 後又修改php引數,ng引數未能解決 最終在網上一番查詢,在ng的配置檔案中加入下方的 fastcgi connect timeout 300 fastcgi read ti...
記一次linux httpd的https配置
解壓得到乙個證書檔案 私鑰 和chain檔案。chain檔案幫助瀏覽器識別你的證書和內建ca的關係，如果你的頒發ca是由另乙個ca頒發的。上到自己伺服器，使用命令 httpd m 檢視httpd的模組，發現缺少mod ssl模組，這是編譯時沒有開啟ssl引數。使用 httpd v 檢視版本 發現版本...