《数据密集型应用系统设计》读书笔记①：数据序列化及常用序列化协议

首先还是安利时间：写文时的歌单是
君に最後の口づけを
IxU
时间煮雨
我好想你
花に亡霊
あの夢をなぞって
たぶん
群青

1.数据序列化的意义及必要性

  在开发中时长会遇到需要进行跨进程进行数据传输，或者将数据持久化存储到磁盘或别的什么介质中，而数据在传输或存储前需要进行序列化的过程。
  那么，为什么需要这个序列化的过程呢？它的意义是什么呢？
  有些小伙伴可能会不理解，为什么不能直接把数据在内存中拿出来直接拿去进行传输或者存储呢？
  虽然数据都是存在于内存中这一点是没有问题的，但对于使用了不同编程语言而开发出来的程序来说，它们会在底层为了高效利用内存与CPU而进行不同的优化，通常来说它们都是指针变种或者升级版，所以对于一个对象来说，它对用户所表现出来的外观与它在内存中的里相是不一样的，举例来说，假如说有一个Object A，
它表现出来的外观是这样的：
{
  int a = 10;
  long b = 9527;
  String s = "铃木爱理是我老婆";
  char[] carr = [新,垣,结,衣,也,是,我,老,婆];
  Object B:{
    int innerA = 10086;
    long innerB = 1020;
  }
}
但实际上它在内存里是这样的：
{
  int a = 10;(基础数据类型是被直接包着的)
  long b = 9527;
  String b -> 2134565（指向字符串对象地址的指针，数字是我乱写的）
  int[] b -> 689461（指向int数组第0个元素所在地址的指针）
  Object B -> 98463165（指向ObjectB这个对象的指针）
}
所以如果你未经任何处理，直接将ObjectA从内存中复制出来，那么对方最终可能只能接收到一堆无法识别的奇葩数字。

  所以大概可以将序列化的过程简单地理解为【将不同编程语言为了优化而魔改后的内存中的数据，转换为可通过某种方法完整还原会内存中的，用于跨进程传输或持久化存储的数据格式】，而这种序列化的方法必须是在某种意义上通用的，与编程语言无关的。

2.常用的序列化格式

①目前互联网比较流行的XML与JSON

  比较老资格的有XML，以前在银行里的时候也是经常与XML报文打交道。
  JSON是最近几年开始流行起来的，似乎是因为大家嫌弃XML冗余体积比较多，浪费了太多网络带宽，于是乎JSON出来了，体积更小。
  这两种格式都是具有很不错的可读性的，受过训练的人类（指程序猿）也能轻易肉眼读取，并且兼容性也不错，因为大部分JSON和XML的序列化工具都是根据报文中的变量名进行1对1识别，因此除非是因为业务大规模变更而导致必填项发生变化，不然单纯对于实体转换来说具有很好的向前/向后的兼容性。

  但是使用它们也有需要注意的问题：
  数字编码模糊。由于这两种序列化格式中仅有变量名作为标识，因此如果发送方与接收方所定义的实体/数据结构中的数字类型不一致——比如说同为变量a，发送方是double，接收方是int，或者字符串，或者说是所指定的精度不一致的double——这种情况中接收方反序列化时会产生问题

②二进制变种而来的序列化方式

  有部分开发者可能是为了获得更高的传输效率，节省带宽，而会选择更紧凑或更快的解析格式。但这些方式一般偏小众，难以在市场上普及，因此仅作为组织内小范围应用。

目前比较有名的二进制方式有facebook开源的apache thrift和google开源的protocol buffers，以及apache avro。其中apache avro的压缩率是最高的。这两种方式应用起来相对更复杂点（因为需要配置实体信息等各种）

3.模式演化与兼容

  由于市场的发展与业务的变化，所以数据模式总是在发生变化，而对于开发者来说可能不是每一次都会兼顾去把所有的老程序进行升级，因此考虑向前/向后兼容是有必要的。
  对于序列化工具指导兼容性实现的方式有reader模式，writer模式，数据流模式（好像对我来说没什么卵用，随便记下来算了）。

神驱一梦
2020.11.15