在正式切入今天要谈的优化之前，先碎碎念一些自己过去这几年的经历。很久没有登录过博客园了，今天也是偶然兴起打开上来看一下，翻看了下自己的随笔，最后一篇原创文章发布时间是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压缩方式。
好了，今天的浅谈内容结束，期待后续自己能够多有一些出来，有关项目中遇到的一些点和大家分享，也期望能够帮到大家，谢谢！