Hi baotiao, First, requests are acknowledged back to the client once the leader accepted and written them in its transaction log, which guarantees that in case of a crash, pending transactions can be processed on restart. Transactions IDs (zxid) are incremental and generated by the leader. Second, Zab guarantees that if the leader broadcast T and T' in that order, each server must commit T before committing T'.
With these 2 promises, I believe, that FIFO is guaranteed by Zookeeper. Would you please clarify that what do you mean by "set b=1 operation is on the way"? If "set b=1" is accepted by the leader, the client won't have to resend it on reconnect. Regards, Andor On Mon, Nov 13, 2017 at 5:01 AM, 陈宗志 <[email protected]> wrote: > I want to know in the following situation, how zookeeper promise client > FIFO order. > > the client sent three operation to server, set a = 1, set b = 1, set ready > = true. > > is it possible to this situation that the set a = 1 is process by the > leader, then there is something wrong with this tcp connection, this client > reconnect a new tcp connection to the leader, but the set b = 1 operation > is on the way. then the client will use the new tcp connection to sent set > ready = true operation. so the set a = 1 is operated, set b = 1 is not and > set ready = true is operated too. > > the question is how zab promise client FIFO order? > > zab can resend all the operation that hasn't be replied from the leader. > then in this situation, when the client reconnect to the leader, it will > resent the operation set b = 1, set ready = true. > > is this the way the zab used to primise FIFO order? > > Thank you all > > -- > --- > Blog: http://www.chenzongzhi.info > Twitter: https://twitter.com/baotiao <https://twitter.com/#%21/baotiao> > Git: https://github.com/baotiao >
