1、一共有三台服务器，均为独立的服务器，一台 nginx 采用权重 weight=1，weight=1 的方式分别发送到两台 tomcat 服务器；
现在发起压力，tomcat1 和 tomcat2 的服务器受到的压力不一致，CPU%，DISK,MEM% 都有差距。
2、前三个的场景 CPU% 看起来都较为正常且无较大波动，只有第四个场景会出现较大的波动且 tomcat1 和 tomcat2 CPU% 有互补的现象（即 tomcat1 有压力的时候，tomcat2 不会有较大的负载压力）
疑问：为什么只有场景四会出现这种现状，其他三个场景都不会出现互补的情况。
（注，图一为 tomcat1 服务器，图 2 为 tomcat2 服务器）
3、补上一些细节图
这是 TPS 图：
这是响应时间图：
这是各服务资源监控：
这是简陋聚合报告：
未知地区 1F
可能要再说明一些场景的细节了，
有个不成熟的猜测：互补的情况有没有可能是因为事务处理时间较长，同时还存在阻塞的情况，举个例子就是 tomcat1 开始处理了就必须处理完，tomcat2 稍微空了点，下一次就反过来了？配置好 LB 后，可以先不用业务去测试，可以用一个默认 web 页，去验证负载均衡。验证没有问题后，再对业务进行测试。建议：
1、先通过 nginx 日志看看场景 4 里面，nginx 流量分配是不是还是均衡的。
2、放大一点 cpu 图，确认下是否同一个时间点，都是一个节点 cpu 高，另一个低。不要只看形状，得看具体时间点（前提是 2 个服务器的系统时间都是一致的）。
3、确认下场景四涉及的处理逻辑里，是否有用到分布式锁之类的控制并发的设计。如果有，可能拿到锁处理的节点 cpu 会高，其他节点在等待锁的就降下来了。
如果期望大家给到更好的建议，请补充更多的场景细节吧。现在只有个 cpu 占用情况，只能瞎猜。。。我是觉得 nginx 是没有问题的，看前三个场景，两台服务器受到的压力都差异不大，说明 nginx 是在有生效的。我也考虑过这个问题，看过一篇文章是说 nginx 的权重分配策略是根据连接数还是请求数进去分配，如果 tomcat1 有对应的连接数/请求数不处于空闲状态就不会继续分发请求到 tomcat1。1、nginx 的日志是看 access.log,这个日志吗；我对 nginx 是比较陌生~，可以确定的是 nginx 的分发是没什么问题的，但在场景四是不是按设置的权重可能是看看这个 access.log 日志，但这个日志是如何可以看出权重是不是一致，我得查查资料了。
2、我去到对应的 nmon 查看了对应的时间段，可以肯定就是一个 tomcat 服务器低，另外的一个 tomcat 服务器就会高。
3、这个我估计没吧，我去问问开发，我们公司在设计方面应该是不会用到这些高级的东西~，还有这个业务场景其实就是查询类，前面几个场景也是查询类。所以我推测大概率不能存在这些分布式锁的设计（这个我还是确定一下再答复）
4、我在正文补充了一些细节和图形，其他细节你想知道的我再补充。nginx 流量分配策略有好几种的，如果你不确定，先确认下配置的是哪种吧。weight 的话我理解只会按输入的流量去做分配，应该不涉及连接数或者请求数
你也可以查一下两个节点的日志打印情况，确认下 nginx 是不是 1:1 把流量分配到两个节点上。
最后，建议你还是具体了解下场景四的查询实现逻辑（最好直接去看代码，至少了解到能画出一个服务一个泳道这种级别的交互时序图），和前三个有什么差异点吧。不去了解具体逻辑的话，很难做原因分析定位的。