记一次pm2的踩坑

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导致的，正在进一步研究。