1：分散式事物的理解： 

     分散式事務就是指事務的參與者、支援事務的伺服器、資源伺服器以及事務管理器分別位於不同的分散式系統的不同節點之上。就是一次大的操作由不同的小操作組成，這些小的操作分佈在不同的服務節點上，分散式事務需要保證這些小操作要麼全部成功，要麼全部失敗;本質上來說，分散式事務就是為了保證不同資料庫的資料一致性。

2：分散式事物產生的原因：

a）資料庫分庫分表;

   當資料庫單表一年產生的資料超過1000W，那麼就要考慮分庫分表,簡單的說就是原來的一個數據庫變成了多個數據庫,這時候，如果一個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分散式事務。

b)應用SOA化；

就是業務的服務化。比如原來單機支撐了整個電商網站，現在對整個網站進行拆解，分離出了訂單中心、使用者中心、庫存中心等,對於訂單中心，有專門的資料庫儲存訂單資訊，使用者中心也有專門的資料庫儲存使用者資訊，庫存中心也會有專門的資料庫儲存庫存資訊,如果要同時對訂單和庫存進行操作，那麼就會涉及到訂單資料庫和庫存資料庫，為了保證資料一致性，就需要用到分散式事務。

3）分散式的使用場景：

支付：一筆支付，是對買家賬戶進行扣款，同時對賣家賬戶進行加錢，這些操作必須在一個事務裡執行，要麼全部成功，要麼全部失敗，並且賣家賬戶對應賣家資料庫,買家對應買家的資料庫，對不同資料庫的操作必然需要引入分散式事務。

線上下單：在電商平臺下單，往往會涉及到兩個動作，一個是扣庫存，第二個是更新訂單狀態,庫存和訂單一般屬於不同的資料庫，需要使用分散式事務保證資料一致性。

4）常見的分散式事物解決方案：

a）基於XA協議的兩階段提交，

    XA是一個分散式事務協議,XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現,而事務管理器作為全域性的排程者，負責各個本地資源的提交和回滾。

 XA協議比較簡單，而且一旦商業資料庫實現了XA協議，使用分散式事務的成本也，XA也有致命的缺點，那就是效能不理想,往往併發量很高，XA無法滿足高併發場景。

b)訊息事務+最終一致性

所謂的訊息事務就是基於訊息中介軟體的兩階段提交，本質上是對訊息中介軟體的一種特殊利用，它是將本地事務和發訊息放在了一個分散式事務裡，保證要麼本地操作成功成功並且對外發訊息成功，要麼兩者都失敗，開源的RocketMQ就支援這一特性。

具體原理：

其執行的順序：

b.1)A系統向訊息中介軟體傳送一條預備訊息;

b.2)訊息中介軟體儲存預備訊息並返回成功;

b.3)訊息中介軟體儲存預備訊息並返回成功；

b.4)A傳送提交訊息給訊息中介軟體；

對於這個順序執行的分析：

   步驟一出錯，則整個事務失敗，不會執行A的本地操作;

   步驟二出錯，則整個事務失敗，不會執行A的本地操作；

   步驟三出錯，這時候需要回滾預備訊息,回滾方法,：A系統實現一個訊息中介軟體的回撥介面,訊息中介軟體會去不斷執行回撥介面，檢查A事務執行是否執行成功，如果失敗則回滾預備訊息。

 步驟四出錯,這時候A的本地事務是成功的，回滾本地A操作的成功,不需要回滾：其實通過回撥介面，訊息中介軟體能夠檢查到A執行成功了，這時候其實不需要A發提交訊息了，訊息中介軟體可以自己對訊息進行提交，從而完成整個訊息事務。

c）高併發場景下基於訊息中介軟體的兩階段提交的分散式事物：

 比如：將一個分散式事務拆成一個訊息事務（A系統的本地操作+發訊息）+B系統的本地操作

 B系統的操作由訊息驅動，只要訊息事務成功，那麼A操作一定成功，訊息也一定發出來了，這時候B會收到訊息去執行本地操作。如果B本地操作失敗，訊息會重投,直到B操作成功。這樣就變相地實現了A與B的分散式事務。

雖然上面的方案能夠完成A和B的操作，但是A和B並不是嚴格一致的，而是最終一致的,當然，這種玩法也是有風險的，如果B一直執行不成功，那麼一致性會被破壞，具體要不要玩，還是得看業務能夠承擔多少風險。

d）TCC程式設計模式,

TCC程式設計模式，也是兩階段提交的一個變種。

TCC提供了一個程式設計框架，將整個業務邏輯分為三塊：Try、Confirm和Cancel三個操作。

  以線上下單為例：Try階段會去扣庫存,Confirm階段則是去更新訂單狀態，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存,TCC就是通過程式碼人為實現了兩階段提交，不同的業務場景所寫的程式碼都不一樣，複雜度也不一樣，因此，這種模式並不能很好地被複用。

4)總結：

分散式事務，本質上是對多個數據庫的事務進行統一控制,按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分散式事務;部分控制就是各種變種的兩階段提交，包括上面提到的訊息事務+最終一致性、TCC模式;完全控制就是完全實現兩階段提交。

