开篇
先来讲一个故事，最近在改造项目中日志处理服务，使用了公司内部公共的一些组件与服务。好不容易改造完成了，前几天开始灰度上线，上线观察了一天，从监控平台上可以看到，每次流量高峰期（一般早中晚各一次）就会出现大量的thrift反序列化失败的问题。出现问题怎么办呢？解决呗，就这样，故事开始了...
数据流图
先来介绍整个服务的数据流示意图，如下：
- 每台服务器都会部署一个scribe-agent，用于将本机产生的日志发送到远端的scribe-server；
- scribe-server将收集的日志分别打印到HDFS和kafka。
然后我这边有一个服务去消费kafka的数据，做一些数据分析。
发现问题
服务跑了一天多，我从公司内部的监控平台上发现，我的服务（消费kafka的服务）在每一个日志高峰期都会出现大量的thrift结构反序列化失败的异常。
解决问题
发现问题之后我有几个可以怀疑的地方：
- 打印日志的服务和消费日志的服务使用的thrift版本不一致，导致序列化失败（我的问题）；
- 日志序列化或者反序列化的时候有多线程安全问题，导致数据被打乱(我的问题)；
- 由于消费kafka过程中使用了disruptor框架做异步处理，怀疑disruptor有bug；
- 日志在传输过程中被篡改（不是我的问题）；
其中第三点可以细分为以下几个可能：
- scribe-agent写日志到scribe-server有bug（scribe-agent是其他team同事负责的）
- scribe-server将日志写到kafka有bug（其他team同事负责的）
一般来说，排查问题都应该从自身问题找起，所以首先来证明自己的清白：
- 通过MD5检查写日志的服务和分析日志的服务使用的thrift是同一个版本；
- google了一下，我使用的序列化和反序列化应该没问题，并且我们主业务也是使用相同的方法；
- 将disruptor的ringBuffer大小设置为0，变异步成同步；
做了上述修改与实验之后，还是没有解决问题，所以可以断定问题出在第四步：日志在传输过程中被篡改。
于是发邮件咨询相关的同事，得到的回答都是没有问题的，很多业务都使用我们的服务，从来没出现过问题，你再找找原因吧。，没办法啊，气场不够，只能说声谢谢，然后继续自己摸索。
三天时间过去了，还是没能找到自己的原因，我真是快要奔溃了，于是在leader的陪同下亲自去找之前邮件沟通过的同事，大概聊了20分钟，最后对方突然说：流量高峰期的时候，我们会将日志写到本地文件，随后再次读取的时候可能真的会有问题，巴拉巴拉一堆，说我们看看吧，一会儿给你们回邮件。
回来等了几分钟，收到邮件了：这个确实是我们的一个bug，你们流量太大了，之前都没有遇到过，我们会尽快修复，到时候通知你们。
总结
- 程序员天生自信，当受到质疑时，第一反应就是："我的程序肯定没问题"；
- 程序员最最重要的两个东西：技术，名气，如果没有技术和名气，别人根本不把你当回事，遇到问题时都会认为是你自己的问题，所以，努力提升自己技术和影响力吧！
声明
本文首发于个人技术博客，转载请注明出处，本文链接：http://qifuguang.me/2015/11/13/%E7%A8%8B%E5%BA%8F%E5%91%98%E6%9C%80%E9%87%8D%E8%A6%81%E7%9A%84%E4%B8%A4%E4%B8%AA%E4%B8%9C%E8%A5%BF/
如果你喜欢我的文章，请关注我的微信订阅号：“机智的程序猿”，更多精彩，尽在其中：
