转载

程序员最重要的两个东西

开篇

先来讲一个故事,最近在改造项目中日志处理服务,使用了公司内部公共的一些组件与服务。好不容易改造完成了,前几天开始灰度上线,上线观察了一天,从监控平台上可以看到,每次流量高峰期(一般早中晚各一次)就会出现大量的thrift反序列化失败的问题。出现问题怎么办呢?解决呗,就这样,故事开始了…

数据流图

先来介绍整个服务的数据流示意图,如下:

程序员最重要的两个东西
  1. 每台服务器都会部署一个scribe-agent,用于将本机产生的日志发送到远端的scribe-server;
  2. scribe-server将收集的日志分别打印到HDFS和kafka。

然后我这边有一个服务去消费kafka的数据,做一些数据分析。

发现问题

服务跑了一天多,我从公司内部的监控平台上发现,我的服务(消费kafka的服务)在每一个日志高峰期都会出现大量的thrift结构反序列化失败的异常。

解决问题

发现问题之后我有几个可以怀疑的地方:

  1. 打印日志的服务和消费日志的服务使用的thrift版本不一致,导致序列化失败(我的问题);
  2. 日志序列化或者反序列化的时候有多线程安全问题,导致数据被打乱(我的问题);
  3. 由于消费kafka过程中使用了disruptor框架做异步处理,怀疑disruptor有bug;
  4. 日志在传输过程中被篡改(不是我的问题);

其中第三点可以细分为以下几个可能:

  1. scribe-agent写日志到scribe-server有bug(scribe-agent是其他team同事负责的)
  2. scribe-server将日志写到kafka有bug(其他team同事负责的)

一般来说,排查问题都应该从自身问题找起,所以首先来证明自己的清白:

  1. 通过MD5检查写日志的服务和分析日志的服务使用的thrift是同一个版本;
  2. google了一下,我使用的序列化和反序列化应该没问题,并且我们主业务也是使用相同的方法;
  3. 将disruptor的ringBuffer大小设置为0,变异步成同步;

做了上述修改与实验之后,还是没有解决问题,所以可以断定问题出在第四步: 日志在传输过程中被篡改。

于是发邮件咨询相关的同事,得到的回答都是 没有问题的,很多业务都使用我们的服务,从来没出现过问题,你再找找原因吧。 ,没办法啊,气场不够,只能说声谢谢,然后继续自己摸索。

三天时间过去了,还是没能找到自己的原因,我真是快要奔溃了,于是在leader的陪同下亲自去找之前邮件沟通过的同事,大概聊了20分钟,最后对方突然说: 流量高峰期的时候,我们会将日志写到本地文件,随后再次读取的时候可能真的会有问题,巴拉巴拉一堆,说我们看看吧,一会儿给你们回邮件。

回来等了几分钟,收到邮件了: 这个确实是我们的一个bug,你们流量太大了,之前都没有遇到过,我们会尽快修复,到时候通知你们。

总结

  1. 程序员天生自信,当受到质疑时,第一反应就是:”我的程序肯定没问题”;
  2. 程序员最最重要的两个东西: 技术,名气 ,如果没有技术和名气,别人根本不把你当回事,遇到问题时都会认为是你自己的问题,所以,努力提升自己技术和影响力吧!

声明

正文到此结束
Loading...