大型分布式C++框架《三：序列化与反序列化》

时间 2019-11-11

原文原文链接

1、前言

　　　　我的感受序列化简单来讲就是按必定规则组包。反序列化就是按组包时的规则来接包。正常来讲。序列化不会很难。不会很复杂。由于过于复杂的序列化协议会致使较长的解析时间，这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。就像压缩文件、解压文件，会占用大量cpu时间。php

　　　　因此正常的序列化会在时间和空间上考虑。我的感受对于电商业务时间应该是相对重要些。毕竟用户没有那么多时间等你解析。

咱们是用thrift来序列化的。一份thrift文件生成2份。一份是c++生成的用来编写服务接口。一份是php生成的。全部请求都会先落到前端机器。而后前端机器用php调用服务端函数接口。返回处理结果。这实际上是远程调用rpc。

2、分配序列化空间的大小

说序列化以前先说下平台给序列化分配的buf的空间大小前端

一、每一个协程会分配大概固定包头（56个字节）+特殊buf（200个字节）的空间来保存包头。因此首先若是收到的包特殊buf（就是放sessionkey和uid等信息）大于200个字节。会报错不处理。可是并不会给netio 返回一个错误包消息。因此客户端会一直等到客户端设置的超时时间

二、每一个container会分配3M的空间来处理数据。因此去掉包头和特殊buf.剩下的就是能够用来序列化的空间 3*1024*1024-固定包头-特殊buf。因此最少会有 3*1024*1024-56-200的空间

这里其实能够看到协程的好处。这个3M的空间。对于每一个协程来讲是共享的。由于咱们是协程的方式，实际上是一种顺序流程,没有协程会跟你竞争使用这个buf的资源。由于能够本身手动控制协程的切换。

若是是多线程的话。可能就要对这个buf加锁。竞争这一个全局资源来处理数据。这也是多线程编程被诟病的一个地方，须要加锁。

3、序列化步骤

一、咱们先看下请求。

    oCntlInfo.setOperatorUin(10458);
    oCntlInfo.setOperatorKey("abcde");
    oCntlInfo.setRouteKey(1234);
 
    std::string source = "aaaaa";
    std::string inReserve;
    std::string errmsg;
    std::string outStr;
 
 
    std::string machineKey;
    for(int i =0;i<500*1024;i++)
    {
        machineKey.append("a");
    }
 
 
    AoActionInfo oActionInfo;
    oActionInfo.SetDisShopId(1111);
    oActionInfo.SetDistributorId(2222);
 
    uint32_t dwResult = Stub4App.AddActionSupplier(
                oCntlInfo,
                machineKey,
                source,
                1,
                1,
                oActionInfo,
                inReserve,
                errmsg,
                outStr);
    if(dwResult == 0)
    {
        std::cout << "Invoke OK!" << std::endl;
        std::cout << "Invoke OK!" << std::endl;
 
    }

客户端直接调用函数接口。到服务端请求结果c++

最后须要序列化的东西以下是类_Cao_action_AddActionSupplier_Req

函数的入参都是咱们须要序列化的内容。注意这里是rpc调用的一个关键点。编程

二、序列化开始

a) 先看下咱们的thritf服务器

若是下图。发现咱们的函数入参也是打上了tag标志的。做用跟咱们在结构体中打tag标志是同样的。为了标识一个字段的含义。session

序列化的时候把这些tag序列化进去。而后反序列化的时候靠这些tag来解析多线程

b ) 先把图贴出来。按着图来说更清晰些app

c) 首先咱们会建立一个CByteStream的类来。序列化内容。在CByteStream的构造函数会自动写入一个字节的序列化包头。值为1

CByteStream(char* pStreamBuf = NULL, uint32_t nBufLen = 0,bool bStore=true, bool bRealWrite = true);

pStreamBuf 是序列化buf指针

pStreamBuf 是序列化的长度

bStore true表示是否须要包数据存储下来。 false表示不须要把数据存下来

bRealWrite 表示是否支持读写buf

d) 接着就开始写类_Cao_action_AddActionSupplier_Req的成员变量。其实就是函数入参。写的时候是先协tag就是下图中的fid。其实就是在thrift中已经写好的函数入参的tag值。

具体写的过程咱们先看简单基本类型。好比strMachineKey

1）先写tag。 strMachineKey 的tag为1. 程序里规定tag占两个字节。因此函数入参能够是0xffff个。

2 ) 接着会写4个固定的字节。用来存储后面紧跟着数据的值。这里strMachineKey的长度是512000.

3 ) 写内容。把strMachineKey的内容写入紧跟着的buf

