fs buffer, user is sent acknowledgement, power goes out Data not yet written to disk is LOST System is UNAVAILABLE Single Disk Solutions: fsync, battery backup, prayer Failure Mode 1
of the most fundamental problems in distributed computing and is at the core of many algorithms for distributed data processing, distributed file management, and fault- tolerant distributed applications.”
numerous attempts to make it more approachable. Furthermore, its architecture is unsuitable for building practical systems, requiring complex changes to create an efficient and complete solution. As a result, both system builders and students struggle with Paxos.”
ensures Safety and Linearizability 3. Detect crashes + Elect new Leader 4. Maintain consistency after Leadership “coups” 5. Depose old Leaders if they return 6. Manage cluster topology
for building strongly consistent distributed systems in Erlang •Implements the raft consensus protocol in Erlang •Fundamental abstraction is the replicated log What:
commands •Commands are transparent to Rafter •Systems build on top of rafter with pluggable state machines that process commands upon log entry commit.
to other processes without having to know if the other process is local. %% Send to a local gen_server process gen_server:cast(peer1, do_something) %% Send to a gen_server on another machine gen_server:cast({‘[email protected]’}, do_something) %% wrapped in a function with a variable name for a clean client API do_something(Name) -‐> gen_server:cast(Name, do_something). %% Using the API Result = do_something(peer1).
good case. Fail otherwise. •Supervisors relaunch failed processes •Links and Monitors alert other processes of failure •Avoids coding most error paths and helps prevent logic errors from propagating
that simplifies the building of reliable, well engineered erlang applications. • The gen_server, gen_fsm and gen_event modules are the most important parts of OTP • They wrap processes as server “behaviors” in order to facilitate building common, standardized distributed applications that integrate well with the Erlang Runtime
peer’s state machine as their entries are committed •All peers in a consensus group can only run one type of state machine passed in during start_node/2 •Each State machine must export apply/1
leader •Messages sent and received between fsm’s according to raft protocol •State handling functions pattern match on messages to simplify and shorten handler clauses.
•Depending upon the configuration of the cluster, different code paths need navigating, such as whether a majority of votes has been received. •Instead of embedding this logic in the consensus fsm, it was abstracted out into a module of pure functions
tsantero
manfredsteyer
sugi_0000
tama50505
ttskch
onopon
h0r15h0
kubotak
rainerhahnekamp
lamodatech
kwakeuijin
makihiro
iwatatomoya
keithpitt
jcasabona
tammyeverts
matthewcrist
chriscoyier
reverentgeek
eileencodes
mclloyd
destraynor
addyosmani
jmmastey
tanoku
