[转帖]etcd网络模块解析

https://www.cnblogs.com/luohaixian/p/17509742.html

1. RaftHttp模块介绍

在etcd里raft模块和网络模块是分开的，raft模块主要负责实现共识算法，保证集群节点的一致性，消息的发送和接收则交给raftHttp网络模块来处理，由上层应用模块来进行协调交互和消息传递。

 

1.1. 整体结构图

 

 

（1）当raft模块发生了状态变化时，会把变化的消息封装到ready对象中，上层应用模块通过监听ready的channel能够获取到对应的消息，然后调用网络层的send方法来发送到其它节点上；

（2）send方法这里会根据消息的类型做一个分发，如果是快照的消息则写入到pipeline的msgc channel中，其它消息则都写入到streamWriter的msgc channel中；

（3）streamWriter启动时会创建一个goroutine，它会监听connc管道上是否有网络连接对象conn（这个是在对方发起get请求建立起来的网络连接），如果有则获取并使用它来作为底层传递对象，监听msgc通道上的消息，如果有消息则获取并通过conn进行发送，如果connc管道上没有则等待；

（4）streamReader启动时会进行一个回拨与peer端建立一条网络连接，比如B节点会发起一个GET请求到A节点，建立一条网络连接，A节点会把这条网络连接放入到connc管道中，供A节点的streamWriter进行写入使用，B节点则是从这条网络连接里读数据，有点类似单向管道；同理A节点的streamReader在启动时也会发起GET请求到B节点从而建立网络连接，此时这条网络是A节点进行读取，B节点进行写入；

（5）对于快照的数据，v3版本的是使用snapSender来进行发送，创建post请求通过pipeline的transport来进行发送；之前的版本则是封装为一个快照消息分发到pipeline的msgc的channel中，pipeline在启动时会创建4个goroutine来监听msgc管道里的消息，如果有则取出并创建post请求通过pipeline transport发送出去；

（6）streamReader从stream pipeline中读到数据时将其进行反序列化为消息，然后根据消息的类型分别放到propc或recvc管道中，这样做区分的原因是因为MsgProp的消息处理的耗时可能比较长，所以单独放到一个管道中去，这样不阻塞其它消息的处理，这两个管道分别会有个goroutine进行读取并调用raft对象的Process函数将其传入到raft模块里去处理；

（7）snapshotHandler是一个gateway的方式接收发过来的post请求，接收快照数据保存到本地然后通知raft状态机进行处理；

（8）streamHandler也是一个gateway的方式接收streamReader发送过来的GET请求，并将该网络连接塞入到connc管道中，供streamWriter进行数据写入；

（9）stream的http transport：在创建http transport时传入的read和write的超时时间是5，因为stream通道传输的消息数据一般都比较小；

（10）pipeline的http transport：在创建http transport时传入的read和write的超时时间是0，因为快照数据比较多，读写的时间也比较长；

 

1.2. 关键数据结构分析

 

 

rafthttp.Transport：网络模块数据结构，里面维护了多个进行网络交互的流对象，通过这个对象可以添加peer和发送数据；

 

http.Transport：go的http库，rafthttp.transport也是通过创建它来进行数据发送和读取，它会去维护tcp连接，并且管理空闲连接；rafthttp里创建了两个http.Transport对象，一个是stream用的，一个是pipeline用的；

 

rafthttp.remote：里面也封装了pipeline，使用pipeline http transport网络发送数据，主要是帮助新加入的成员进行数据追赶。当peer的网络不可用时，如果此时有remote的则也会使用remote的网络连接来进行发送数据；

 

rafthttp.peer：peer代表对端，维护的是向peer发送数据和接收peer数据的网络流对象；

 

rafthttp.pipeline：用以发送快照；

 

rafthttp.streamWriter：rafthttp.peer对象的输出流，通过它向peer端发送数据；

 

rafthttp.streamRader：rafthttp.peer对象的输入流，通过它从peer端接收数据；

 

2. 关键流程分析

2.1. raftExample的网络模块初始化

 

 

2.2. 启动peer流程

 

 

2.3. streamWriter启动流程

 

 

2.4. streamReader启动流程

 

 

3. 传输格式

在代码中，其实我们可以看到streamReader和streamWriter都分别有两个对象的。

streamWriter：writer和msgAppV2Writer

streamReader：msgAppReader和msgAppV2Reader

这两个对象的关键不同点就是encode和decode的不同，因为底层传输字节格式不一样，所以需要这样区分开来。

 

3.1. msgApp格式

Message压缩后发送的格式：

 

比较简单，直接就是写入消息长度，然后接着是压缩后的数据。解压时先读取消息长度，然后读取指定长度的数据进行反序列化为Message格式。

 

3.2. msgAppV2格式

根据Message的消息类型分为3种格式存储。

 

3.2.1. linkHeartbeatMessage类型的消息

只有一个字节，字节值为uint8的0

 

3.2.2. 数据格式是msgTypeAppEntries的

符合这种格式的条件是编码器保存的index、term和logTerm跟Message中的index、term和logTerm一致，否则解码器对象里保存的这些值补充到Message的Entry里就是错的了，对于解码器对象里index等变量的维护逻辑与编码器里的一致。

 

 

解压时按照这种格式读出来，然后填充上解码器对象里的index、term和logTerm值即可。

msgAppV2格式的压缩优化要点：消息中携带的多个entry的index、Term等字段大多数场景都是一样的。当有多个Entry时，它可以节省index、Term和LogTerm这些字段的重复传输，因为在实际使用场景，大概率这些字段都是重复的，所以在encode时只需要保存一份即可，解压时再补上去就行，相比msgApp的直接整个序列化的方式，它传输的字节数要少得多。

 

3.2.3. 非linkHeartbeatMessage和msgTypeAppEntries格式

这种格式类型命名为msgTypeApp，压缩方式与msgApp一样，只不过前面多了个字节，值为uint8的2。

 

4. 网关URL映射处理逻辑

 

URL前缀	映射处理对象	请求举例	说明
/raft	pipelineHandler	POST /raft	只接收POST请求，接收数据后反序列化为Message对象，然后传入到raft模块处理
/raft/probing	probingHandler	GET /raft/probing	收到请求后响应消息，并且带上当前响应时间戳，表示探测成功
/raft/stream/	streamHandler	GET /raft/stream/message/{localID}（V1的格式） GET /raft/stream/msgapp/{localID}（V2的格式）	只接收GET请求，用来建立stream网络连接
/raft/snapshot	snapHandler	POST /raft/snapshot	只接收POST请求，接收到数据后反序列化为Message对象，检查消息类型是否为快照类型，如果不是则返回错误信息，如果是则保存快照数据到本地并传到raft模块进行处理