<p>The idea behind implementing consistency with a quorum is to maintain consistency in one group (that contains the majority of replicas) and forcing, by construction, that reads and writes <em>cannot violate the consistency within that group</em>.</p>

<p>This is done by only allowing updates within a group of replicas that contains the majority of replicas, so that <em>at least one node witnesses all the updates</em>; this is related to the second condition you've mentioned. In more details, consider a scenario for writing:</p>

<ul>
<li>To complete a write, a client must successfully place the updated data item on more than <code>N/2</code> (i.e. a majority of) replicas. (The updated data item will be assigned a new version number that is obtained by incrementing its current version number.)</li>
<li>Since the write quorum engages a majority of the replicas, two distinct write operations <em>cannot succeed at the same time</em>. (There do not exist two distinct groups that contain majorities of replicas.)</li>
<li>Therefore, all <em>write operations are serialized</em> and therefore consistency is guaranteed. (At least one node has to be included in two consecutive write operations, while that node will have the highest current version number.)</li>
</ul>

<p>Note that consistency overall, has to be ensured with respect to both writing and reading. (As an extreme example, a system that does not perform reads will always be consistent.) To that end, mechanisms for distinguishing newer from older values is needed (e.g. a simple version number, as mentioned before) for achieving consistent read operations. This is related to the first condition you've mentioned:
in turn, reading can be achieved with <code>N + x - Nw</code> replicas (where <code>Nw + Nr = N + x</code>, since <code>Nw + Nr &gt; N</code>). Thus the intersection
of the read quorum (of Nr nodes) and the write quorum (of Nw nodes) cannot be empty, so reads cannot overlap with writes, i.e. each read will have to consult at least one replica with the current data item (determined by it's version number). </p>

<p>Note that to control concurrency, mechanisms such as two-phase locking can be used -- for initial query from a set replicas, a reader can use read locks and a writer can use write locks. The locks are released after the operation completes or aborts.</p>

<p>The read/write quorum scheme was first proposed in [1] and it was later generalized into the form you've mentioned in [2]. (These papers cover the topic in more detail.)</p>

<p>[1] <a href="http://dl.acm.org/citation.cfm?id=320076&amp;CFID=830545790&amp;CFTOKEN=62710538" rel="nofollow">Thomas, Robert H. "A majority consensus approach to concurrency control for multiple copy databases." ACM Transactions on Database Systems (TODS) 4.2 (1979): 180-209.</a></p>

<p>[2] <a href="http://dl.acm.org/citation.cfm?id=806583" rel="nofollow">Gifford, David K. "Weighted voting for replicated data." Proceedings of the seventh ACM symposium on Operating systems principles. ACM, 1979.</a></p>

CC BY-SA 3.0
2016-09-25T17:48:48.247Z
2016-09-25T17:54:34.133Z
2016-09-25T17:54:34.133Z
ivcha
<p>If we have 2 concurrent writes and we would write to less than n/2, then we would have inconsistent data. If each write takes a write quorum of at least (n/2)+1, then there is at most one write at a time => We guarantee consistency.</p>

CC BY-SA 3.0
2016-09-17T12:22:28.960Z
2016-09-17T12:22:28.960Z
paulgavrikov
<p>I'm stuck at distributed consistency when using a quorum. In this case we use <code>N</code> servers - <code>2/3N+1</code> for the read quorum (Nr), and <code>N/3+1</code> for the write quorum (Nw).</p>

<p>Now, two conditions have to be satisfied to achieve consistency. </p>

<ol>
<li>Nr + Nw > N (implies at least one server that performs read was updated)</li>
<li>Nw > N/2</li>
</ol>

<p>And the second condition is what isn't clear to me. According to <a href="https://en.wikipedia.org/wiki/Quorum_(distributed_computing)" rel="nofollow">wikipedia</a> this ensures that two write operations don't concurrently occur at the same data item. Can somebody evaluate on that?</p>

<dc.distributed-comp>
Distributed Consistency using Quorum approach
paulgavrikov
# Distributed Consistency using Quorum approach

(Asked by: username_0 on 2016-09-12)

I'm stuck at distributed consistency when using a quorum. In this case we use `N` servers - `2/3N+1` for the read quorum (Nr), and `N/3+1` for the write quorum (Nw).

Now, two conditions have to be satisfied to achieve consistency.

1. Nr + Nw > N (implies at least one server that performs read was updated)
2. Nw > N/2

And the second condition is what isn't clear to me. According to [wikipedia](https://en.wikipedia.org/wiki/Quorum_(distributed_computing)) this ensures that two write operations don't concurrently occur at the same data item. Can somebody evaluate on that?

**Tags:** dc.distributed-comp


---

## 2 answers

### Answer by username_1 on 2016-09-25. Score: 1 | Accepted answer

The idea behind implementing consistency with a quorum is to maintain consistency in one group (that contains the majority of replicas) and forcing, by construction, that reads and writes *cannot violate the consistency within that group*.

This is done by only allowing updates within a group of replicas that contains the majority of replicas, so that *at least one node witnesses all the updates*; this is related to the second condition you've mentioned. In more details, consider a scenario for writing:

* To complete a write, a client must successfully place the updated data item on more than `N/2` (i.e. a majority of) replicas. (The updated data item will be assigned a new version number that is obtained by incrementing its current version number.)
* Since the write quorum engages a majority of the replicas, two distinct write operations *cannot succeed at the same time*. (There do not exist two distinct groups that contain majorities of replicas.)
* Therefore, all *write operations are serialized* and therefore consistency is guaranteed. (At least one node has to be included in two consecutive write operations, while that node will have the highest current version number.)

Note that consistency overall, has to be ensured with respect to both writing and reading. (As an extreme example, a system that does not perform reads will always be consistent.) To that end, mechanisms for distinguishing newer from older values is needed (e.g. a simple version number, as mentioned before) for achieving consistent read operations. This is related to the first condition you've mentioned:
in turn, reading can be achieved with `N + x - Nw` replicas (where `Nw + Nr = N + x`, since `Nw + Nr > N`). Thus the intersection
of the read quorum (of Nr nodes) and the write quorum (of Nw nodes) cannot be empty, so reads cannot overlap with writes, i.e. each read will have to consult at least one replica with the current data item (determined by it's version number).

Note that to control concurrency, mechanisms such as two-phase locking can be used -- for initial query from a set replicas, a reader can use read locks and a writer can use write locks. The locks are released after the operation completes or aborts.

The read/write quorum scheme was first proposed in [1] and it was later generalized into the form you've mentioned in [2]. (These papers cover the topic in more detail.)

[1] [Thomas, Robert H. "A majority consensus approach to concurrency control for multiple copy databases." ACM Transactions on Database Systems (TODS) 4.2 (1979): 180-209.](http://dl.acm.org/citation.cfm?id=320076&CFID=830545790&CFTOKEN=62710538)

[2] [Gifford, David K. "Weighted voting for replicated data." Proceedings of the seventh ACM symposium on Operating systems principles. ACM, 1979.](http://dl.acm.org/citation.cfm?id=806583)


---

### Answer by username_0 on 2016-09-17. Score: 0

If we have 2 concurrent writes and we would write to less than n/2, then we would have inconsistent data. If each write takes a write quorum of at least (n/2)+1, then there is at most one write at a time => We guarantee consistency.


---

