MIT 6.824 lab3 Kvraft

LAB3 than lab2 more free, mainly without reference to the paper and too much information can be checked, and debugging difficulty is relatively large. LAB3A primarily implements raft-based KV Server,client to send requests to the server, and then the server maintains log consistency through the underlying raft, and the operation is stored in memory. LAB3B is primarily implemented to memory snapshots and then persisted into Persister.

My code: MIT6.824 lab3a client

The first is to implement the client operation, we can first by looking at the Test_ Test.go to understand the testing process, first the test creates a few new servers and clients, and then invokes the client's request operation, which invokes the server-side implementation via RPC.

The main is to implement the client side of the Get and Putappend method, this is actually very simple, we only need in two methods, infinite loop attempt to send RPC request to the server side, if the successful return, unsuccessful continue to send.

In order to prevent the network instability and so on, the server has performed the operation, but reply will not go back to the client side, we need to maintain the power of the operation, that is, the weight. An easy way to do this is to add a clientid and SEQ to each client-side request, which is a unique 64-bit number for each client, which is the request sequence number incremented with each new request.

As a result of our testing, a client would repeat the current request if it had not been executed successfully, so we only need to record the maximum number of serial numbers that have been received for each client on the server side. Server

The server side mainly needs to receive the client sends the request, then executes, the execution process mainly sends the log to the underlying raft service, then commits the request through the raft, then obtains the request from the channel in the server side, then applies in the memory, Then notify the client that the operation has been completed or not completed.

The entire process is synchronous and must wait for the request to be completed to reply to the client after the request has been executed, so you can return the index of the request in log through the raft start function, create a channel for each index to receive the completion message, and receive , knowing it was done, and then replying to the client

Need to open a separate goroutine to monitor the Apply channel, once the underlying raft commits one, immediately executes one. lab3b Snapshot

Snapshot is not really complicated, there are a few things to do: When you start the server, you need to read snapshot, and before the underlying raft starts to run. When raft state is log and the other two parameters exceed a certain limit, the server will save the memory status at this time as snapshot raft leader when sending the heartbeat to find and follower log mismatch points, In its existing log does not exist (has been deposited snapshot), leader need to appendentries RPC into Installsnapshot RPC, accompanied by a heartbeat effect. Installsnapshot RPC is mainly truncated log, and then other decisions and other RPC the same, and then to apply channel to send a message with snapshot, when the server side out of execution, is to perform the operation of loading this snapshot, not the client's request.