(2) You can lose a committed data if have more failure than what the quorum is configured to support (eg. losing 3 out of 5 hosts) -- Thawan Kooburat
On 10/21/13 4:48 PM, "Alexander Shraer" <[email protected]> wrote: >Hi, > >(1) Zab is an atomic broadcast protocol, it satisfies strong ordering >properties. Check out the paper: >http://www.stanford.edu/class/cs347/reading/zab.pdf > >Its used to propagate updates in the same order to all the ZooKeeper >servers. The provided consistency in ZooKeeper is basically sequential >consistency + >real-time-order on writes. This is strong, although not linearizable >(its possible that you read from a server that has stale data). > >If you use the sync call before a read, ZooKeeper provides >ilnearizability for sync+read and write operations (this is true with >certain timing assumption made in ZooKeeper for efficiency). > >(2) No, only a suffix of uncommitted operations can disappear. >Operations acked by a quorum never dissappear. > >(3) For read operations the server responds immediately using local >state. For writes it responds after a quorum acked the update. > > >Alex > >On Mon, Oct 21, 2013 at 1:47 AM, 聂安 <[email protected]> wrote: >> hi all, >> >> About zk, I got some questions bothered me for one week, which can be >>described as follows: >> >> (1) Does zab guarantee a strong consistency? >> >> (2) Could those committed proposals on new-elected-followers be deleted >>when initially synced? >> >> (3) When does the server in zk respond to the client? After commiting >>the proposal? >> >> thank you！ >> >> >> >> >> Regards, >> >> An.Nie