分散式理論    

分為   CAP定理 and  BASE理論

 CAP定理

他指出WEB服務無法同時滿足一下3個屬性：

• 一致性(Consistency) ： 客戶端知道一系列的操作都會同時發生(生效)
• 可用性(Availability) ： 每個操作都必須以可預期的響應結束
• 分割槽容錯性(Partition tolerance) ： 即使出現單個元件無法可用,操作依然可以完成

具體地講在分散式系統中，在任何資料庫設計中，一個Web應用至多隻能同時支援上面的兩個屬性。顯然，任何橫向擴充套件策略都要依賴於資料分割槽。因此，設計人員必須在一致性與可用性之間做出選擇。

這個定理在迄今為止的分散式系統中都是適用的

資料庫的2PC（兩階段提交） 又叫做 XA Transactions。

，XA 是一個兩階段提交協議，該協議分為以 下兩個階段：

• 第一階段：事務協調器要求每個涉及到事務的資料庫預提交(precommit)此操作，並反映是否可以提交.
• 第二階段：事務協調器要求每個資料庫提交資料。

其中，如果有任何一個數據庫否決此次提交，那麼所有資料庫都會被要求回滾它們在此事務中的那部分資訊。這樣做的缺陷是什麼呢? 咋看之下我們可以在資料庫分割槽之間獲得一致性。

如果CAP 定理是對的，那麼它一定會影響到可用性。

BASE理論

• Basically Available（基本可用）
• Soft state（軟狀態）
• Eventually consistent（最終一致性）

BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

通過兩種手段來擴充套件我們的資料服務

1）資料分割槽：就是把資料分塊放在不同的伺服器上（如：uid % 16，一致性雜湊等）。

    2）資料映象：讓所有的伺服器都有相同的資料，提供相當的服務。

，資料服務的高可用性只能通過第二種方法來完成——資料的冗餘儲存  但是，加入更多的機器，會讓我們的資料服務變得很複雜，尤其是跨伺服器的事務處理，也就是跨伺服器的資料一致性

簡單說來：

1）要想讓資料有高可用性，就得寫多份資料。

2）寫多份的問題會導致資料一致性的問題。

3）資料一致性的問題又會引發效能問題

資料庫分庫分表( 單表資料量達到1000W)

目的就在於減少資料庫的負擔，縮短查詢時間。

資料庫分散式核心內容無非就是資料切分（Sharding），以及切分後對資料的定位、整合。資料切分就是將資料分散儲存到多個數據庫中，使得單一資料庫中的資料量變小，通過擴充主機的數量緩解單一資料庫的效能問題，從而達到提升資料庫操作效能的目的。

為兩種切分模式 ：

一種是按照不同的表（或者Schema）來切分到不同的資料庫（主機）之上，這種切可以稱之為資料的垂直（縱向）切分；

另外一種則是根據表中的資料的邏輯關係，將同一個表中的資料按照某種條件拆分到多臺資料庫（主機）上面，這種切分稱之為資料的水平（橫向）切分。

垂直切分

即業務切分

垂直分庫就是根據業務耦合性，將關聯度低的不同表儲存在不同的資料庫。做法與大系統拆分為多個小系統類似，按業務分類進行獨立劃分。與"微服務治理"的做法相似，每個微服務使用單獨的一個數據庫。

垂直分表是基於資料庫中的"列"進行，某個表字段較多，可以新建一張擴充套件表，將不經常用或欄位長度較大的欄位拆分出去到擴充套件表中。在欄位很多的情況下（例如一個大表有100多個欄位），通過"大表拆小表"，更便於開發與維護，也能避免跨頁問題，MySQL底層是通過資料頁儲存的，一條記錄佔用空間過大會導致跨頁，造成額外的效能開銷。另外資料庫以行為單位將資料載入到記憶體中，這樣表中欄位長度較短且訪問頻率較高，記憶體能載入更多的資料，命中率更高，減少了磁碟IO，從而提升了資料庫效能。

下面來分析下垂直切分的優缺點：

優點：

 拆分後業務清晰，拆分規則明確。

 系統之間整合或擴充套件容易。

 資料維護簡單。

缺點：

 部分業務表無法 join，只能通過介面方式解決，提高了系統複雜度。

 受每種業務不同的限制存在單庫效能瓶頸，不易資料擴充套件跟效能提高。

 事務處理複雜。

由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與儲存瓶

頸，所以就需要水平拆分來做解決。

  水平拆分

  水平拆分不是將表做分類，而是按照某個欄位的某種規則來分散到多個庫之中，每個表中 

包含一部分資料。簡單來說，我們可以將資料的水平切分理解為是按照資料行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的資料庫中 

當一個應用難以再細粒度的垂直切分，或切分後資料量行數巨大，存在單庫讀寫、儲存效能瓶頸，這時候就需要進行水平切分了。

水平切分分為庫內分表和分庫分表，是根據表內資料內在的邏輯關係，將同一個表按不同的條件分散到多個數據庫或多個表中，每個表中只包含一部分資料，從而使得單個表的資料量變小，達到分散式的效果

