zoukankan      html  css  js  c++  java
  • 大型分布式C++框架《四:netio之buffer管理器 下》

    每周一篇又来了。这次主要介绍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.
  • 相关阅读:
    jq实现多级手风琴效果
    css弹性盒布局
    css兼容处理
    bootstrap--双日历插件
    char*,string,char a[], const char *,之间的转换
    8.Maximum Depth of Binary Tree
    7. Minimum Depth of Binary Tree-LeetCode
    6. Reverse Linked List 逆转单链表
    5.Maximum Product Subarray-Leetcode
    卷积神经网络(Convolutional Neural Networks)CNN
  • 原文地址:https://www.cnblogs.com/xumaojun/p/8526489.html
Copyright © 2011-2022 走看看