用 pkg_resources 来查
>>>import pkg_resources >>> pkg_resources.get_distribution("construct").version '2.5.2'

print([p.project_name,p.version for p in pkg_resources.working_set])

@chinvo，实际上这样难点倒不是如何找到包的版本，而是确认进程中引用到的包的版本，同时不能因为检查这个包而引入这个包，同时也不愿意去主动 reload_model

@18870715400 这样只是调用系 pip 查看包的版本，并不代表进程内用的就是这个版本的包呀。除非让进程重启，这个显然是不可能的。

自己用 pyinotify 找了下信息的上下文，找到原因了，原来被其他人的 Jenkins 更新删了。。。

@Vegetable，提供了一个 oper 用户，没有虚拟环境，被删除就是包被 uninstall 了， 缓存还在

@Hopetree，哈哈，理论上是应该分离的，只是这个是老项目了，拆起来觉得麻烦。不想动

@ruanimal，就是 pip 包无缘由的被删除了，想要定位到原因，但是 pip 的没有 log，所有问问大家有推荐方法没

@lxk11153，最近不断被删除，每次手动装太麻烦，难

@luozic，好的，感谢大佬

@Qzier，flask 做的接口

@martyyyyy，用的是 flask

@luozic ,链接打不开兄弟

@julyclyde，是的

@jasonyang9，是我懵逼了

@DevilHunterXX，是的，写个脚本不停的抓，大不了抓几天，一定会碰到的

原因很简单，用相同的 hash 函数可以方便的将对象和 cache 节点对应起来呀，一致性 hash 的核心是解决 cache 节点增加或者删除的时候所有 cache 节点都会受影响，出现的各类问题，所以实际上是解决对象与 cache 节点的对应，降低影响范围。相同的 hash 函数用起来方便可行，用两个也可以。(只是没人会无缘故的舍近求远而已~)

最后回复：
对应的进程找到，并且已经处理了，感谢大家的建议。
简单总结一下：
1、用极短的时间抓 pid 这个思路也不太行，应为极短的时间很难定义，各种参数 -c 1 都不行
2、用程序的方式也不行，程序也是调用系统命令，系统不行，程序也不行
最后的方法：
简单的说就是“撞大运”，不停的抓 pid （通过 tcpdump，netstat、lsof 都行），抓一天，两天这样。总会在连接刚开启的时候被发现一些业务中不应该出现的命令或者进程，然后再分析来源，最终定位到问题进程，所以我的感觉是长时间多次抓包，虽然概率低，但终究是能找到的，需要耐心了~

感谢各位~