庫內分表只解決了單一表資料量過大的問題，但沒有將表分佈到不同機器的庫上，因此對於減輕MySQL資料庫的壓力來說，幫助不是很大，大家還是競爭同一個物理機的CPU、記憶體、網路IO，最好通過分庫分表來解決。

幾種典型的分片規則包括：

 按照使用者 ID 求模，將資料分散到不同的資料庫，具有相同資料使用者的資料都被分散到一個庫中。

 按照日期，將不同月甚至日的資料分散到不同的庫中。

 按照某個特定的欄位求摸，或者根據特定範圍段分散到不同的庫中。

 切分原則都是根據業務找到適合的切分規則分散到不同的庫，

 優點：

 拆分規則抽象好，join 操作基本可以資料庫做。

 不存在單庫大資料，高併發的效能瓶頸。

 應用端改造較少。

 提高了系統的穩定性跟負載能力。

缺點：

 拆分規則難以抽象。

 分片事務一致性難以解決。

 資料多次擴充套件難度跟維護量極大。

 跨庫 join 效能較差。

分庫分表可以在不同的層做。一般來說有以下幾種：

jdbc層：實現複雜，屬於輕量級，對應用基本沒有侵入性;缺點是不能複用資料庫連線，在應用部署多的時候資源耗費大，不適於大規模部署。類似噹噹網的sharding-jdbc.

ORM層：比如蘑菇街TSharding框架封裝mybatis，實現簡單。缺點是必須依賴ORM層，侵入性比較大。

DBProxy層：如cobar和mycat，可以做到連線複用，效能不錯，完全沒侵入性。缺點是實現複雜，框架比較重，維護工作量大。

DAO層：實現簡單，缺點是分表比較麻煩。美團的框架似乎就是這樣做到。

無論怎麼做分庫分表，其基本思路都是一樣的。需要有分庫路由，分庫規則，分庫關鍵字

分庫數量

分庫數量首先和單庫能處理的記錄數有關，一般來說，Mysql 單庫超過5000萬條記錄，Oracle單庫超過1億條記錄，DB壓力就很大(當然處理能力和欄位數量/訪問模式/記錄長度有進一步關係)。

在滿足上述前提下，如果分庫數量少，達不到分散儲存和減輕DB效能壓力的目的；如果分庫的數量多，好處是每個庫記錄少，單庫訪問效能好，但對於跨多個庫的訪問，應用程式需要訪問多個庫，如果是併發模式，要消耗寶貴的執行緒資源；如果是序列模式，執行時間會急劇增加。

最後分庫數量還直接影響硬體的投入，一般每個分庫跑在單獨物理機上，多一個庫意味多一臺裝置。所以具體分多少個庫，要綜合評估，一般初次分庫建議分4-8個庫。

路由透明

分庫從某種意義上來說，意味著DB schema改變了，必然影響應用，但這種改變和業務無關，所以要儘量保證分庫對應用程式碼透明，分庫邏輯儘量在資料訪問層處理。當然完全做到這一點很困難，具體哪些應該由DAL負責，哪些由應用負責，這裡有一些建議：

對於單庫訪問，比如查詢條件指定使用者Id，則該SQL只需訪問特定庫。此時應該由DAL層自動路由到特定庫，當庫二次分裂時，也只要修改mod 因子，應用程式碼不受影響。

對於簡單的多庫查詢，DAL負責彙總各個資料庫返回的記錄，此時仍對上層應用透明。

幾種典型的資料分片規則為：

1、根據數值範圍 ： 按照時間區間或ID區間來切分

2、根據數值取模 ：  一般採用hash取模mod的切分方式

問題：

1、事務一致性問題 ： 更新內容同時分佈在不同庫中，不可避免會帶來跨庫事務問題。跨分片事務也是分散式事務，沒有簡單的方案，一般可使用"XA協議"和"兩階段提交"處理。

2、跨節點關聯查詢 join 問題  ： 切分之前，系統中很多列表和詳情頁所需的資料可以通過sql join來完成。而切分之後，資料可能分佈在不同的節點上，此時join帶來的問題就比較麻煩了，考慮到效能，儘量避免使用join查詢。

3、跨節點分頁、排序、函式問題   ： 跨節點多庫進行查詢時，會出現limit分頁、order by排序等問題。分頁需要按照指定欄位進行排序，當排序欄位就是分片欄位時，通過分片規則就比較容易定位到指定的分片；當排序欄位非分片欄位時，就變得比較複雜了。需要先在不同的分片節點中將資料進行排序並返回，然後將不同分片返回的結果集進行彙總和再次排序，最終返回給使用者。 

4、全域性主鍵避重問題 ： 在分庫分表環境中，由於表中資料同時存在不同資料庫中，主鍵值平時使用的自增長將無用武之地，某個分割槽資料庫自生成的ID無法保證全域性唯一。因此需要單獨設計全域性主鍵，以避免跨庫主鍵重複問題。

5、資料遷移、擴容問題