大型分布式C++框架《四：netio之buffer管理器 下》

原帖:http://www.cnblogs.com/ztteng/p/5428825.html

　每周一篇又来了。这次主要介绍netio的buffer管理器。 首先buffer管理是每一个网络层不可回避的问题。怎么高效的使用buffer是很关键的问题。这里主要介绍下我们的netio是怎么处理。说实话 这是我见过比较蛋疼buffer管理。  反正我是看了好几天 才看明白的。

     最近看了下Qcon2016的视频.里面很多大牛介绍分布式平台。 感觉特别牛逼~~。 感觉我们的分布式相比他们的这些还是简陋了点。感兴趣的同学可以去看看

     http://daxue.qq.com/content/special/id/20

 

 

1.1  我们先看下 一次系统调用recv就能收到完整包的情况

1）首先通过系统调用函数recv  会每次把从TCP读到的数据放到

 

m_achRecvBuf[TPT_RECV_BUF_LEN];

这个buf大小为128*1024

2、判断包头。

先判断是否是0x5a5a

然后解析包头判断 需要发送过来的总长度  如果大于1024*1024就报错。

1024*1024是在初始化的时候申请的大小。 我们的一个最大请求包已经限定为1M

 

如果发现tcp一次就能收到完整的包。

netio并不会使用我们字节的buf管理器。

m_pSink->OnRecv而是直接丢给netio的app类去处理。

然后等netio中app类对包做了具体的处理后。

网络层 发现处理完以后就会直接  重新跳到while 循环中等待新事件

 

int CNetHandleMng::_RetrievePkgData(int nHandle,char* pRcvBuf,int nBufLen){    ......    //当前数据包已经读取完成    m_pSink->OnRecv(nHandle,pRcvBuf+TPT_HEAD_LEN,dwPkgLen);    return (dwPkgLen + TPT_HEAD_LEN);}

int CNetHandleMng::OnRecv(int nHandle,char* pRcvBuf,int nBufLen){    stConn* pConn = _GetConn(nHandle);    if( NULL == pConn )    {        std::stringstream oss;        oss<<"reactor report recv data for connection handle"<<nHandle<<" but we cann't found the connection data"<<std::endl;        m_pSink->ReportTptError(__FILE__,__LINE__,__func__,oss.str().c_str());        return 0;    }     int nReadLen =0;    if( 0 == pConn->m_pRcvBuf->m_nDataLen )    {         nReadLen = _RetrievePkgsData(nHandle,pRcvBuf,nBufLen);        if( nReadLen < 0 )            return nReadLen;//reactor层会自动关闭连接              if( nReadLen >= nBufLen )            return 0;//数据已经处理完毕        .....     } 

我们发现在一次recv能收完整个数据包的时候。平台没用字节的buf管理器。而是直接就给netio app类来处理了

 

1.2  我们先看下 一次系统调用recv收不完包的情况。

5.2.1  我们先分析下一个具体的例子 然后再慢慢的归纳和总结

a)为什么是256个指针?

初始化的时候  

CNetioApp::CNetioApp():CNetMsgqSvr(4096*5,1024*1024,4*1024)

规定了一个最大请求包是 1024*1024

buffer管理器中 最小的一个buf大小是4*1024

 

(1024*1024+4*1024 -1 ) / （1024*4）  = 256

然后分配256个大小的二维指针。

所以初始化的时候  会设置一个大小为256的二维指针。注意这里只是创建二维指针。当时并没有给每个指针指向的对象分配空间。

 

b) 当客户端首次connet的时候。会继续初始化一些信息

当客户端connet请求来临时候。会去buffer管理器取一块buffer。

默认情况下。都是取p[0]里的buffer。  

当buffer管理器 发现p[0]为空的时候。  会去创建10个buffer 。这里10是写死的。 由于是p[0]是第一行。那么每个buffer的大小是4096.

 

这10个buffer 是一个链表。 index=0是最先创建的。index=9是最后创建的。

 

如上图。 index=9被拿出去了 。但其实这个时候并没有数据过来。

这个不管。被connet信息结构体指向的buffer。我们都认为是在使用中。

这个时候p[0] 就会跳到index=8.

注意 二维指针  永远是指向未被使用的buffer。这很重要。如果没有空间。会继续创建buffer

 

 

c) 第一次recv   16384数据

