C++右值引用和移动语义

传统方式

对于一般的网络编程乃至分布式应用或者微服务架构中，各个服务之间的数据通信是少不了的，比如服务端和客户端想要传递一个User的数据结构，通常情况下，我们会先定义一个结构体：

struct User{
    int id;
    string name;
    /*...*/
}

考虑到各个服务的实现和字节序的问题，发送方还要把这个结构体序列化成字节流，接收方收到字节流以后要按和发送方约定好的格式进行反序列化，至此一个网络数据包的发送接收流程才算结束。

但是，这种方式最致命的一个问题就是不灵活。由于结构体是预先定义好并且硬编码到程序中的，如果消息的发送方想要增加或者删除其中一个字段，那对于该类型数据的所有接收方来说都是灾难性的，因为每个接收程序都要进行相应改动，这往往是我们无法接受的。

json和xml

于是，我们常常使用诸如json、xml这种可变的编码方式来作为服务间消息传递的载体。同样对于User数据，一个json可能是这样的

{
    "id":10,
    "name":"simon"
}

如果想要增加一个字段变成：

{
    "id":10,
    "name":"simon",
    "tel":123456
}

下游服务依然可以正常解析id和name字段，不会受到影响。

json相对于字节流，因为增加了一个key，所以最明显的缺点是

数据包变大了
也增加了发送方和接收方的序列化/反序列化时间

上面两点往往是常见的性能瓶颈。下面我们来探讨如何针对这两点进行改进：

如何更小

对于前面的那条json数据

{
    "id":10,
    "name":"simon",
    "tel":123456
}

中间有很多冗余的字符，比如{，"等，为了把数据变小一点，我们可以暴力一点，直接表示为：

|  10  | simon | 123456 |

通过直接将value拼在了一起，舍去了不必要的冗余字符，我们大幅度的压缩了空间，但是会有一些问题，就是当我们将这段数据发送给接收端，接收端怎么知道每个value对应哪个key呢？比如simon这个值，对应的是age还是name呢？

比较好的方式是事先跟接收端约定好有哪些字段，顺序是啥样子的，然后接收端按照顺序对应起来：

字段1：id	字段2：name	字段3： tel
10	simon	123456

很完美，这样我们确实压缩了不少数据，棒棒的。

能不能更小一点呢？

假设name这个字段为null，我们其实是不必要传递这个字段的，这个时候我们需要传递的数据就为：

字段1：id	字段3： tel
10	123456

但是在接收端，解析数据并按照顺序进行字段匹配的时候就会出问题：

字段1：id	字段2：name	字段3： tel
10	123456

显然已经乱套了，为了保证能够正确的配对，我们可以使用tag技术：

tag|10	tag|simon	tag|123456

也就是说，每个字段我们都用tag|value的方式来存储的，在tag当中记录两种信息，一个是value对应的字段的编号，另一个是value的数据类型（比如是整形还是字符串等），因为tag中有字段编号信息，所以即使没有传递height字段的value值，根据编号也能正确的配对。

tag的开销

有的同学会问，使用tag的话，会增加额外的空间，这跟json的key/value有什么区别吗？

这个问题问的好，json中的key是字符串，每个字符就会占据一个字节，所以像name这个key就会占据4个字节，但在protobuf中，tag使用二进制进行存储，一般只会占据一个字节，它的代码为：

static int makeTag(final int fieldNumber, final int wireType) {
  return (fieldNumber << 3) | wireType;
}

fieldNumber表示后面的value所对应的字段的编号是多少，比如fieldNumber为1，就表示age，如果为2，就表示name等；wireType表示value的数据类型，以此来计算value占用字节的大小

在protobuf当中，wireType可以支持的字段类型如下：

Type	Meaning	Used For
0	Varint	int32, int64, uint32, uint64, sint32, sint64, bool, enum
1	64-bit	fixed64, sfixed64, double
2	Length-delimited	string, bytes, embedded messages, packed repeated fields
3	Start group	groups (deprecated)
4	End group	groups (deprecated)
5	32-bit	fixed32, sfixed32, float

因为tag一般占用一个字节，开销还算是比较小的，所以protobuf整体的存储空间占用还是相对小了很多的。

其次，在实际的传输过程中protobuf会对整数进行压缩。

我们知道整数在计算机当中占据4个字节，但是绝大部分的整数，比如价格，库存等，都是比较小的整数，实际用不了4个字节，像127这种数，在计算机中的二进制是： 00000000 00000000 00000000 01111111（4字节32位）完全可以用最后1个字节来进行存储，protobuf当中定义了Varint这种数据类型，可以以不同的长度来存储整数，将数据进一步的进行了压缩。

但是这里面也有一个问题，在计算机当中的负数是用补码表示的，对于-1，它的二进制表示方式为： 11111111 11111111 11111111 11111111（4字节32位）显然无法用1个字节来表示了，但-1确实是一个比较简单的数，这个时候就可以使用zigzag算法来对负数进行进一步的压缩，最终我们可以使用2个字节来表示-1。

如何更快

虽然数据现在很小了，但是解析速度还是有很大的提升空间的，因为每个字段都是用tag|value来表示的，在tag中含有value的数据类型的信息，而不同的数据类型有不同的大小，比如如果value是bool型，我们就知道肯定占了一个字节，程序从tag后面直接读一个字节就可以解析出value，非常快，而json则需要进行字符串解析才可以办到。

如果value是字符串类型的，具体value有多长，我们无法从tag当中了解到，但是如果不知道value的长度，我们就不得不做字符串匹配操作，要知道字符串匹配是非常耗时的。

为了能够快速解析字符串类型的数据，protobuf在存储的时候，做了特殊的处理，分成了三部分：tag|leg|value，其中的leg记录了字符串的长度，同样使用了varint来存储，一般一个字节就能搞定，然后程序从leg后截取leg个字节的数据作为value，解析速度非常快。

C++右值引用和移动语义