Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
kvserver: setup flow token returns using the RaftTransport
This commit integrates the kvflowcontrol.Dispatch with the kvserver-level RaftTransport. When log entries are admitted below raft, we'll want to inform the origin nodes of this fact, effectively returning the flow tokens that were deducted when replicating the log entry to us. We repurpose the existing RaftTransport for this communication -- we piggyback these flow token returns[^1] on raft messages already bound to nodes we're returning tokens to. We also guarantee delivery of tokens in the presence of idle RaftTransport connections[^2]. We had to to introduce some protocol changes here. When a client establishes a RaftMessageRequestBatch stream, it sends along to the server the set of all StoreIDs it has. It's populated on the first RaftMessageRequestBatch sent along MultiRaft.RaftMessageBatch gRPC stream identifying at least one store, and then populated once more if any additional stores have been initialized[^3]. This data is used by the kvflowcontrol machinery to track the exact set of stores on the client node. It uses this information to react to the gRPC streams breaking. Since these streams are used to piggy information about which log entries were admitted below raft[^4] in order for the server-side to free up flow tokens, if the stream breaks we possibly risk leaking these tokens. So when these streams break, we use information about the client's stores to release all held tokens[^5]. We're not using this code just yet, which is just the below-raft integration with kvflowcontrol. The subsequent commit will introduce the above-raft integration where we'll actually deduct flow tokens at the sender, encode proposals using EntryEncoding{Standard,Sideloaded}WithAC, which in turn enqueues virtual work items in below-raft admission queues for asynchronous admission. Once asynchronously admitted, using the changes in this commit, we'll return flow tokens using the now-wired-up kvflowcontrol.Dispatch interface. --- Suggested reading order for reviewers: - (*RaftTransport).kvflowControl Brief comment block which tries to give a lay of the land. - flow_control_stores.go Integration interface+implementation that's going to be used by the RaftTransport to return flow tokens to the specific locally held kvflowcontrol.Handles, after learning about admitted raft log entries from remote nodes. It's implemented more fully in the subsequent commit. - flow_control_raft_transport.go Contains the set of new dependencies now used in the RaftTransport code for flow token purposes. It also includes the interfaces that show how the RaftTransport informs individual replicas that its no longer connected to specific (remote) stores. They're used more fully in the subsequent commit. - raft_transport.go The actual code changes to the RaftTransport. - flow_token_transport_test.go and flow_token_transport/* Datadriven test to understand how the various pieces fit together. - kvflowdispatch/* Adds some metrics and unit testing for the canonical kvflowcontrol.Dispatch implementation (previously implemented). --- [^1]: In the form of kvflowcontrolpb.AdmittedRaftLogEntries. [^2]: See kvserver.TestFlowTokenTransport. [^3]: This two-step process is because of how and when we allocate StoreIDs. Ignoring nodes that are bootstrapping the cluster (which just picks the initial set of StoreIDs -- see pkg/server.bootstrapCluster), whenever a new node is added, it's assigned a node ID and store ID by an existing node in CRDB (see kvpb.JoinNodeResponse). Subsequent store IDs, for multi-store nodes, are generated by the joining node by incrementing a sequence ID generator (see pkg/server.(*Node).initializeAdditionalStores). All of which is to say that the very first time we issue a RaftMessageRequestBatch, we might not have all the StoreIDs. But we will very shortly after, and certainly before any replicas get allocated to the additional store. [^4]: See kvflowcontrolpb.AdmittedRaftLogEntries and its use in RaftMessageRequest. [^5]: See I1 from kvflowcontrol/doc.go. Release note: None
- Loading branch information