Spring cloud---分散式
一、 分散式的定義 和 叢集的區別
（1） 分散式定義
分散式是將不同的業務模組部署在不同的伺服器上或者同一個業務務拆分成多個子業務部署在不同的伺服器上，多個子業務之間配合完成整個業務，解決高併發的問題。分散式好處在於提高子業務的效率到達提高整體業務的服務能力。從實體來看，單一伺服器處理整個業務流程，如果流程簡單或者是請求量不夠大，那麼也能支撐業務。但是當業務逐漸複雜，請求量增大，單例伺服器明顯不能支撐龐大的業務系統。如果使用分散式，將整體業務拆分成多個子業務，那麼多個子業務之間就可以支撐整體業務系統。之所以能支撐龐大的業務，是因為分散式可以用n個伺服器來支撐一個業務，相對單一伺服器來說更加的高效。
分散式帶來的好處是能夠處理大量的請求，但是同樣也附帶一些問題最多的還是一致性。分散式在每個環節上都有對應的需求，比如Load Balance、DB、Cache和檔案等等，並且當分散式節點之間有關聯時，還得考慮之間的通訊，另外，節點非常多的時候，得有監控和管理來支撐。這樣看起來，分散式是一個非常龐大的體系，只不過你可以根據具體需求進行適當地裁剪。按照最完備的分散式體系來看，可以由以下模組組成：
- 分散式任務處理服務：負責具體的業務邏輯處理
- 分散式節點註冊和查詢：負責管理所有分散式節點的命名和物理資訊的註冊與查詢，是節點之間聯絡的橋樑
- 分散式DB：分散式結構化資料存取
- 分散式Cache：分散式快取資料（非持久化）存取
- 分散式檔案：分散式檔案存取
- 網路通訊：節點之間的網路資料通訊
- 監控管理：蒐集、監控和診斷所有節點執行狀態
- 分散式程式語言：用於分散式環境下的專有程式語言，比如Elang、Scala
- 分散式演算法：為解決分散式環境下一些特有問題的演算法，比如解決一致性問題的Paxos演算法
（2）叢集的定義
叢集的核心概念是多個伺服器做同一個業務或者是同一整體業務的物理形態，不同於分散式的將業務拆分。抽象來看叢集很像橫向擴充套件，水平擴充套件到多臺伺服器，而分散式是縱向切割，提高切割點的效能以達到整體提升的效率。很多時候分散式的切割點包含了叢集（為了達到高可用）。
二、 一致性理論
說到分散式就不得不關注分散式的一致性，這個是分散式的致命問題。而在分散式領域主要討論的是強一致性(實時性)和最終一致性。典型的案例：
- 兩階段提交（2PC，Two-Phase-Commit）方案
- eBay時間佇列方案
- TCC補償時間
- 快取資料最終一致性
（1）CAP理論
定理：
- 一致性（Consistency） 資料一致更新，所有資料變動都是同步更新的
- 可用性（Avalibility） 分散式事務能一直保持可用狀態。當用戶傳送一個請求之後，伺服器在有限時間返回資料
- 分割槽容忍性（Partition Tolerance） 可靠性
（2）Base理論
核心思想:
- 基本可用（BasicallyAvailable）：指分散式系統在出現故障時，允許損失部分的可用性來保證核心可用。
- 軟狀態（SoftState）：指允許分散式系統存在中間狀態，該中間狀態不會影響到系統的整體可用性。
- 最終一致性（EventualConsistency）：指分散式系統中的所有副本資料經過一定時間後，最終能夠達到一致的狀態。
三、一致性模型
資料的一致性模型可以分成以下 3 類：
- 強一致性：資料更新成功後，任意時刻所有副本中的資料都是一致的，一般採用同步的方式實現。
- 弱一致性：資料更新成功後，系統不承諾立即可以讀到最新寫入的值，也不承諾具體多久之後可以讀到。
- 最終一致性：弱一致性的一種形式，資料更新成功後，系統不承諾立即可以返回最新寫入的值，但是保證最終會返回上一次更新操作的值。
分散式系統資料的強一致性、弱一致性和最終一致性可以通過Quorum NRW演算法分析。
https://en.wikipedia.org/wiki/Quorum(distributedcomputing)
四、分散式解決方案 （1） 2PC方案——強一致性
2PC的核心原理是通過提交分階段和記日誌的方式，記錄下事務提交所處的階段狀態，在元件宕機重啟後，可通過日誌恢復事務提交的階段狀態，並在這個狀態節點重試，如Coordinator重啟後，通過日誌可以確定提交處於Prepare還是PrepareAll狀態，若是前者，說明有節點可能沒有Prepare成功，或所有節點Prepare成功但還沒有下發Commit，狀態恢復後給所有節點下發RollBack；若是PrepareAll狀態，需要給所有節點下發Commit，資料庫節點需要保證Commit冪等。
2PC方案的問題：
- 同步阻塞。
- 資料不一致。
- 單點問題。
- 增加超時機制。
- 兩階段之間插入準備階段。
Paxos：https://en.wikipedia.org/wiki/Paxos(computerscience)
Raft：https://raft.github.io/
（2） eBay 事件佇列方案——最終一致性 eBay 的架構師Dan Pritchett，曾在一篇解釋BASE 原理的論文《Base：An Acid Alternative》中提到一個eBay 分散式系統一致性問題的解決方案。它的核心思想是將需要分散式處理的任務通過訊息或者日誌的方式來非同步執行，訊息或日誌可以存到本地檔案、資料庫或訊息佇列，再通過業務規則進行失敗重試，它要求各服務的介面是冪等的。
描述的場景為，有使用者表user 和交易表transaction，使用者表儲存使用者資訊、總銷售額和總購買額，交易表儲存每一筆交易的流水號、買家資訊、賣家資訊和交易金額。如果產生了一筆交易，需要在交易表增加記錄，同時還要修改使用者表的金額
論文中提出的解決方法是將更新交易表記錄和使用者表更新訊息放在一個本地事務來完成，為了避免重複消費使用者表更新訊息帶來的問題，增加一個操作記錄表updates_applied來記錄已經完成的交易相關的資訊。
這個方案的核心在於第二階段的重試和冪等執行。失敗後重試，這是一種補償機制，它是能保證系統最終一致的關鍵流程。
（3）TCC （Try-Confirm-Cancel）補償模式——最終一致性 某業務模型如圖，由服務 A、服務B、服務C、服務D 共同組成的一個微服務架構系統。服務A 需要依次呼叫服務B、服務C 和服務D 共同完成一個操作。當服務A 呼叫服務D 失敗時，若要保證整個系統資料的一致性，就要對服務B 和服務C 的invoke 操作進行回滾，執行反向的revert 操作。回滾成功後，整個微服務系統是資料一致的。
實現關鍵要素：
- 服務呼叫鏈必須被記錄下來。
- 每個服務提供者都需要提供一組業務邏輯相反的操作，互為補償，同時回滾操作要保證冪等。
- 必須按失敗原因執行不同的回滾策略。
（4） 快取資料最終一致性
在我們的業務系統中，快取（Redis 或者Memcached）通常被用在資料庫前面，作為資料讀取的緩衝，使得I/O 操作不至於直接落在資料庫上。以商品詳情頁為例，假如賣家修改了商品資訊，並寫回到資料庫，但是這時候使用者從商品詳情頁看到的資訊還是從快取中拿到的過時資料，這就出現了快取系統和資料庫系統中的資料不一致的現象。
要解決該場景下快取和資料庫資料不一致的問題我們有以下兩種解決方案：
為快取資料設定過期時間。當快取中資料過期後，業務系統會從資料庫中獲取資料，並將新值放入快取。這個過期時間就是系統可以達到最終一致的容忍時間。更新資料庫資料後同時清除快取資料。資料庫資料更新後，同步刪除快取中資料，使得下次對商品詳情的獲取直接從資料庫中獲取，並同步到快取。
參考連結：https://mp.weixin.qq.com/s/QMRTQEnE8BdNYHOKR0tkoA