1、問題：

公司采用了自動發布平臺，最近突然發現一個問題，上線完成後服務是能正常訪問的，但是有一個節點訪問的時候每兩次中總是有一次404，通過nginx的access日誌分析發現第一次正常訪問有一次get請求202，接下來訪問第二次或出現一次get404，post202，get404，返回三個請求？很奇怪啊。

2、探索：

首先檢查nginx是否有人修改，導致轉發出問題。經檢查發現沒問題，然後去後端服務器排查是否啟動了多個instanc，使用pm2 ls查看，只有一個instanc。然後再查看端口，netstat -tunlp | grep 10081,也只有一個。那就很奇怪了，從訪問的結果來看明顯是輪訓了兩個節點，於是查看代碼的commit id，pm2 show 21 (21是pm2的id)，發現代碼是1個月前的；到項目的目錄下，使用git log查看發現代碼就是最新的。問題已經發現了，就是一個instance有了兩份代碼，並且輪訓訪問。而只能看到有一個是啟動的。猜想是之前的進程沒有在代碼發布的時候平滑重啟，導致有兩個進程都占用同一個端口，但是代碼確實兩份。所以訪問的時候會出現輪訓一個錯一個對的情況。

於是將現有的instanc停掉，來驗證之前的猜想，pm2 stop 21，發現服務還是可以訪問的，只是一直返回的是報錯的那個。netstat -tunlp | grep 10081，發現還是有輸出。這就驗證了，一個端口，兩份代碼，兩個服務的猜想。

3、解決：

將instan刪掉，pm2 delete 21，將剩下的那個netstat -tunlp | grep 10081，根據pid將進程kill掉。然後重新構建，問題就解決了。

4、FQA：

1、這個問題並不是必現的，因為向上的服務是可以正常訪問的，又是集群環境，因此發生的時候，bug不容易排查。

2、在nginx的access日誌裏面，觀察到總有某個節點請求會有失敗和成功，並且很有規律，就可以考慮排查一下是否是這個錯。

3、目前懷疑是pm2 的startOrReload的bug導致的，正在進一步研究。

記一次pm2的踩坑