status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Website: minor additional tweaks for docs/internals/consensus.html.

This commit is contained in:
Ryan Breen 2015-04-11 11:41:55 -04:00
parent 2b9bb18921
commit 218b432446
2 changed files with 9 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/source/docs/guides/index.html.markdown
View File

@ -30,6 +30,8 @@ The following guides are available:
* [Multiple Datacenters](/docs/guides/datacenters.html) - Configuring Consul to support multiple datacenters. * [Multiple Datacenters](/docs/guides/datacenters.html) - Configuring Consul to support multiple datacenters.
* [Securing Consul](/docs/guides/securing.html) - This guide covers cluster security options.
* [Outage Recovery](/docs/guides/outage.html) - This guide covers recovering a cluster that has become unavailable due to server failures. * [Outage Recovery](/docs/guides/outage.html) - This guide covers recovering a cluster that has become unavailable due to server failures.
* [Semaphore](/docs/guides/semaphore.html) - This guide covers using the Key/Value store to implement a semaphore. * [Semaphore](/docs/guides/semaphore.html) - This guide covers using the Key/Value store to implement a semaphore.

13
website/source/docs/internals/consensus.html.markdown
View File

@ -9,7 +9,7 @@ description: |-
# Consensus Protocol # Consensus Protocol
Consul uses a [consensus protocol](http://en.wikipedia.org/wiki/Consensus_(computer_science)) Consul uses a [consensus protocol](http://en.wikipedia.org/wiki/Consensus_(computer_science))
to provide [Consistency](http://en.wikipedia.org/wiki/CAP_theorem) as defined by CAP. to provide [Consistency (as defined by CAP)](http://en.wikipedia.org/wiki/CAP_theorem).
The consensus protocol is based on The consensus protocol is based on
["Raft: In search of an Understandable Consensus Algorithm"](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf). ["Raft: In search of an Understandable Consensus Algorithm"](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf).
For a visual explanation of Raft, see the [the Secret Lives of Data](http://thesecretlivesofdata.com/raft). For a visual explanation of Raft, see the [the Secret Lives of Data](http://thesecretlivesofdata.com/raft).
@ -54,8 +54,9 @@ on a quorum of nodes. Once an entry is committed it can be applied.
The leader is responsible for ingesting new log entries, replicating to followers, The leader is responsible for ingesting new log entries, replicating to followers,
and managing when an entry is considered committed. and managing when an entry is considered committed.
Raft is a complex protocol and will not be covered here in detail. For the full Raft is a complex protocol and will not be covered here in detail (for those who
specification, we recommend reading this [paper](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf). desire a more comprehensive treatment, the full specification is available in this
[paper](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)).
We will, however, attempt to provide a high level description which may be useful We will, however, attempt to provide a high level description which may be useful
for building a mental model. for building a mental model.
@ -69,11 +70,11 @@ In addition, if stale reads are not acceptable, all queries must also be perform
the leader. the leader.
Once a cluster has a leader, it is able to accept new log entries. A client can Once a cluster has a leader, it is able to accept new log entries. A client can
request that a leader append a new log entry: from Raft's perspective, a log entry request that a leader append a new log entry (from Raft's perspective, a log entry
is an opaque binary blob. The leader then writes the entry to durable storage and is an opaque binary blob). The leader then writes the entry to durable storage and
attempts to replicate to a quorum of followers. Once the log entry is considered attempts to replicate to a quorum of followers. Once the log entry is considered
*committed*, it can be *applied* to a finite state machine. The finite state machine *committed*, it can be *applied* to a finite state machine. The finite state machine
is application specific, and in Consul's case, we use is application specific; in Consul's case, we use
[BoltDB](https://github.com/boltdb/bolt) to maintain cluster state. [BoltDB](https://github.com/boltdb/bolt) to maintain cluster state.
Obviously, it would be undesirable to allow a replicated log to grow in an unbounded Obviously, it would be undesirable to allow a replicated log to grow in an unbounded