ACID
事務(wù)的四個特征：Atomic原子性聋庵，Consistency一致性饱苟，Isolation隔離性，Durability持久性
CAP
在一個分布式系統(tǒng)中编矾， Consistency（一致性）攀涵、 Availability（可用性）、Partition tolerance（分區(qū)容錯性）洽沟，三者不可得兼。
BASE
BASE是Basically Available（基本可用）蜗细、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個短語的簡寫裆操，BASE是對CAP中一致性和可用性權(quán)衡的結(jié)果，其來源于對大規(guī)穆剑互聯(lián)網(wǎng)系統(tǒng)分布式實踐的結(jié)論踪区，是基于CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency）吊骤，但每個應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點缎岗，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性（Eventual consistency）。
2PC
兩階段提交
階段一：提交事務(wù)請求（投票階段）（會阻塞）
階段二：執(zhí)行事務(wù)提交（執(zhí)行階段）
3PC
解決2PC的阻塞白粉，但還是可能造成數(shù)據(jù)不一致
階段一：CanCommit
階段二：PreCommit（將2pc的階段一分成兩部传泊，減少了阻塞）
階段三：doCommit（由于有階段一和二，這兒超時會提交鸭巴，會造成數(shù)據(jù)不一致）
paxos
Paxos的目的是讓整個集群的對某個值的變更達成一致眷细。
- phase 1
- a) proposer向網(wǎng)絡(luò)內(nèi)超過半數(shù)的acceptor發(fā)送prepare消息
- b) acceptor正常情況下回復(fù)promise消息
- phase 2
- a) 在有足夠多acceptor回復(fù)promise消息時，proposer發(fā)送accept消息
- b) 正常情況下acceptor回復(fù)accepted消息
raft
Raft 是一種為了管理復(fù)制日志的一致性算法鹃祖。它提供了和 Paxos 算法相同的功能和性能溪椎，但是它的算法結(jié)構(gòu)和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易構(gòu)建實際的系統(tǒng)。
Raft 將一致性問題分解成了三個相對獨立的子問題：
- 領(lǐng)導(dǎo)選舉：一個新的領(lǐng)導(dǎo)人需要被選舉出來校读，當(dāng)先存的領(lǐng)導(dǎo)人宕機的時候
- 日志復(fù)制：領(lǐng)導(dǎo)人必須從客戶端接收日志然后復(fù)制到集群中的其他節(jié)點沼侣，并且強制要求其他節(jié)點的日志保持和自己相同。
- 安全性：在 Raft 中安全性的關(guān)鍵是狀態(tài)機安全：如果有任何的服務(wù)器節(jié)點已經(jīng)應(yīng)用了一個確定的日志條目到它的狀態(tài)機中歉秫，那么其他服務(wù)器節(jié)點不能在同一個日志索引位置應(yīng)用一個不同的指令蛾洛。
系統(tǒng)可用性指標(biāo)
| 系統(tǒng)可用性% | 宕機時間/年 | 宕機時間/月 | 宕機時間/周 | 宕機時間/天 |
|---|---|---|---|---|
| 90% (1個9) | 36.5 天 | 72 小時 | 16.8 小時 | 2.4 小時 |
| 99% (2個9) | 3.65 天 | 7.20 小時 | 1.68 小時 | 14.4 分 |
| 99.9% (3個9) | 8.76 小時 | 43.8 分 | 10.1 分鐘 | 1.44 分 |
| 99.99% (4個9) | 52.56 分 | 4.38 分 | 1.01 分鐘 | 8.66 秒 |
| 99.999% (5個9) | 5.26 分 | 25.9 秒 | 6.05 秒 | 0.87 秒 |
各高可用方案