针对整形和长整形就不说了

大同小异

e) 接着咱们关注下是怎么写结构体oActionInfo的。

1）先写tag。 oActionInfo 的tag为5. 程序里规定tag占两个字节。

2 ) 接着针对结构体这里会写4个固定的字节用来存结构体序列化长度。由于开始不知道因此值为0。

3 ) 接着写字段 DistributorId。它在oActionInfo结构体中的tag值为6.类型为int64. 因此先写tag=6占两个字节，接着分配4个字节存长度。最后分配8个字节存内容

4）跟着写DisShopId字段。就不细说了

5）最后写了2个字节包尾

6）最后回写结构体的长度

这里注意下写结构体时候的写法。不注意的话会看错。

1）这里先拿到开始写结构体的buf指针。注意这里是用的int32_t。占四个字节。跟前面保持一直。这里用来的存后面总序列虚化结构体提的总长度。

2）因为刚开始的时候并不知道后面的结构体会序列化多少个字节。因此这里先写4个字节。

同时把这便宜的4个字节的内存值设置为0

bs<<0; （这里其实建议写成 bs<<int32_t（0）会好一点。开起来一致）

这里开始没注意。觉得写4个字节值为0的 结构体的头。其实这里是放结构体长度的

3）最后第5步。从新赋值结构体的长度

1）int32_t* pLen = (int32_t*)bs.getRawBufCur();
2）bs << 0;
3）int32_t iLen=bs.getWrittenLength();
4）Serialize_w(bs);
5）*pLen = bs.getWrittenLength() - iLen;

f）最后对整个_Cao_action_AddActionSupplier_Req写了两个字节的包尾函数

g) 我么能够看到oActionInfo其实有一堆的字段。可是咱们在请求的时候只写了两个字段。全部在序列化的时候也只序列化了两个字段

其实咱们能够看到咱们的这种序列化,很整齐。很规则。比较紧凑。可是并不节省空间。这个里面有不少数据能够压缩的。可是压缩带来一个问题就是解压的时候很消耗cpu的。跟个人业务场景不服和。也不必。ui

4、序列化解析

其实知道了数据是怎么写入的解析起来就很容易了。其实这种序列化就是两边约定规则。知道规则之后就能够解析了
解析的具体步骤就不详细说了。这里说下解析的时候几个特殊的地方

一、由于tag占2个字节。因此函数入参不能大于0xffff. 一个结构体的字段个数不能大于0xffff

二、假如前端传入的tag在解析端找不到。解析端会偏移处理下一个tag。因此这是为何咱们能够删除字段的缘由。

好比前端传入的结构以下

struct A{

1:int aa

2:int bb

}

可是服务端后台编译后删除了一个字段

struct A{

1:int aa

}

a)若是前端只填了字段aa。那么解析起来没有任何问题.由于不会把字段bb的任何信息序列化进去。

b)假如前端填了 aa 和 bb字段。

那么服务端在解析的时候。拿到tag2。发现找不到对应的数据。

那么它会偏移4个字节取tag2对应字段内容所占的字节数。好比这里是4.

接着它发现是4.就偏移4个字节。不处理字段值内容。直接取下一个tag进行处理

这也就是咱们为何能删除字段的缘由。

这样看来咱们的函数入参其实也是能够删除的

三、咱们服务端新增字段从新编译。前端没有对应的tag。根本不会序列化进来。这也是咱们能够增长字段的缘由。

四、解析的时候若是发现tag为0.则会是认为解析结束。因此咱们的tag是不能为0的

五、这样咱们也就能为服务端函数增长入参的。同一个函数好比前端的入参是4个。服务端能够增长N个. 可是注意不能占用函数已经用的tag。不然会有问题。并且为了保证函数的统一性。最好别这么作。

六、到这里已经很清晰了。最后再说一次不能改tag对应的类型。

5、话外

咱们的这一套就是远程调用rpc服务。经过咱们的序列化。

其实就能了解所谓的RPC服务是什么样的。

说白了，远程调用就是将对象名、函数名、参数等传递给远程服务器，服务器将处理结果返回给客户端。

为了能解析出这些信息。在入参的时候作上标识(这里是打tag).

谷歌的protobuf也用过。跟thrift其实差很少可是序列化和反序列的话的具体实现是有些不一样的。

谷歌的protobuf更节省空间

之前具体看过序列化的源码。以为序列化反序列化以及rpc很神秘。如今看了源码才发现确实写的确实好，

可是没那么神秘里。其实就是按必定规则组包。因此仍是要多看源码啊。

咱们用的thrift就是 facebook的thrift。可是改了些东西。大致是同样的。