前言
最近遇到了一个HTTP请求返回一个gz压缩包的问题,前前后后搞了3天,总算是把整个流程以及处理的细节搞明白了,总结一篇博客记录分享一下。
问题描述几解决方案
流量方的优化
获取某推广告成效数据的时候由于数据量很多,可能会导致Response数据量过大从而造成请求失败的问题。
某推服务方设计了这样一种方式:先将请求的到的数据写入到一个json文件中,然后将这个json文件使用gzip压缩(经过实际测试,一个100多k大小的json文件使用gzip压缩后只有十几k的大小,并且gzip压缩后是不保留原文件的)。
最终服务端存的是一个压缩后的gz文件,然后返回给用户端一个链接,用户根据这个链接去“下载”压缩后的数据文件,大大减少了网络带宽的占用!
比如我们可以通过下面这个链接下载成效数据:成效数据链接
也就是说,与我们平时处理的请求不同的是,现在这种情况下发送GET请求得到的是一个gz文件的数据流。
解决思路
其实解决问题的思路有2个:一个是根据gz数据流将gz文件写入到本地,然后在本地解压这个文件,读取解压后的文件;另外一种思路是直接根据gz数据流将json文件解压到本地,省去了中间在本地生成gz压缩文件的过程!
一目了然:在上面描述的业务场景中,肯定是第二种解决方案最优!
优化的三方包
从网上找了一个包去处理文件解压缩的问题,但是其源码本身有一些问题,略微修改了一下其源码后便可使用了。
最终修改后的项目地址请访问:Unpackit
原文件存在的问题可以看README的描述。
解决问题的demo
自己写了一个demo专门用来展示两种解决方案的实现过程。
麻雀虽小,五脏俱全,这个demo用到了自定制错误、http的连接池,以及go中常用的错误返回机制。
项目地址如下,欢迎star:https://gitee.com/huoyingwhw/unpackit-demo
细节记录
关于一些解决问题中间的细节请查看笔者另外2篇博客: