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的03.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模块进行处理 |