这里发现收到的16384个字节 大于4096个字节。

则buffer管理器。会在p[3] 这里申请10个buffer块。

每块  1024*4*4=16384  刚好 放下recv的16384数据

 

因为不用p[0]的buffer块。 则先回退p[0]的指向。从index=8  到index=9

然后让connet信息块 重新指向p[3]的index=9

前面说了 二维指针一定要指向未被使用的buffer。  所有p[3] 指向index=8

 

同时在m_nDatalen里面记录 已经保存的字节数

 

这个时候还没有收完 需要继续收数据

 

 

d) 第二次recv   16384数据

注意 第二次也收到了16384.

那么第二次的16384  +  上次的16384 = 32768 

这个时候p[3] 这一列的buffer放不下。  需要重新创建buffer

 

这个时候在p[7] 这一列上创建   4*1024*8 =32768  刚好放下所有数据

这个时候在p[7] 创建10个buffer 。 每个buffer为4*1024*8

 

接着还是要归还p[3]  buffer的使用权。这个时候吧p[3]的指针指向index = 9  同时把 index=9里面的m_nDatalen设置为0.

这样就表示p[3]的index=9被 释放了。  但是其实index=9还是有内容的并没有清除。

 

接着我们把累加的数据 放到p[7]的index=9里面

 

 

e)

 后面都是类似的逻辑。 归还空间。然后申请新空间

我看总共131158个字节的内容  recv  6次。

buffer管理器 替换了包括最开始初始化的的buffer总共花了7次 才找到合适的buffer来存放内容

p[32] 的buffer大小 为4*1024*33=135168

 

1.2.2 .  正常情况下的buffer总大小

 

        在netio包了一段时间后。假如各种包的大小都存在。那么最后会怎么样~~。

        这256个指针  都会被创建buffer。 没一列的buffer大小是 4*1024*行数。比如第一行就是4*1024*1.

最后一行就是4*1024*256.

        而且被创建的buffer不会被释放。我们来计算下这个总的buffer会多大。

        4*1024*(1+2+3...+256)=134742016 134742016 1048576

       134742016 / (1024 * 1024) = 128 M  

        大概128兆。但是 这只是并发请求不高的情况下。我们来看下并发请求高的情况下会怎么样

 

1.2.3 .  高并发场景下 buffer的总大小

我们假设并发来了20个请求。为了使分析简单。我们就认为。每个请求数据都在4*1024以内。

如下图  用户p[0]的10个buffer以后。

p[0] 这个时候是指向了NULL的。

但是这个时候还有请求该怎么帮。

继续分配

这个时候再分配 10个buffer

 

如下图  又重新分配了10个buffer。 跟在0的后面。 在来的请求就是在后面的10个buffer中分配。

代码中是 每次网络层向buffer管理器申请buffer的时候。

会去查看 二维指针是否为空。不为空则把空间给出来存数据。

如果为空。则会申请10个内存

 

所有看到这。当并发请求很大的时候。这个buffer会突增大到一个很恐怖的数字。

而且由于 创建后的空间不会被删除。会一直维持一个很高的内存占用

 

 

1.2.4  buffer的释放。

我们以下图为例子。

请求 7、4、8 先后是否空间。

那么p[0] 先是指向 index=3  然后指向index=6  最后指向index=2

 

那么p[0] 指向的其实是  没有被使用的空间的  链表头。  

p[0]  ->index2->index6->index3

 

下次又有新请求来的时候。 则把index2分配给新请求使用

 

 

总结下：

1)netio的buffer初看还是很麻烦的。看了2、3天才看明白。主要是实现的思想还是有点复杂。但是个人感觉看下来并没有什么特别惊艳的地方。实现上感觉有点像google的tcmall。

2)申请不释放的好处就是不会产生大量内存碎片。

3)但是高并发场景下回内存爆增。且不会下去。

4)还有针对一个大包。需要多次recv。那么buffer管理器会不停的替换buffer来存数据。而不是解析包头。确定包的大小。然后指定一个刚好符合的buffer。然后每次recv数据都放在这个buffer里。而不用不停的替换buffer.