前言

隨著業(yè)務(wù)的拓展，功能越來越多。把所有的功能都放在同一個服務(wù)下，代碼混合交錯，造成維護困難，也容易造成某一小bug導(dǎo)致整個服務(wù)不可用。因此我們會按業(yè)務(wù)功能會拆分成多個不同的服務(wù)（微服務(wù)的形成），多個服務(wù)組成的系統(tǒng)，有個響亮的名字：分布式系統(tǒng)；而系統(tǒng)中的服務(wù)狀態(tài)我們該怎么去管理，有什么相關(guān)的理論呢？

• 分布式和集群
• 數(shù)據(jù)庫事務(wù)
• 分布式事務(wù)
• 分布式數(shù)據(jù)一致性
• CAP 理論
• BASE理論

分布式和集群

• 分布式是指通過網(wǎng)絡(luò)連接的多個服務(wù)或組件，通過交換信息協(xié)作而形成的系統(tǒng)
• 集群是指同一種服務(wù)組件的多個實例形成的整體
• 這兩個概念并不完全沖突，分布式系統(tǒng)也可以是一個集群。zookeeper集群也是一種分布式系統(tǒng)，它的服務(wù)之間會互相通信協(xié)作
• 集群不是分布式系統(tǒng)的情況，比如多個經(jīng)過負載均衡的HTTP服務(wù)器，它們之間不會互相通信，如果不帶上負載均衡的部分的話，則不能稱作分布式系統(tǒng)

數(shù)據(jù)庫事務(wù)

• 事務(wù)是基于數(shù)據(jù)進行操作，需要保證事務(wù)的數(shù)據(jù)通常存儲在數(shù)據(jù)庫中，所以介紹到事務(wù)，就不得不介紹數(shù)據(jù)庫事務(wù)的 ACID 特性
• 原子性（Atomicity），整個事務(wù)中的所有操作，要么全部完成，要么全部不完成，不可能停滯在中間某個環(huán)節(jié)
• 一致性（Consistency），在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫數(shù)據(jù)的一致性約束沒有被破壞
• 隔離性（Isolation），隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致
• 持久性（Durability），事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失

分布式事務(wù)

• 分布式系統(tǒng)一般由多個獨立的子系統(tǒng)組成，多個子系統(tǒng)通過網(wǎng)絡(luò)通信互相協(xié)作配合完成各個功能；這個協(xié)作過程需要保證各個系統(tǒng)的數(shù)據(jù)一致性，我們稱這種跨系統(tǒng)的事務(wù)為分布式事務(wù)
• 上面的場景會存在多種情況；庫存服務(wù)和訂單服務(wù)全部成功。或者庫存服務(wù)和訂單服務(wù)部分成功，而傳統(tǒng)的單機事務(wù)理論不再適用

分布式事務(wù)的難點

• 原子性：事務(wù)操作跨不同節(jié)點，當(dāng)多個節(jié)點某一節(jié)點操作失敗時，需要保證多節(jié)點操作的要么什么都不做，要么都做
• 一致性：當(dāng)發(fā)生網(wǎng)絡(luò)傳輸故障或者節(jié)點故障，節(jié)點間數(shù)據(jù)復(fù)制通道中斷，在進行事務(wù)操作時需要保證數(shù)據(jù)一致性
• 隔離性：在分布式事務(wù)控制中，可能會出現(xiàn)提交不同步的現(xiàn)象，會出現(xiàn)“部分已經(jīng)提交”的事務(wù)

分布式數(shù)據(jù)一致性

• ACID并不適合分布式事務(wù)，而分布式事務(wù)的難點涉及的問題，最終影響是導(dǎo)致數(shù)據(jù)出現(xiàn)不一致，因此在分布式系統(tǒng)會著重關(guān)注保證系統(tǒng)的一致性。

CAP理論

