grpc-go源码剖析四十六之服务器端是如何将数据帧缓存到recvBuffer里？(多个数据帧时，在底层是如何来存储的？)

已发表的技术专栏
0  grpc-go、protobuf、multus-cni 技术专栏 总入口

1  grpc-go 源码剖析与实战  文章目录

2  Protobuf介绍与实战 图文专栏  文章目录

3  multus-cni   文章目录(k8s多网络实现方案)

4  grpc、oauth2、openssl、双向认证、单向认证等专栏文章目录)

经过前面几篇文章分析，我们已经服务器端接收到数据帧后，经历抽样流控，链路流控，流级别流控；

那么，接下来我们要考虑的问题是，服务器端如何来维护接收到数据帧呢？

换句话说，服务器端接收到不止一个数据帧时，按照什么原则来存储这些数据帧？ 是随意存储，还是存储到单链表里呢？

1、数据帧存储到recvBuffer里的整体流程图？

1.1、存储模型图？

• 数据帧在grpc框架中的存储是利用channel+bytes.Buffer作为底层存储的(recvBuffer.c + recvBuffer.backlog)。
• 将获取到的数据帧先存储到channel通道里，channel的类型是recvMsg，而recvMsg是对bytes.Buffer的包装
• 后续接收到的数据帧，存储到backlog切片里，backlog类型是recvMsg的切片

1.2、存储流程图？

主要流程说明:

• 先从bytes.Buffer对象池里获取一个bytes.Buffer类型的对象
• 将数据帧存储到bytes.Buffer对象里
• 调用recvBuffer的存储器put： 就是判断切片backlog里是否有数据
  • 若没有的话，将接收到是数据帧存储到通道里
  • 若有数据的话，将接收到的数据帧存储到切片backlog的尾部即可。

2、从源码的视角进行分析

2.1、将接收到数据帧封装到类型为bytes.Buffer对象里

分析入口在:

在gRPC-go源码中提供了测试用例，随便找一个服务器端的启动文件main.go ,参考下面的调用链即可找到：

main.go->s.Serve->s.handleRawConn(rawConn)->s.serveStreams(st)->st.HandleStreams(func(stream *transport.Stream)->handleData方法

或者

直接进入grpc-go/internal/transport/http2_server.go文件中的handleData方法里：

1．func (t *http2Server )handleData(f *http2.DataFrame) {
2．        // ---省略掉----流控相关代码-----
3．	s := t.getStream(f)
4．	if size > 0 {
5．		
6．		if len(f.Data()) > 0 {
7．			buffer := t.bufferPool.get()
8．			buffer.Reset()
9．			buffer.Write(f.Data())
10．			s.write(recvMsg{buffer: buffer})
11．		}
12．	}
13． // ---省略掉----不相关代码-----
14．}

本次分析，只关心第7-10行：
主要流程说明：

• 第7行：从对象池bufferPool获取一个bytes.Buffer类型的对象buffer
• 第9行：将数据帧存储到对象buffer里
• 第10行：向将buffer封装到recvMsg结构体里，然后调用流的write方法

2.2、gRPC-go框架是如何存储bytes.Buffer对象的？也就是，如何来存储接收到的数据帧的

接着上面，直接点击write方法：(进入grpc-go/internal/transport/transport.go文件中Stream结构体的Write方法里：)

func (s *Stream) write(m recvMsg) {
	s.buf.put(m)
}

可见，实际调用的是类型recvBuffer的put方法：
进入grpc-go/internal/transport/transport.go文件中recvBuffer结构体的put方法里:

1．func (b *recvBuffer) put(r recvMsg) {
2．	b.mu.Lock()
3．	if b.err != nil {
4．		b.mu.Unlock()
5．		// An error had occurred earlier, don't accept more
6．		// data or errors.
7．		return
8．	}
9．	b.err = r.err
10．	if len(b.backlog) == 0 {
11．		select {
12．		case b.c <- r:
13．			b.mu.Unlock()
14．			return
15．		default:
16．		}
17．	}
18．	b.backlog = append(b.backlog, r)
19．	b.mu.Unlock()
20．}

主要流程说明:

• 第3-8行：校验工作
• 第10-16行：判断一下切片b.backlog是否为空，
  • 如果没有数据的话，就将接收到的数据r，存储到通道b.c里
  • 如果不为空，即切片b.backlog已经有数据帧了的话，就将新接收到的数据帧存储到切片b.backlog的尾部

假设客户端将一个数据帧分多次发送，服务端第一次接收到数据帧后是存储到通道b.c里了，以后的数据帧呢？

可能场景一：

• 第一次接收到数据帧后，执行的顺序第10-14行，然后就退出了。此时b.backlog依旧没有数据帧。
• 第二次接收到数据帧后，执行的是第10行，然后进入第11行，多路复用器，发现第12行的通道b.c中的数据，还没有消费，那么就会阻塞，执行defalut分支，然后执行18行，将第二个数据帧里存储到了切片b.backlog里了
• 第三次接收到数据帧时，就会直接执行第18行了。

可能场景二：

• 可能是，当第一个数据帧存储到通道后，就立马消费掉了，第二数据帧还会存储到通道b.c里；
  也就是当服务器接收到的数据帧来不及消费时，就会将待处理的数据帧存储到切片里。

如果前一个数据还没有被消费的话，就存储到切片b.backlog里；

这种方式，

其实是保证了数据是按照顺序存储的

到目前为止，已经将接收到数据帧真正的存储到本地内存了，至于如何读取，再后面的章节，会介绍。

3、总结

其实，本篇文章在解决一种场景，接收端接收到多次请求后，如何保证按顺序存储，为以后按顺序读取数据奠定了基础。

底层采用了通道+切片的方式实现。

在自己的项目中，如果有类似的场景，是不是可以作为一种参考方案呢？

将别人的经验，别人的源码，经过抽象整理后，灵活运用到我们自己的场景中，才是我们的最终目的。

下一篇文章
  服务器端在真正执行客户端的请求方法前，是如何完整的读取到请求参数值的？

 

点击下面的图片，返回到专栏大纲