Committing locally when sending an ACK at a server would lead to loss of consistency - it is possible that this is the only server that acks, e.g., this server is temporarily disconnected from the leader, the leader gets re-elected and the operation is truncated from logs at other servers. Its ok to ACK it but its not ok to commit since this exposes this to users as a committed operation that they can see.
On Mon, Sep 28, 2015 at 4:19 AM, Ibrahim El-sanosi (PGR) < i.s.el-san...@newcastle.ac.uk> wrote: > In Zab, assume we have a cluster consists of 3-servers. To deliver a write > request, it must run 3 communication steps proposal, acknowledgement and > commit. > As Zab uses reliable FIFO, it is possible to remove commit round. As soon > as a follower receives a proposal, it logs, sends an ACK and commits > locally. Upon receiving ACK from any follower, leader commits a proposal > locally, no COMMIT message need to be sent to followers. In this case, all > servers commit a proposal in two round-trips, resulting in reducing latency > particularly in followers. > > Note that this optimization can only work in 3-servers cluster (follower > reaches a majority as soon as it acks). > Does anyone see any problems with such (small) optimization? > Ibrahim >
