分布式系統
分布式系統是指其組件分布在網絡上，組件之間通過傳遞消息進行通信和動作協調的系統。核心理 念是讓多臺服務器協同工作，完成單臺服務器無法處理的任務，尤其是高並發或者大數據量的任 務。

分布式系統特點

透明性：分布式系統對於用戶來說是透明的，一個分布式系統在用戶面前的表現就像 一個傳統的單處理機分時系統，可讓用戶不必了解其內部結構就能使用。

擴展性：分布式系統大的特點就是可擴展性，它能夠根據需求的增加而擴展，可以 通過橫向擴展使集群的整體性能得到線性提升，也可以通過縱向擴展單臺服務器的性 能使服務器集群性能得到提升。

可靠性：分布式系統不允許單點失效的問題存在，它的基本思想是，如果一臺機器壞 了，則其他的機器能夠接替它進行工作，具有持續服務的特性。

高性能：采用服務器集群的方式能夠保證系統的高性能。

分布式系統的缺點

在節點通信部分的開銷大，線程安全問題也變得復雜，需要在保證數據完整性的同時 要兼顧性能。 過分依賴網絡，網絡信息的丟失或飽和將會抵消分布式系統的大部分優勢。 有潛在的數據安全和網絡安全等安全性問題。

CAP理論

CAP理論是指在分布式系統中不可能同時滿足一致性 Consistency、可用性 Availability和分區容錯 性 Partition Tolerance。

一致性（Consistency）：系統在執行過某項操作後仍然處於一致的狀態。在分布式 系統中，更新操作執行成功後所有的用戶都應該讀取到新的值。

可用性（Availability）：每一個操作總是能夠在一定的時間內返回結果。

分區容錯性（Partition Tolerance）：分區容錯性是在網絡故障、某些節點不能通信 的時候系統仍能繼續工作。

數據一致性

強一致性：當更新操作完成之後，任何多個後續進程或者線程的訪問都會返回新的 更新過的值。這種是對用戶友好的，就是用戶上一次寫什麽，下一次就保證能讀到 什麽。根據 CAP 理論，這種實現需要犧牲可用性。 弱一致性：系統並不保證後續進程或者線程的訪問都會返回新的更新過的值。系統 在數據寫入成功之後，不承諾立即可以讀到新寫入的值，也不會具體的承諾多久之 後可以讀到。 最終一致性：弱一致性的特定形式。系統保證在沒有後續更新的前提下，系統終返 回上一次更新操作的值。在沒有故障發生的前提下，不一致窗口的時間主要受通信延 遲，系統負載和復制副本的個數影響。DNS 是一個典型的終一致性系統。

在絕大多數的場景，都需要犧牲強一致性來換取系統的高可用性，系統往往只需要保證終一致 性。

分布式數據庫

分布式數據庫是指數據在物理上分布而在邏輯上集中管理的數據庫系統。物理上分布式指分布式數 據庫的數據分布在物理位置不同並由網絡連接的節點或站點上；邏輯上集中是指各個數據庫節點之 間在邏輯上是一個整體，並由統一的數據庫管理系統管理。不同的節點分布可以跨不同的機房、城 市甚至國家。

數據分片

數據分片是指將數據全局的劃分為相關的邏輯片段，有水平切分，垂直切分，混合切分三種類型。
水平切分：按照某個字段的某種規則將數據分散到多個節點庫中，每個節點包含一部 分數據。可以將數據的水平切分簡單的理解為按照數據進行切分，就是將表中的某些 數據分到一個節點，將另外的某些切分都另外的節點，從分布式的整體來看它們就是 一個整體的表。

垂直切分：垂直切分就是按照業務將表進行分類並分布到不同的節點上。

混合切分：水平切分與混合切分的結合。

分布式查詢處理

分布式查詢處理的任務就是把一個分布式數據庫上的高層次的查詢映射為在本地數據庫上操作，將 要查詢的數據定位到各個節點上，使得查詢在各節點進行，後通過網絡通信的操作匯聚查詢結 果。

分布式事務
分布式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的 分布式系統的不同節點之上。詳細內容可參照分布式事務章節

Mycat數據庫中間件

Mycat是一個開源的面向企業應用的開發的大數據庫集群，支持事務，ACID，是可以替代Mysql的 加強版數據庫。應用與Mycat以及Mysql關系圖如下：

Mycat核心概念

邏輯庫

開發人員通常在實際應用中並不需要知道中間件的存在，只需要關註數據庫，所以數據庫中間件可 以被當做一個或多個數據庫集群構成的邏輯庫。

邏輯表

在分布式數據庫中，對於應用來說，讀寫數據的表就是邏輯表。邏輯表可以分部在一個或多個分片 節點上，也可以不分片。

分片表：分片表是將數據量很大的表切分到多個數據庫實例中，所有分片組合起來構 成一張完成的表。例如我們的運單表。 非分片表：並非所有的表都需要進行分片，某些表可以不用分片。非分片表是相對於 分片表而言的不需要數據切分的表。 全局表：當業務表進行分片後，業務表與其他的基礎表之間的關聯查詢就成了棘手的 問題，所以在Mycat中通過數據冗余來解決這類表的關聯查詢，即所有分片節點上都 復制了一份數據，這些冗余數據的表定義為全局表。例如我們的數據字典表，用戶表 等。 ER表：ER表是基於E-R關系的數據分片策略，即子表的記錄與其所關聯的主表的記 錄放在同一個數據分片上，即子表依賴於主表，通過表分組保證數據關聯查詢不會跨 庫操作。例如我們的交接單表與交接單明細表。

