flask close_wait连接问题排查与修复方法

記得去年夏天，公司的那台Flask服務器突然卡到爆，用戶投訴像雪片一樣飛來。我當時以為是流量太大，結果一查系統監控，CPU和內存都正常，但連接數飆升到幾千個。用netstat一掃，滿屏的CLOSE_WAIT狀態，看得我頭皮發麻。這種TCP連接問題，在Flask裡頭特別常見，往往是資源沒關乾淨導致的，拖垮整個服務。

先說說CLOSE_WAIT到底是啥玩意兒。簡單講，這是TCP協議的一個狀態，表示本地端收到了對方發來的關閉請求（FIN包），但自己還沒發回確認。在Flask應用裡，常見於資料庫連接、外部API調用或文件操作沒正確釋放。舉個例子，如果視圖函數裡用了SQLAlchemy，但忘記在請求結束後關閉session，連接就會卡在這個狀態，堆積起來像雪球一樣，服務器慢慢就癱瘓了。

排查這問題，得從工具入手。我習慣先用終端命令：netstat -tulnp | grep CLOSE_WAIT，看看哪些端口和IP卡住了。接著，用lsof -i :端口號追蹤具體進程，定位到Flask的worker。有一次，我發現是某個第三方庫的bug，它沒處理好HTTP keep-alive，導致連接一直掛著。日誌分析也很關鍵，在Flask的logger裡加debug級別，監控每個請求的生命週期，尤其注意after_request鉤子有沒有執行。

修復方法多著呢，核心就是確保資源及時釋放。最簡單的，在每個視圖函數末尾手動關閉連接，比如用db.session.close()。但這樣容易漏，更好的招是寫個全局的after_request鉤子，自動清理所有資源。代碼片段像這樣：

進階點的話，上連接池管理。用SQLAlchemy的話，配置pool_recycle和pool_timeout，避免閒置連接卡死。伺服器層面，如果跑gunicorn，調worker_timeout參數，強制重啟長時間閒置的worker。記得那次我加了這個，問題立馬緩解。還得監控起來，用Prometheus或ELK stack追蹤連接狀態，一有異常就告警。

深度來講，這問題背後是HTTP協議的坑。keep-alive本意是提升效能，但Flask預設沒處理好時，就容易出包。建議在開發環境模擬高負載，用ab或locust測試，看連接數變化。實戰中，我常犯的錯是依賴框架自動處理，結果踩雷。現在寫碼，我強迫自己每個外部調用都用with語句包起來，確保萬無一失。總之，預防勝於治療，養成習慣檢查連接管理，省得半夜被call醒。

【評論】