luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages 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 da1c476343
commit db65ebb631
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.
* [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.
* [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
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
["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).
@ -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,
and managing when an entry is considered committed.
Raft is a complex protocol and will not be covered here in detail. For the full
specification, we recommend reading this [paper](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf).
Raft is a complex protocol and will not be covered here in detail (for those who
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
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.
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
is an opaque binary blob. The leader then writes the entry to durable storage and
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
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
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.
Obviously, it would be undesirable to allow a replicated log to grow in an unbounded