程序員最重要的兩個東西

先來介紹整個服務的數據流示意圖，如下：

1. 每臺服務器都會部署一個scribe-agent，用于將本機產生的日志發送到遠端的scribe-server；
2. scribe-server將收集的日志分別打印到HDFS和kafka。
</ol>

然后我這邊有一個服務去消費kafka的數據，做一些數據分析。

發現問題

服務跑了一天多，我從公司內部的監控平臺上發現，我的服務（消費kafka的服務）在每一個日志高峰期都會出現大量的thrift結構反序列化失敗的異常。

解決問題

發現問題之后我有幾個可以懷疑的地方：

1. 打印日志的服務和消費日志的服務使用的thrift版本不一致，導致序列化失敗（我的問題）；
2. 日志序列化或者反序列化的時候有多線程安全問題，導致數據被打亂(我的問題)；
3. 由于消費kafka過程中使用了disruptor框架做異步處理，懷疑disruptor有bug；
4. 日志在傳輸過程中被篡改（不是我的問題）；
</ol>

其中第三點可以細分為以下幾個可能：

1. scribe-agent寫日志到scribe-server有bug（scribe-agent是其他team同事負責的）
2. scribe-server將日志寫到kafka有bug（其他team同事負責的）
</ol>

一般來說，排查問題都應該從自身問題找起，所以首先來證明自己的清白：

1. 通過MD5檢查寫日志的服務和分析日志的服務使用的thrift是同一個版本；
2. google了一下，我使用的序列化和反序列化應該沒問題，并且我們主業務也是使用相同的方法；
3. 將disruptor的ringBuffer大小設置為0，變異步成同步；
</ol>

做了上述修改與實驗之后，還是沒有解決問題，所以可以斷定問題出在第四步： 日志在傳輸過程中被篡改。

于是發郵件咨詢相關的同事，得到的回答都是 沒有問題的，很多業務都使用我們的服務，從來沒出現過問題，你再找找原因吧。 ，沒辦法啊，氣場不夠，只能說聲謝謝，然后繼續自己摸索。

三天時間過去了，還是沒能找到自己的原因，我真是快要奔潰了，于是在leader的陪同下親自去找之前郵件溝通過的同事，大概聊了20分鐘，最后對方突然說： 流量高峰期的時候，我們會將日志寫到本地文件，隨后再次讀取的時候可能真的會有問題，巴拉巴拉一堆，說我們看看吧，一會兒給你們回郵件。

回來等了幾分鐘，收到郵件了： 這個確實是我們的一個bug，你們流量太大了，之前都沒有遇到過，我們會盡快修復，到時候通知你們。

總結

1. 程序員天生自信，當受到質疑時，第一反應就是：”我的程序肯定沒問題”；
2. 程序員最最重要的兩個東西： 技術，名氣 ，如果沒有技術和名氣，別人根本不把你當回事，遇到問題時都會認為是你自己的問題，所以，努力提升自己技術和影響力吧！
</ol> 本文鏈接：http://qifuguang.me/2015/11/13/程序員最重要的兩個東西/
 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
  本文地址：http://www.baiduhome.net/news/view/1c76293
程序員