分片節點

將數據切分後，一個大表被分到不同的分片數據庫上，每個表分片所在的數據庫就是分片節點。

節點主機

將數據切分後，每個分片節點不一定會獨占一臺機器，同一臺機器上可以有多個分片數據庫，這樣 一個或者多個分片節點所在的機器就是節點主機。

Mycat原理

Mycat核心配置文件
Mycat三大核心配置文件：

server.xml：服務器參數調整和用戶授權的配置文件。

schema.xml：邏輯庫定義和表以及分片定義的配置文件。

rule.xml：是分片規則的配置文件。

Mycat分片規則
Mycat有多種分片規則，以下為部分常用分片規則：
取模分片：按照分片字段取模分片。

枚舉分片：按照分片字段枚舉值分布到不同的節點上。

範圍分片：按照分片字段的範圍進行分片。

一致性hash分片：按照分片字段做一致性hash分片。

分布式事務
隨著並發量、數據量越來越大以及業務已經細化到不能再按照業務劃分，我們不得不使用分布式數 據庫提高系統的性能，在分布式系統中，各個節點在物理上都是相對獨立的，每個節點上的數據操 作都可以滿足ACID。但是，各個節點之間無法知道其他節點事務的執行情況，如果想讓多臺機器中 的數據保存一致，就必須保證所有的節點上的數據操作要麽全部執行成功，要麽全部不執行，比較 常規的解決方法就是引入“協調者”來統一調度所有節點的執行。
XA規範
X/Open組織（即現在的Open Group）定義了分布式事務處理模型。X/Open DTP模型包括應用程 序（AP）、事務管理器（TM）、資源管理器（RM）。通常把一個數據庫內部的事務處理看做本地 事務，而分布式事務處理的對象是全局事務。全局事務是指在分布式事務處理環節中，多個數據庫 可能需要共同完成一個工作，這個工作就是一個全局事務。在一個事務中可能更新幾個不同的數據 庫，此時一個數據庫對自己內部所做的操作的提交不僅需要本身的操作成功，還需要全局事務相關 的其他數據庫操作成功。如果任一數據庫的任一操作失敗，則參與此事務的所有數據庫所做的所有 操作必須回滾。XA就是X/Open DTP定義的事務管理器與資源管理器之間的接口規範（即接口函 數），事務管理器用它來通知數據庫事務的開始、結束、提交、回滾等。

二階段提交
所謂的兩個階段是指準備階段和提交階段。
第一階段：準備階段
事務協調者(事務管理器)給每個參與者(資源管理器)發送Prepare消息，每個參與者要麽直接返回失 敗(如權限驗證失敗)，要麽在本地執行事務，寫本地的redo和undo日誌，但不提交，到達一種“萬事 俱備，只欠東風”的狀態。
可以進一步將準備階段分為以下三個步驟：
1）協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響 應。
2）參與者節點執行詢問發起為止的所有事務操作，並將Undo信息和Redo信息寫入日誌。（註意： 若成功這裏其實每個參與者已經執行了事務操作）
3）各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返 回一個”同意”消息；如果參與者節點的事務操作實際執行失敗，則它返回一個”中止”消息。
第二階段：提交階段
如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾(Rollback)消息；否 則，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理 過程中使用的鎖資源。

二階段提交的缺點：
1）同步阻塞問題，在執行過程中所有參與節點都是事務阻塞型的。
2）單點故障，由於協調者的重要性，一旦協調者發送故障，則參與者會一致阻塞下去。
3）數據不一致，在二階段提交的提交階段中，當協調者向參與者發送commit請求之後發生了局部 網絡異常或者在發生commit請求過程中協調者發生了故障，則會導致只有一部分參與者接收到了 commit請求，而在部分參與者在接收到commit請求之後就會執行commit操作，其他部分未接收到 commit請求的機器則無法執行事務提交，於是整個分布式系統便出現了數據不一致現象。
三階段提交
三階段提交是二階段提交的改進版本。三階段提交把二階段提交的準備階段再次一份為二，這樣三 階段提交就有CanCommit、PreCommit、DoCommit三個階段。
相對於二階段提交，三階段提交主要解決的單點故障問題，並減少阻塞，因為一旦參與者無法及時 收到來自協調者的信息之後，他會默認執行commit。而不會一直持有事務資源並處於阻塞狀態。但 是這種機制也會導致數據一致性問題，因為，由於網絡原因，協調者發送的abort響應沒有及時被參 與者接收到，那麽參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行 回滾的參與者之間存在數據不一致的情況。
Mycat的分布式事務
Mycat分布式事務是一種二階段提交事務方式。

Mycat內部實現流程如下： 1）set autocommit = 0 將MysqlConnection中的autocommit設置為false; 2）set xa = on 將Mycat中開啟XA事務管理器，進行XA事務開始標記，執行SQL業務，1pc提交並記錄日誌到 tm.log中，如果1pc階段有異常，則直接回滾事務。 3）在多節點Mysql中全部進行2pc提交，提交成功後，事務結束，如果有異常，則對事務進行重新 提交或者回滾。
Mycat中的XA分布式事務的異常流程處理如下： 1）一階段commit異常：如果1pc提交任意一個mysql節點無法提交或者異常，則全部節點的事務進 行回滾，拋出異常給應用事務回滾。 2）Mycat Crash Recovery：Mycat崩潰以後，根據tm.log事務日誌再進行重啟恢復，Mycat啟動後 執行事務日誌查找各個節點中已經prepared的XA事務，進行commit或者rollback.

MyCat入門