一、分佈式事務簡介
1、轉賬經典案例
跨地區和機構的轉賬的業務在實際生活中非常常見，基礎流程如下：
賬戶01通過一系列服務和支付的流程，把錢轉入賬戶02，在這一過程中，如果賬戶01出現出賬成功，但是賬戶02沒有入賬，這就導致數據不一致，違反了基本的事務原則。基於數據歸屬在不同服務和不同的數據庫中，這種情況下的事務出錯被稱爲分佈式事務問題。
2、基本概念
分佈式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分佈式系統的不同節點之上。
如上的轉賬案例，看似只有一次的轉賬操，實際上由不同的服務不同數據庫的多個細節操作組成，這些無感知的細節操作分佈在不同服務上，甚至屬於不同的地區和應用，如何保證這些操作全部成功或者全部失敗，即保證不同數據庫間的數據一致性，這就是分佈式事務需要解決的核心問題。
3、分佈式事務特點
基於如下電商業務場景，基本分佈式的架構思路：
數據庫基於業務特點，進行分庫分表；
數據庫拆分，隨之就是業務的服務化(SOA)；
基於電商業務進行拆分，會出現常見的：訂單，用戶，庫存，物流等一系列的服務，管理不同的業務數據庫，在實際的下單支付應用場景下，需要同時操作用戶，訂單，庫存等多個服務，就必須保證數據一致性，下單支付成功，庫存必須就需要用到分佈式事務。
二、CAP基礎理論
1、基礎簡介
說到分佈式事務問題，必然會說下CAP理論，分佈式系統的三大指標：
Consistency：一致性
單個事務執行更新寫操作，操作結束成功返回，在同一時間的其他事務讀取的數據完全一致，不存在中間狀態。在分佈式的系統中描述：用戶下單支付，扣款，減庫存，生成物流，必須一致。例如限量打折促銷中，用戶下單後庫存沒減少，這就導致不一致問題。
Availability：可用性
服務必須一直處於可用的狀態，收到用戶的請求，服務器必須在有限的時間給出迴應，不管結果是處理成功或者處理失敗。
Partition tolerance：分區容錯
通俗說，在分佈式系統中，一個流程裏可能出現某個服務出錯情況，這是無法絕對避免的，在程序設計上要能容忍這種錯誤發生。
2、CP和AP模式
分佈式系統很難同時滿足一致性、可用性、分區容錯性三個特點，在大部分的系統架構中，都會選擇CP或者AP模式，即需要拋棄一個特點，說明一點，爲何P沒有拋棄，對於分佈式系統而言，分區容錯是該架構模式下的基本原則，不同的SOA服務和數據庫是比如會被部署到不同的節點下。所以如何解決C（一致性）和A（可用性）就成分佈式系統的最大痛點。
爲何不能同時滿足C和A，這也是基於分佈式架構特點看，不同服務直接不能保證通信是100%成功，一旦出現失敗情況，一致性和可用性就無法滿足。
既然強一致性無法保證，那退一步，給處理時間，最後結果保證一致性，也可以，這就涉及到BASE理論。
三、BASE基礎理論
1、基礎簡介
BASE理論是由eBay公司的架構師提出的，主要是對上述的CAP理論中一致性和可用性做的權衡結果，基於CAP定律逐步演化而來，核心思想；即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當策略實現數據的最終一致性。
Basically Available：基本可用
分佈式系統在發生故障的時，允許損失部分可用性。例如常見電商清倉甩賣時，爲保證主業務可以，一些不重要的服務直接降級提示。
Soft State：軟狀態
允許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的整體可用性。相對於原子性而言，要求多個節點的數據副本都是一致的，這是一種硬狀態。
Eventual Consistency：最終一致
強調的數據更新操作，即軟狀態必須有個時間期限，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。時間期限長短取決於延時、負載、數據同步等各種因素。
BASE理論提出是基於大規模高可用可擴展的分佈式系統架構，不同於關係型數據庫事務特點(ACID)的強一致性模型，通過犧牲強一致性來獲取更高的可用性，並允許數據在一段時間內是不一致的，但最終達到一致狀態。實際的業務場景下事物(ACID)基本特性和BASE理論也是要權衡考慮。
2、柔性事務
遵循BASE理論，利用業務特點，在指定期限內讓事務保持最終一致性，柔性事務是一種思想，從根本上看，就是業務模式對於事務過程中不一致性有一定的容忍度，可以留出足夠的時間執行事務最終一致的方法。
3、PAXOS算法
Paxos算法一種保障分佈式系統最終一致性的共識算法，利用的是選舉策略，少數服從多數的思想。PAXOS不要求對所有節點做實時同步，實質上是考慮到了分區情況下的可用性，通過減少完成一次事務需要的參與者個數，來保障系統的可用性。
例如：N個服務節點，有(N/2)+1個節點達成共識，則認爲系統達到了一致，並且按照Paxos原則，最終理論上也達到了一致，不會再改變，如此一來，只要保證有半數以上的服務存活，允許小部分服務掛掉，客戶可以與大部分服務節點通信，那麼就不會影響整體操作流程，也不需確保服務器全部處於工作狀態，容錯性非常好。操作影響的數據和結果隨後會被異步的同步到其他節點上，從而保證最終一致性。
四、服務間隔離
1、分佈式結構
分佈式系統架構的明顯特點，就是按照業務系統的功能，拆分成各種服務，每個服務下面都有自己獨立的數據庫，以此降低業務間的耦合度，隔離不同的數據庫保證系統最大的穩定性等。
例如上圖是電商系統中經典的業務場景，訂單-倉儲-物流的服務模式，不同服務提供不同的應用場景，服務間存在通信機制，以此實現服務的高可用。
2、隔離思想
分佈式的架構體系中，涉及一個根本思想邏輯：隔離；
服務和數據庫根據業務拆分，進而隔離開來，整個架構中某個服務掛掉，不會影響其他的服務繼續執行。例如上述1中：如果物流服務掛掉，影響的是用戶無法實時追蹤物流狀態，但是不會影響訂單的持續產生。
隔離的策略也是各有不同，常見的電商系統是典型的按照業務特點進行拆分，這種就是不同的業務場景下，使用不同的服務和數據庫；還有一種業務場景，多租戶平臺，針對大客戶提供獨立的服務和數據庫，對小客戶提供公服務和數據庫，這種策略比較現實：大客戶帶來收益多，完全覆蓋服務和數據庫的成本，必須保證不能被一些非必要因素影響。
不管是基於什麼策略拆分隔離，首先都必須面對數據庫設計的問題。
五、數據庫設計
1、拆分思想
數據庫在業務體系不大的情況，一般都是單庫出現，最多加一個備份庫以備不時之需，當業務體量不斷擴大，就會考慮拆分場景，例如常見的：水平拆分，垂直拆分策略。
水平拆分
首先把單表表分割N個結構相同的表，然後把數據按照策略分散到不同的表中，這是表層面；如果把表在分散在不同的數據庫中，這就是數據庫層面的水平拆分。
垂直拆分
把單表中數據按照不同特點，拆分成兩張不同的表，常見的策略是根據數據是修改多，還是讀取多，把修改頻繁的字段放一張表，讀取頻繁的放另一張表，這是表層面；如果根據業務特點，拆分不同庫，這就是數據庫層面。
2、拆分模式
讀寫分離
讀寫分離是數據庫拆分的最基本方式，實現起來難度也不大，只需要根據讀寫庫的配置，把業務中數據寫操作路由到寫庫，數據讀操作路由到讀庫即可。
這種方式實現的數據庫拆分雖然相對容易，如果出現主從複製掛掉的情況，就會導致數據讀不到，或者數據讀取延時，所以在強一致的要求的情況下，使用不多。
分庫分表
分庫分表主要用來解決單表數據量過大的問題，根據特定字段的路由規則，把數據分散到不同的庫，不同的表中。
通常是基於一些唯一值的哈希算法實現的分庫分表策略。也有一些成熟的中間件可以集成到項目直接使用，這種模式更多適用於單點數據的查詢的場景，可以基於路由快速定位數據所在的庫表。
業務分庫
基於業務特點拆分數據庫，是當前分佈式架構下，或者微服務模式的基礎用法，不同業務場景下數據放在一個庫，因爲數據關聯性很強，在使用的時候方便，同時與其他業務數據隔離開來，避免單點故障導致數據庫掛掉。
這種模式雖然看起來更合理，但是複雜度也是非常的陡，因爲兩種業務場景下的數據不可能絕對沒有關聯，比如訂單庫一定依賴用戶庫的信息，這就需要訂單服務和用戶服務之間需要通信，引發的問題就會很多。
用戶分庫
在多租戶場景下，會根據客戶流水大小提供不相同的服務和數據庫，這是一個十分現實的策略，畢竟可能一個大客戶的月流水超過幾個小客戶的總和。
既然可以根據客戶情況分庫，也可以基於其他策略，比如地區，常見雲服務的應用，選擇華南，華北，華東區之類的。
六、架構體系難點
這裏所提到的涉及問題，是指基於業務分庫模式下的出現的問題。
1、服務依賴
在分佈式架構體系下，不同服務都有各自的數據庫，但是數據之間一定是有關係的，服務A要用服務C的數據庫，就必須通過服務C提供的接口來獲取，這是基本機制，不然拆分服務和庫就沒意義了，這樣就會導致服務間產生依賴關係。
如上圖，如果訂單服務和論壇服務同時依賴用戶服務，那麼就要考慮如果用戶服務掛掉，會影響多大的範圍，做好權衡，還有一個關鍵點，如果多個服務依賴一個服務，那麼就要保證被依賴的服務有足夠的能力應對，例如這裏，如果訂單服務有10W的流量，論壇服務有10W的流量，那麼就要保證部署上用戶服務起碼要能承受20W的流量。
2、分佈式事務
既然數據庫在不同的服務下面，服務之間又存在依賴關係，那麼保證數據的事務一致性就是非常大的難題。
這裏基於支付業務的轉賬場景做一個簡單的演示，從數據源1的賬戶表中，向數據源2的賬戶表中操作轉賬，儘管在代碼層面看添加了事務最高級別的控制，但是卻沒有起到控制作用，導致出賬成功，但是入賬失敗，這就是典型的分佈式事務問題。
總結
以上就是小編整理的分佈式概述，如果感覺比較晦澀，沒關係，小編之前也有整理過架構寶典，需要深入瞭解學習的朋友，點擊即可閱覽，希望能夠幫到大家更好的學習！！！
喜歡請多多點贊評論轉發，關注小編，你們的支持就是小編最大的動力！！！