认识达内从这里开始

压缩是我们在做性能优化的时候都会经常用到的一个优化方法，今天我们就通过案例分析来简单了解一下，压缩对性能优化的优势都有哪些。

压缩的原理消耗计算的时间，换一种更紧凑的编码方式来表示数据。

为什么要拿时间换空间?时间不是宝贵的资源吗?

举一个视频网站的例子，如果不对视频做任何压缩编码，因为带宽有限，巨大的数据量在网络传输的耗时会比编码压缩的耗时多得多。对数据的压缩虽然消耗了时间来换取更小的空间存储，但更小的存储空间会在另一个维度带来更大的时间收益。

这个例子本质上是："操作系统内核与网络设备处理负担vs压缩解压的CPU/GPU负担"的权衡和取舍。

我们在代码中通常用的是无损压缩，比如下面这些场景:

HTTP协议中Accept-Encoding添加Gzip/deflate，服务端对接受压缩的文本(JS/CSS/HTML)请求做压缩，大部分图片格式本身已经是压缩的无需压缩;

HTTP2协议的头部HPACK压缩;

JS/CSS文件的混淆和压缩(Uglify/Minify);

一些RPC协议和消息队列传输的消息中，采用二进制编码和压缩(Gzip、Snappy、LZ4等等);

缓存服务存过大的数据，通常也会事先压缩一下再存，取的时候解压;

一些大文件的存储，或者不常用的历史数据存储，采用更高压缩比的算法存储;

JVM的对象指针压缩，JVM在32G以下的堆内存情况下默认开启"UseCompressedOops"，用4个byte就可以表示一个对象的指针，这也是JVM尽量不要把堆内存设置到32G以上的原因;

MongoDB的二进制存储的BSON相对于纯文本的JSON也是一种压缩，或者说更紧凑的编码。但更紧凑的编码也意味着更差的可读性，这一点也是需要取舍的。纯文本的JSON比二进制编码要更占存储空间但却是RESTAPI的主流，因为数据交换的场景下的可读性是非常重要的。

信息论告诉我们，无损压缩的极限是信息熵。进一步减小体积只能以损失部分信息为代价，也就是有损压缩。

那么，有损压缩有哪些应用呢?

预览和缩略图，低速网络下视频降帧、降清晰度，都是对信息的有损压缩;

音视频等多媒体数据的采样和编码大多是有损的，比如MP3是利用傅里叶变换，有损地存储音频文件;jpeg等图片编码也是有损的。虽然有像WAV/PCM这类无损的音频编码方式，但多媒体数据的采样本身就是有损的，相当于只截取了真实世界的极小一部分数据;

散列化，比如K-V存储时Key过长，先对Key执行一次"傻"系列(SHA-1、SHA-256)哈希算法变成固定长度的短Key。另外，散列化在文件和数据验证(MD5、CRC、HMAC)场景用的也非常多，无需耗费大量算力对比完整的数据。

除了有损/无损压缩，但还有一个办法，就是压缩的极端——从根本上减少数据或彻底删除。

能减少的就减少：

JS打包过程"摇树"，去掉没有使用的文件、函数、变量;

开启HTTP/2和高版本的TLS，减少了RoundTrip，节省了TCP连接，自带大量性能优化;

减少不必要的信息，比如Cookie的数量，去掉不必要的HTTP请求头;

更新采用增量更新，比如HTTP的PATCH，只传输变化的属性而不是整条数据;

缩短单行日志的长度、缩短URL、在具有可读性情况下用短的属性名等等;

使用位图和位操作，用风骚的位操作小化存取的数据。的例子有：用Redis的位图来记录统计海量用户登录状态;布隆过滤器用位图排除不可能存在的数据;大量开关型的设置的存储等等。

能删除的就删除：

删掉不用的数据;

删掉不用的索引;

删掉不该打的日志;

删掉不必要的通信代码，不去发不必要的HTTP、RPC请求或调用，轮询改发布订阅;

终极方案：砍掉整个功能。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。