> Although Raft is stable and easy to implement, it takes 2 RTTs to complete a consensus request from the view of a client. One RTT takes place between the client and the leader server, and the leader server takes another RTT to broadcast the message to the follower servers. In a geo-distributed environment, an RTT is quite long, varying from tens of milliseconds to hundreds of milliseconds, so 2 RTTs are too long in such cases.
> We adopt a new consensus protocol named CURP to resolve the above issue. Please refer to the paper for a detailed description. The main benefit of the protocol is reducing 1 RTT when contention is not too high. As far as we know, Xline is the first product to use CURP.
1 comment
[ 2.3 ms ] story [ 31.3 ms ] thread> Although Raft is stable and easy to implement, it takes 2 RTTs to complete a consensus request from the view of a client. One RTT takes place between the client and the leader server, and the leader server takes another RTT to broadcast the message to the follower servers. In a geo-distributed environment, an RTT is quite long, varying from tens of milliseconds to hundreds of milliseconds, so 2 RTTs are too long in such cases.
> We adopt a new consensus protocol named CURP to resolve the above issue. Please refer to the paper for a detailed description. The main benefit of the protocol is reducing 1 RTT when contention is not too high. As far as we know, Xline is the first product to use CURP.
It is open source, Apache license, Rust: https://github.com/datenlord/xlinehttps://github.com/datenlo...