http://horicky.blogspot.com/2009/11/nosql-patterns.html

A brief history of Consensus_ 2PC and Transaction Commit (譯) 對于一致性問題很好的綜述

2 Phase Commit(譯)

?

Master Slave (or Single Master)Model

Under this model, each data partition has a single master and multiple slaves.

All update requests has to go to the master where update is applied and then asynchronously propagated to the slaves. Notice that there is a time window of data lost if the master crashes before it propagate its update to any slaves, so some system will wait synchronously for the update to be propagated to at least one slave.

Read requests can go to any replicas if the client can tolerate some degree of data staleness. This is where the read workload is distributed among many replicas. If the client cannot tolerate staleness for certain data, it also need to go to the master.

Master Slave model works very well in general when the application has a high read/write ratio. It also works very well when the update happens evenly in the key range. So it is the predominant model of data replication.

主從模式, 最傳統(tǒng)和簡單的模式
寫操作, 所有寫操作通過master, master寫成功即返回, 然后master負(fù)責(zé)異步propagate到各個slave節(jié)點(diǎn). 為了增強(qiáng)可靠性, 也可以等master至少propagate一個slave后再返回.
讀操作, 如果可以容忍舊數(shù)據(jù), 從任一節(jié)點(diǎn)讀. 如果不能容忍, 所有讀操作也要通過master
缺點(diǎn), 單點(diǎn)問題, 以及master負(fù)載過重
解決辦法, 參考Google的設(shè)計(jì), GFS, Bigtable

?

去中心化的方案, Quorum Based 2PC

由于主從模式比較成熟和簡單
對于分布式的場景, 去中心化的設(shè)計(jì)(無固定master), 如何保證一致性? 這才是近年來, 研究的難點(diǎn)和熱點(diǎn)

JimGray在“Notes on Database Operating Systems” (1979)中描述了兩階段提交(2PC)

二階段提交(2PC)協(xié)議

傳統(tǒng)的2PC協(xié)議用于保證分布式事務(wù)的原子性, 分布式存放的數(shù)據(jù), 必須要保證同時更新成功或失敗.
所以coordinator必須在第一階段, 發(fā)送prepare請求保證所有的數(shù)據(jù)復(fù)本當(dāng)前都是ready for update, 在得到所有復(fù)本回應(yīng)后再開始第二階段, 正真的commit
這里就比基于master復(fù)雜, 不是僅僅master同意, 而是要所有的node都同意, 才能commit

To provide "strict consistency", we can use a traditional 2PC protocol to bring all replicas to the same state at every update.

Lets say there is N replicas for a data.
When the data is update, there is a "prepare" phase where the coordinator ask every replica to confirm whether each of them is ready to perform the update.
Each of the replica will then write the data to a log file and when success, respond to the coordinator.
After gathering all replicas responses positively, the coordinator will initiate the second "commit" phase and then ask every replicas to commit.
Each replica then write another log entry to confirm the update.

Notice that there are some scalability issue as the coordinator need to "synchronously" wait for quite a lot of back and forth network roundtrip and disk I/O to complete.
On the other hand, if any one of the replica crashes, the update will be unsuccessful. As there are more replicas, chance of having one of them increases. Therefore, replication is hurting the availability rather than helping. This make traditional 2PC not a popular choice for high throughput transactional system.
2PC協(xié)議的最大的問題是沒有考慮節(jié)點(diǎn)fail的case, 任意的節(jié)點(diǎn)的fail都會導(dǎo)致block.
Dale Skeen在“NonBlocking Commit Protocols” (1981)中指出，對于一個分布式系統(tǒng), 需要3階段的提交算法來避免2PC中的阻塞(block)問題, 但問題關(guān)鍵很難找到一個好的3PC算法

對于阻塞問題,? 其實(shí)想當(dāng)然的是可用通過timeout來解決, 當(dāng)然問題沒有那么簡單,
問題的核心在于，你無法區(qū)分一個進(jìn)程到底是終止了還是正在以極低的速度執(zhí)行，這使得在異步系統(tǒng)中的錯誤處理幾乎是不可能的
Fischer, Lynch 和 Paterson在"Impossibility of distributed consensus with one faulty process” (1985) 中證明了這一點(diǎn)

對于一個異步系統(tǒng)來說即使只有一個進(jìn)程出錯，分布式一致性也是不可能達(dá)到的，這就是著名的FLP結(jié)論

人們意識到一個分布式算法具有兩個屬性: 安全性(safety)和活性(liveness), 2PC極具安全性,卻缺乏活性

在1986年的會議上, 分布式事務(wù)被認(rèn)為是一個新的一致性問題，稱為uniform consensus (參見“Uniform consensus is harder than consensus” (2000))

With uniform consensus all processes must agree on a value, even the faulty ones - a transaction should only commit if all RMs are prepared to commit. Most forms of consensus are only concerned with having the non-faulty processes agree. Uniform consensus is more difficult than general consensus.

個人理解, 在節(jié)點(diǎn)或進(jìn)程失效的時候, 仍然可以達(dá)成一致性, 而不會存在2PC的block的情況

Paxos, quorum based 2PC

最終Lamport在“The Part-Time Parliament” (submitted in 1990, published 1998)中提出了Paxos一致性算法, 后來Lamport又發(fā)表了“Paxos Made Simple (2001).

用于解決uniform consensus的問題.

Paxos的核心, 在于quorum based 2PC, 在分布式環(huán)境既然無法要求所有節(jié)點(diǎn)能夠正常響應(yīng)
那么Paxos只需要majority(多數(shù)派)正常響應(yīng), 就可以達(dá)成一致性決議, 從而避免任一節(jié)點(diǎn)fail導(dǎo)致的block
但問題在于, 那些沒有響應(yīng)的節(jié)點(diǎn)(因?yàn)閒ail或網(wǎng)絡(luò)等原因)怎樣保證其一致性?
答案是, 任何一致性決議的達(dá)成都需要majority的accept, 任意兩個majority集合都一定有交集(至少一個節(jié)點(diǎn))
而任一節(jié)點(diǎn)都只能accept一次proposal(除非具有相同的value), 所以當(dāng)一個一致性決議達(dá)成的情況下, 不可能有不同value新決議被達(dá)成(即使在部分節(jié)點(diǎn)fail的情況下)
從而即使fail的節(jié)點(diǎn)wake-up后, 仍然可以簡單的從其他majority節(jié)點(diǎn)learn并保證一致性
這就是為什么叫quorum based 2PC, 其實(shí)本質(zhì)就是 R +W > N
并且在一段時間內(nèi)無法獲得majority的響應(yīng)時, 可以隨時主動放棄現(xiàn)有提案, 并提出更高編號的提案, 進(jìn)一步避免block

傳統(tǒng)2PC只是Paxos的一種特殊case (當(dāng)W = N and R = 1)
A more efficient way is to use the quorum based 2PC (e.g. PAXOS).
In this model, the coordinator only need to update W replicas (rather than all N replicas) synchronously. The coordinator still write to all the N replicas but only wait for positive acknowledgment for any W of the N to confirm. This is much more efficient from a probabilistic standpoint.

As you can see, the quorum based 2PC can be considered as a general 2PC protocol where the traditional 2PC is a special case where W = N and R = 1. The general quorum-based model allow us to pick W and R according to our tradeoff decisions between read and write workload ratio.

轉(zhuǎn)載于:https://www.cnblogs.com/fxjwind/archive/2013/04/03/2998396.html

總結(jié)

以上是生活随笔為你收集整理的Strong Consistency, 强一致性技术概述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。