• 前面介紹到的分布式事務(wù)的難點涉及的問題，最終影響是導(dǎo)致數(shù)據(jù)出現(xiàn)不一致，下面對分布式系統(tǒng)的一致性問題進行理論分析，后面將基于這些理論進行分布式方案的介紹(可用性和一致性的沖突:CAP理論)
• 一致性（Consistence）: 所有節(jié)點訪問最新相同的數(shù)據(jù)副本
• 可用性（Availability）: 非故障的節(jié)點在合理的時間內(nèi)返回合理的響應(yīng)（不是錯誤或者超時的響應(yīng)）
• 分區(qū)容錯性（Partition tolerance）: 分布式系統(tǒng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的時候，仍然能夠?qū)ν馓峁┓?wù)

?

當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)的時候，如果我們要繼續(xù)服務(wù)，那么強一致性和可用性只能 2 選 1。也就是說當(dāng)網(wǎng)絡(luò)分區(qū)之后 P 是前提，決定了 P 之后才有 C 和 A 的選擇。也就是說分區(qū)容錯性（Partition tolerance）我們是必須要實現(xiàn)的

?

為啥無法同時保證 CA 呢？

若系統(tǒng)出現(xiàn)“分區(qū)”，系統(tǒng)中的某個節(jié)點在進行寫操作。為了保證一致性C， 必須要禁止其他節(jié)點的讀寫操作，這就和 A 發(fā)生沖突了；如果為了保證A，其他節(jié)點的讀寫操作正常的話，那就無法保證數(shù)據(jù)一致性，和C沖突

CAP 實際應(yīng)用案例

• ZooKeeper保證的是CP。任何時刻對ZooKeeper的讀請求都能得到一致性的結(jié)果，但是ZooKeeper不保證每次請求的可用性比如在Leader選舉過程中或者半數(shù)以上的機器不可用的時候服務(wù)就是不可用的
• Eureka保證的則是AP。Eureka在設(shè)計的時候就是優(yōu)先保證A（可用性）。在 Eureka中不存在什么Leader節(jié)點，每個節(jié)點都是一樣的、平等的。因此 Eureka 不會像 ZooKeeper 那樣出現(xiàn)選舉過程中或者半數(shù)以上的機器不可用的時候服務(wù)就是不可用的情況。Eureka 保證即使大部分節(jié)點掛掉也不會影響正常提供服務(wù)，只要有一個節(jié)點是可用的就行了。只不過這個節(jié)點上的數(shù)據(jù)可能并不是最新的

BASE理論

• BASE是Basically Available（基本可用） 、Soft-state（軟狀態(tài)） 和 Eventually Consistent（最終一致性）。BASE理論是對CAP中一致性(C)和可用性(A)權(quán)衡的結(jié)果
• 最終一致性是弱一致性的一個特例，系統(tǒng)會保證在一定時間內(nèi)，能夠達到一個數(shù)據(jù)一致的狀態(tài)

基本可用

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時候，允許損失部分可用性；那什么又是允許損失部分可用性呢？

• 響應(yīng)時間上的損失: 正常情況下，處理用戶請求需要0.5s返回結(jié)果，但是由于系統(tǒng)出現(xiàn)故障，處理用戶請求的時間變?yōu)?s
• 系統(tǒng)功能上的損失：正常情況下，用戶可以使用系統(tǒng)的全部功能，但是由于系統(tǒng)訪問量突然劇增，系統(tǒng)的部分非核心功能無法使用

軟狀態(tài)

• 軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)（CAP理論中的數(shù)據(jù)不一致），并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點的數(shù)據(jù)副本之間進行數(shù)據(jù)同步的過程存在延時

最終一致性

• 最終一致性強調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后，最終能夠達到一個一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性

歡迎指正文中錯誤

參考文章

• CAP和BASE理論了解么？可以結(jié)合實際案例說下不？
• 分布式與集群的區(qū)別是什么?^[1]
• 數(shù)據(jù)一致性問題^[2]

Reference