记录一次多个环境导致代码bug问题

一、场景复现

因为公司环境首先分为生产，测试，预发布，发布环境。而当时我在生产环境去进行自测时，发现自己的请求测试时而成功，时而失败。
成功失败与否其实很简单，就是看数据库有没有成功修改那条数据。因为我的场景是如果有新的订单，那么就会生产消息从而触发消息队列同步客户信息。我的测试场景是修改这个客户信息然后给这个客户手动增加一笔订单从而让它生产消息从而启动消息队列。
经过4次测试后回到数据库一看，发现有2次并没有修改这个客户的信息，而是直接新增（这个新增的原因是因为老代码的Bug,我也是为了修复这个bug才复现的这个场景）。当时并没有反应过来真正原因。
于是在消息队列增加了一条日志又来检验有没有走消息队列（用来排查是不是在别的地方直接create了），结果发现日志没打印出来！！
但是其实并不可能按道理来说，因为这个create只有两个地方被调用，一个是消息队列，也就是我刚才加日志的那块儿，另一个就是老代码，但是老代码那块儿本来就有日志，如果在那儿调用肯定也会出现相关日志，但是并没有调用。

二、原因

后面leader指出，当时oss有3台机器在同时运行，之所以哪里都没有日志，是因为zk将请求负载到其他机器上了，所以自然看不到相关日志及之前bug出现的error堆栈。

三、zk负载

由于zookeeper主要扮演的角色是分布式集群中的协调者，所以首先介绍一下分布式和集群的概念。简单来说，分布式是将一个完整的系统拆分成多个能实现不同业务需求的系统分布在多个地方，而集群是只将业务需求相同系统或服务复杂多份放在不同的服务器实现负载均衡，减轻服务器压力。用个比喻来说，小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。

zookeeper实现负载均衡其实原理很简单，zookeeper 的数据存储类似于liunx的目录结构。首先建立servers节点，并建立监听器监视servers子节点的状态（用于在服务器增添时及时同步当前集群中服务器列表）。在每个服务器启动时，在servers节点下建立子节点worker server（可以用服务器地址命名）,并在对应的字节点下存入服务器的相关信息。这样，我们在zookeeper服务器上可以获取当前集群中的服务器列表及相关信息，可以自定义一个负载均衡算法，在每个请求过来时从zookeeper服务器中获取当前集群服务器列表，根据算法选出其中一个服务器来处理请求。

四、总结

其实这个问题我碰到过不止三次，但每次都没有注意，往往会在这上面耗费大量时间，虽然问题原因很小，但若是有此经验，后面遇到势必可以有这个考虑方向，从而减少排查时间。
另外，需要自己学会去看堆栈排查问题，而不是依赖leader.这一点非常重要!也是排查问题后面的必备要素。