1 概览

由于独立于应用系统，分布式缓存的本质就是将所有的业务数据对象序列化为字节数组，然后保存到自己的内存中。所使用的序列化方案也自然会成为影响系统性能的关键点之一。一般来说，我们对一个序列化框架的关注主要有以下几点：

1. 序列化速度：即对一个普通对象，将其从内存对象转换为字节数组需要多长时间；这个当然是越快越好
2. 对象压缩比：即序列化后生成对象的与原内存对象的体积比
3. 支持的数据类型范围：序列化框架都支持什么样的数据结构；对于大部分的序列化框架来说，都会支持普通的对象类型，但是对于复杂对象（比如说多继承关系、交叉引用、集合类等）可能不支持或支持的不够好
4. 易用性：一个好的序列化框架必须也是使用方便的，不需要用户做太多的依赖或者额外配置

对于一个序列化框架来说，以上几个特性很难都做到很出色，这是一个鱼和熊掌不可兼得的东西（具体原因后面会介绍），但是终归有自己的优势和特长，需要使用者根据实际场景仔细考量。下面就针对目前主流的序列化框架：Java、Hessian、ProtoBuf、Kryo分别从速度、压缩比、支持对象类型和易用性几方面分别讨论。

2 压缩比对比

单位：字节

3 序列化速度对比

单位：纳秒

4 支持对象类型与易用性对比

4.1 Java源生序列化

ava源生序列化是JDK自带的对象序列化方式，也是我们最常用的一种；其优点是简单、方便，不需要额外的依赖而且大部分三方系统或框架都支持；目前看来，Java源生序列化的兼容性也是最好的，可支持任何实现了Serializable接口的对象（包括多继承、循环引用、集合类等等）。但随之而来不可避免的就是，其序列化的速度和生成的对象体积和其他序列化框架相比，几乎都是最差的

4.2 Hessian

Hessian的序列化实现和Java的原生序列化很相似，只是对于序列化反序列化本身并不需要的一些元数据进行了删减；所以Hessian可以像Java的源生序列化那样，可以支持任意类型的对象；但是在存储上，Hessian并没有做相应的优化，所以其生成的对象体积相较于Java的源生序列化并没有下降太多。由于Hessian相较于Java源生序列化并没有太大的优势，所以一般情况下，如果系统中没有使用Hessian的rpc框架，则很少单独使用Hessian的序列化机制。

4.3 Google Protobuf

GPB最大的特点就是自己定义了一套自己数据类型，并且规定只允许用我的这套；所以在使用GPB的时候，我们不得不为它单独定义一个描述文件，或者叫schema文件，用来完成Java对象中的基本数据类型和GPB自己定义的类型之间的一个映射。不过也正是GPB对类型的自定义，也让他可以更好的针对这些类型做出存储和解析上的优化，从而避免了Java源生序列化中的诸多弱点。对于对象属性，GPB并没有直接存储属性名称，而是根据schema文件中的映射关系，只保存该属性的顺序id；而对于，GPB针对常用的几种数据类型采用了不同程度的压缩，同时属性区段之间采用特定标记进行分隔，这样可以大大减少存储所占用的空间。对于数值类型，常见的压缩方式有变长byte、分组byte、差值存储等，一般都是根据属性的使用特点来做定制化的压缩策略。GPB的另一个优点就是跨语言，支持Java、C、PHP、Python等目前比较大众的语言；其他类似的还有Facebook的Thrift，也需要描述文件的支持，同时也包含了一个rpc框架和更丰富的语言支持

4.4 Kryo

前面我们提到，诸如Hessian和GPB这些三方的序列化框架或多或少的都对Java原生序列化机制做出了一些改进；而对于Kryo来说，改进无疑是更彻底一些；在很多评测中，Kryo的数据都是遥遥领先的；Kryo的处理和Google Protobuf类似。但有一点需要说明的是，Kryo在做序列化时，也没有记录属性的名称，而是给每个属性分配了一个id，但是他却并没有GPB那样通过一个schema文件去做id和属性的一个映射描述，所以一旦我们修改了对象的属性信息，比如说新增了一个字段，那么Kryo进行反序列化时就可能发生属性值错乱甚至是反序列化失败的情况；而且由于Kryo没有序列化属性名称的描述信息，所以序列化/反序列化之前，需要先将要处理的类在Kryo中进行注册，这一操作在首次序列化时也会消耗一定的性能。另外需要提一下的就是目前kryo目前还只支持Java语言。

参考

1. https://www.cnblogs.com/siqi/p/5096317.html