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, 陈宗志 <baotiao@gmail.com> 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
>
|