前言
隨著業務的拓展，功能越來越多，把所有的功能都放在同一個服務下，代碼混合交錯，造成維護困難，也容易造成某一小bug導致整個服務不可用，因此我們會按業務功能會拆分成多個不同的服務（微服務的形成），多個服務組成的系統，有個響亮的名字：分布式系統；而系統中的服務狀態我們該怎么去管理，有什么相關的理論呢？
- 分布式和集群
- 資料庫事務
- 分布式事務
- 分布式資料一致性
- CAP 理論
- BASE理論
關注公眾號，一起交流，微信搜一搜: 潛行前行
分布式和集群
- 分布式是指通過網路連接的多個服務或組件，通過交換資訊協作而形成的系統
- 集群是指同一種服務組件的多個實體二形成的整體
- 這兩個概念并不完全沖突，分布式系統也可以是一個集群，zookeeper集群也是一種分布式系統，它的服務之間會互相通信協作
- 是集群不是分布式系統的情況，比如多個經過負載均衡的HTTP服務器，它們之間不會互相通信，如果不帶上負載均衡的部分的話，則不能稱作分布式系統
資料庫事務
- 事務是基于資料進行操作，需要保證事務的資料通常存盤在資料庫中，所以介紹到事務，就不得不介紹資料庫事務的 ACID 特性
- 原子性（Atomicity），整個事務中的所有操作，要么全部完成，要么全部不完成，不可能停滯在中間某個環節
- 一致性（Consistency），在事務開始之前和事務結束以后，資料庫資料的一致性約束沒有被破壞
- 隔離性（Isolation），隔離性可以防止多個事務并發執行時由于交叉執行而導致資料的不一致
- 持久性（Durability），事務處理結束后，對資料的修改就是永久的，即便系統故障也不會丟失
分布式事務
- 分布式系統一般由多個獨立的子系統組成，多個子系統通過網路通信互相協作配合完成各個功能；這個協作程序需要保證各個系統的資料一致性，我們稱這種跨系統的事務為分布式事務
- 上面的場景會存在多種情況；庫存服務和訂單服務全部成功，或者庫存服務和訂單服務部分成功，而傳統的單機事務理論不再適用
分布式事務的難點
- 原子性：事務操作跨不同節點，當多個節點某一節點操作失敗時，需要保證多節點操作的要么什么都不做，要么都做
- 一致性：當發生網路傳輸故障或者節點故障，節點間資料復制通道中斷，在進行事務操作時需要保證資料一致性
- 隔離性：在分布式事務控制中，可能會出現提交不同步的現象，會出現“部分已經提交”的事務
分布式資料一致性
- ACID并不適合分布式事務，而分布式事務的難點涉及的問題，最終影響是導致資料出現不一致，因此在分布式系統會著重關注保證系統的一致性，
CAP理論
- 前面介紹到的分布式事務的難點涉及的問題，最終影響是導致資料出現不一致，下面對分布式系統的一致性問題進行理論分析，后面將基于這些理論進行分布式方案的介紹(可用性和一致性的沖突:CAP理論)
- 一致性（Consistence）: 所有節點訪問最新相同的資料副本
- 可用性（Availability）: 非故障的節點在合理的時間內回傳合理的回應（不是錯誤或者超時的回應）
- 磁區容錯性（Partition tolerance）: 分布式系統出現網路磁區的時候，仍然能夠對外提供服務
當發生網路磁區的時候，如果我們要繼續服務，那么強一致性和可用性只能 2 選 1，也就是說當網路磁區之后 P 是前提，決定了 P 之后才有 C 和 A 的選擇，也就是說磁區容錯性（Partition tolerance）我們是必須要實作的
為啥無同時保證 CA 呢？
若系統出現“磁區”，系統中的某個節點在進行寫操作，為了保證一致性C， 必須要禁止其他節點的讀寫操作，這就和 A 發生沖突了；如果為了保證A，其他節點的讀寫操作正常的話，那就無法保證資料一致性，和C沖突
CAP 實際應用案例
- ZooKeeper保證的是CP， 任何時刻對ZooKeeper的讀請求都能得到一致性的結果，但是ZooKeeper不保證每次請求的可用性比如在Leader選舉程序中或者半數以上的機器不可用的時候服務就是不可用的
- Eureka保證的則是AP， Eureka在設計的時候就是優先保證A（可用性），在 Eureka中不存在什么Leader節點，每個節點都是一樣的、平等的，因此 Eureka 不會像 ZooKeeper 那樣出現選舉程序中或者半數以上的機器不可用的時候服務就是不可用的情況，Eureka 保證即使大部分節點掛掉也不會影響正常提供服務，只要有一個節點是可用的就行了，只不過這個節點上的資料可能并不是最新的
BASE理論
- BASE是Basically Available（基本可用） 、Soft-state（軟狀態） 和 Eventually Consistent（最終一致性），BASE理論是對CAP中一致性?和可用性(A)權衡的結果
- 最終一致性是弱一致性的一個特例，系統會保證在一定時間內，能夠達到一個資料一致的狀態
基本可用
基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性；那什么又是允許損失部分可用性呢？
- 回應時間上的損失: 正常情況下，處理用戶請求需要0.5s回傳結果，但是由于系統出現故障，處理用戶請求的時間變為3s
- 系統功能上的損失：正常情況下，用戶可以使用系統的全部功能，但是由于系統訪問量突然劇增，系統的部分非核心功能無法使用
軟狀態
- 軟狀態指允許系統中的資料存在中間狀態（CAP理論中的資料不一致），并認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的資料副本之間進行資料同步的程序存在延時
最終一致性
- 最終一致性強調的是系統中所有的資料副本，在經過一段時間的同步后，最終能夠達到一個一致的狀態，因此，最終一致性的本質是需要系統保證最終資料能夠達到一致，而不需要實時保證系統資料的強一致性
歡迎指正文中錯誤
參考文章
- CAP和BASE理論了解么？可以結合實際案例說下不？
- 分布式與集群的區別是什么?
- 資料一致性問題
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/274544.html
標籤：其他
上一篇：使用Spring cloud alibaba簡單構建微服務專案以及注冊中心Nacos與Spirng的整合原理（一）