在正式切入今天要談的優化之前，先碎碎念一些自己過去這幾年的經歷。很久沒有登錄過博客園了，今天也是偶然興起打開上來看一下，翻看了下自己的隨筆，最后一篇原創文章發布時間是2015年的4月，今天是2017年的6月10號，真是離開了博客園有兩年之久了。
2014年6月畢業后開始了北漂生活，在百度2年時間，主要從事百度Hi服務端的研發工作。在百度算是第一次對整個項目的開發有了相對完善的了解，同時也從一個新人逐步的成長，踩了一些坑，長了一些見識。2016年6月離開百度，回到成都，主要是考慮在成都安家，同時老婆也懷孕了，家里很快就要迎來兩個小朋友。正好成都螞蟻金服團隊在招人，通過幾次面試然后順利的加入到了螞蟻金服人工智能團隊。
加入螞蟻一晃過去了一年時間了，現在還記得入職當天就出差時我一臉懵逼的狀態。到螞蟻之后，最大的改變就是團隊不再把我當做一個新人來培養，沒有人來指導你改怎么樣做，我收到的就是一個需求，至於這個需求怎么做，我可以隨意發揮，當然前提是要做好。總結為一句話，就是以結果為導向，你可以做的很完美，也可以做的很low，但只要項目符合預期，並取得了該有的成效那你就沒有失職。當然懵逼歸懵逼，任務可不會等你的，根本就沒有時間給我去適應，然后就開始卷入各種任務中。現在回想起來，入職那段時間我效率也是最高的，當然壓力也大。
好了，閑話不多說，談談今天我要說的話題：pb傳輸優化淺談。在最近螞蟻的工作中，遇到一個性能優化的問題，兩個系統之間通過pb形式傳輸數據，考慮到數據量比較大（單次請求包大約2M左右），原有的pb傳輸性能不符合業務預期。那么，該怎么優化來提升這個性能呢？
首先我們需要分析主要的耗時在那個環節？我們對該調用鏈路進行簡單的梳理：
客戶端將請求對象序列化為pb--網絡IO--服務反序列化對象--業務計算--計算結果序列化--網絡IO--客戶端對響應反序列化
對整個流程中的分階段耗時進行統計分析，發現目前主要的耗時在序列化的過程，也就是說目前的pb序列化性能不符合預期！怎么優化呢？序列化的過程是cpu密集型的，既然pb序列化無法滿足，那我們就尋求性能更好的序列化方式，這里我們選擇了flat buffer。
pb和fb各有裨益，在內存空間占用這個指標上，flat buffers占用的內存空間比protobuf多了兩倍。序列化時二者的cpu計算時間fb比pb快，當然反序列化時二者的cpu計算時間fb比pb也要快。即fb在計算時間上占優勢，而pb則在內存空間上占優。
看似問題解決了，然而未必！序列化、反序列化的性能提升了，傳輸的數據包變大了。那就繼續優化唄，包大了怎么破？壓縮~
壓縮方法比較多，GZIP、LZO、Zippy/Snappy壓縮等方法眾多，我們需要選擇適合我們的那一款。這幾款壓縮也是hbase中應用的幾種壓縮方式。我們對其特點做一個分析，其中：
1）GZIP的壓縮率最高，但是其是CPU密集型的，對CPU的消耗比其他算法要多，壓縮和解壓速度也慢；
2）LZO的壓縮率居中，比GZIP要低一些，但是壓縮和解壓速度明顯要比GZIP快很多，其中解壓速度快的更多；
3）Zippy/Snappy的壓縮率最低，而壓縮和解壓速度要稍微比LZO要快一些。
BigTable中采用的是Zippy算法，目標是達到盡可能快的壓縮和解壓速度，同時減少對CPU的消耗。我們目前的需求和這個也是類似的，所以我們通過實現最終選定了使用snappy壓縮方式。
好了，今天的淺談內容結束，期待后續自己能夠多有一些時間出來，將有關項目中遇到的一些點和大家分享，也期望能夠幫到大家，謝謝！