You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm afraid I do not have a short or complete answer for this.
To answer the first half of the question regarding revision number:
To ensure linearizability guarantee, all mutating requests, once agreed by majority of servers in a cluster (via Raft consensus protocol), are applied sequentially to the key value store. Every mutating request increases the revision of store by 1.
The second half question involves optimization in many layers in the system. For example, starting from v3.2, mutating requests are batched: #7105. Starting from v3.4, long running reads do not block other requests including writes: #10523. etc.
Just wondering how etcd computes the revision number that is monotonically increasing but is also able to support a high write throughput.
The text was updated successfully, but these errors were encountered: