我來扯扯分布式數據庫系統DDBS的設計

注明：本文只是在完成一個高級數據庫作業的文章，不能算是正兒八經登堂入室的paper，所以，不負責任哈，帶壞小朋友不要找我哦 ^_~

轉載注明出處：Scofield's blog[  http://blog.csdn.net/scotfield_msn/article/details/60344796  ]

一、   引入

目前本人所確定的研究方向是自然語言處理、文本挖掘，實際項目實踐中涉及到分布式系統平臺的構建，而必然接觸得到到分布式系統的核心部分：分布式數據庫系統（DDBS）。平時在與分布式數據庫系統的接觸中，總是會萌發出一種想徹徹底底的了解透分布式DB的想法?，F在借助高級數據庫原理這門課的報告作業來對DDBS做一個系統的研究。主要探討設計DDBS所涉及到的關鍵技術以及算法問題。

1.1、概念

分布式數據庫是指物理上分散而邏輯上集中的系統，它使用計算機網絡將地理位置分散而管理和控制又需要不同程度集中的多個邏輯單位（通常是集中式數據庫系統）連接起來，共同組成一個統一的數據庫系統。分布式數據庫系統是相對于傳統集中式數據庫系統的，隨著項目產品的物理上的擴充以及網絡技術的發展，集中式數據庫系統表現出它的不足：數據按實際需要已在網絡上分布存儲，再采用集中式處理，勢必造成通信開銷大；應用程序集中在一臺計算機上運行，一旦該計算機發生故障，則整個系統受到影響，可靠性不高；集中式處理引起系統的規模和配置都不夠靈活，系統的可擴充性差。在這種形勢下，集中式DB的“集中計算”概念向“分布計算”概念發展。

DDBS的分類有三種：同構同質型DDBS，各個場地都采用同一類型的數據模型；同構異質型DDBS，各個場地采用同一類型的數據模型，但是DBMS的型號不同，譬如DB2、Oracle、SYBASE、SQL Server；異構型DDBS，各個場地的數據模型的型號不同，甚至類型也不同。

DDBS的特點在于：物理分布性，數據不是存儲在一個場地上，而是存儲在計算機網絡的多個場地上。邏輯整體性，數據物理分布在各個場地，但邏輯上是一個整體，它們被所有用戶（全局用戶）共享，并由一個DDBMS統一管理。場地自治性，各場地上的數據由本地的DBMS管理，具有自治處理能力，完成本場地的應用（局部應用）。場地之間協作性，各場地雖然具有高度的自治性，但是又相互協作構成一個整體。以及數據獨立性、集中與自治相結合的控制機制、適當增加數據冗余度、事務管理的分布性。所以DDBS得優勢也很明顯：具有靈活的體系結構，適應分布式的管理和控制機構，經濟性能優越，系統的可靠性高、可用性好，局部應用的響應速度快，可擴展性好，易于集成現有的系統。大大降低單個數據庫的壓力（數據量少，單個數據庫不會被頻繁操作到，如提交事務，搶占資源程度降低）。

1.2、構建之前的思考

       1、項目考慮構建分布式數據庫的時機。

       假設目前服務器的磁盤和內存，cpu都相對較好，一臺數據庫服務器可以存儲好幾億條的數據。考慮用分布式數據庫，肯定是容量或者性能方面，現有的單機數據庫滿足不了業務的需求。普通的X86服務器，一臺數據庫服務器存好幾億條數據，問題不大，但前提是需要分庫或分表，單表幾億條數據，普通服務器基本支撐不了的，畢竟數據量一大，表對應的B樹層次就高，寫入時B樹節點的分裂和調整，開銷也大。同時，上億規模下，單臺數據庫服務器的恐怕不能支持密集的讀請求，性能可能會有問題。

       2、考慮分布式數據庫中間件的有效性

       目前比較流行的分布式構建方式是DBA利用開源中間件，結合自己項目的MySQL或pg數據庫，來搭建出一套分布式數據庫的解決方案。主要的方法有兩種：一種是水平拆分。當數據量大到單機數據庫已存儲不下時， 可以對數據進行拆分，化整為零，將數據均勻分布到多個數據庫節點中。由于對數據進行了拆分，每個數據庫節點上的數據量小了，自然讀寫性能就提高了。另一種是讀寫分離。這種方法，主要用在數據量并不大，單機數據庫能夠hold得住，但讀請求很高的情況下。此時，可以配置多個只讀數據庫節點，來分擔主節點的讀請求。通過數據復制機制，在主節點和只讀節點之間進行數據的實時同步，保證主從節點的數據一致性。兩種方法很好地解決了數據庫的容量和性能問題。當然，使用了中間件，相當于在sql的執行路徑上，多了一個處理環節，因此單條sql的延時，相對于直連數據庫節點，在非滿負載的情況下，肯定是要高的。但在實際的業務訪問中，sql的性能瓶頸，一般都出在數據庫節點上，中間件只是做單純的sql解析和路由，性能開銷不會很大。因此，通過增加數據庫節點，提升sql處理的短板，是能夠提高系統效率的。

       3、中間件對復雜SQL場景的支持度

       確實如果用一些中間件方案，對跨庫事務、join等操作很難處理好。基于中間件來進行分庫，對 SQL 有閹割的情況，并不是所有sql都能夠支持。主要原因是數據被拆分了。而數據一旦被拆分到多個節點，則： 1.復雜的join查詢；2.同時更新多個數據庫節點的sql語句；這兩類SQL的支持難度，就比較高。這也是目前市面上所有中間件都無法滿足的兩點。復雜的join查詢之所以難以支持，是因為要跨節點join；同時更新多個節點的sql難以支持，是因為很難解決多個節點的并發一致性問題。但是除了這兩點之外，其他的sql類型，一款中間件是能夠努力做到的。綜合地講，中間件也具有一定的局限性。

二、   考慮的問題

分布式數據庫的設計目標要達到：1、本地性或近地性：盡量減少站點之間的通信次數和通信量，滿足90%/10%準則，考慮分片和分布方案（本地和遠程訪問次數）的擇優。2、控制數據適當冗余：冗余增加了可靠性、可用性，提高了效率，但會造成維護數據一致性開銷增加。3、工作負荷分布均衡：各站點可以分擔整個工作任務，但又會造成本地性降低。4、綜合考慮存儲能力和費用等等。

若是自己想要設計構建出一套相對高可用、高性能和高并發的DDBS，需要考慮大量的問題。其中典型的有分布式一致性問題、數據分片問題、分布式數據庫查詢優化、事務管理以及并發問題等等。

2.1、一致性問題

一致性就是數據保持一致，在分布式系統中，可以理解為多個節點中數據的值是一致的。而一致性又可以分為強一致性與弱一致性。強一致性可以理解為在任意時刻，所有節點中的數據是一樣的。同一時間點，你在節點A中獲取到key1的值與在節點B中獲取到key1的值應該都是一樣的。弱一致性包含很多種不同的實現，目前分布式系統中廣泛實現的是最終一致性。

分布式數據庫系統中，涉及到了一些關鍵的部分，比如事務管理處理等，這些部分對一致性的要求非常之高，所以就這就是為什么單獨將一致性問題拿出來講的原因。

數據庫大體分為以下幾類，有關系型（事務型）的數據庫，以Oracle、MySQL為代表，有keyvalue數據庫，以Redis和memcached db為代表，有文檔型數據庫如MongoDB，有列式數據庫以Hbase，cassandra，dynamo為代表。有些數據庫本身就是分布式的數據庫設計理念，比如上面的列式數據庫；有些本身是單節點的設計架構，如redis、mongodb、關系型數據庫。但是考慮到整個系統的可用性，這么內存型的數據庫都有分布式部署的機制，如redis的主從復制，mongodb的Master-slave，replicaset，mysql和oracle的主從結構。而對于關系型數據庫主要以強一致性的實現為主，而文檔型、列式數據庫主要以弱一致性（最終一致性）的實現為主。

2.2、數據分片

在設計分布式數據庫的時候，設計者必須考慮數據如何分布在各個場地上，也就是全局數據應該如何進行邏輯劃分和物理劃分。哪些數據應該分布式存放，哪些不需要分布式存放，哪些數據需要復制。對系統驚醒全盤考慮，使系統性能最優。分布式數據庫中數據的存儲單位成為片段，對全局數據庫的劃分叫做分片。劃分的結果就是片段。每個片段可以保存在一個以上的場地（服務器）。分片的作用大概有以下幾種：1、減少網絡傳輸量，對數據進行復制存儲，目的是可以就近訪問所需數據副本，減少網絡上的數據傳輸量。2、增大事務處理的局部性。3、提高數據的可用性和查詢效率。4、負載均衡。

另外，在分布式數據庫中，存在著分區、分片、分庫、分表等的概念。

分區：原來所有的數據都是在一個數據庫上的，網絡IO及文件IO都集中在一個數據庫上的，因此CPU、內存、文件IO、網絡IO都可能會成為系統瓶頸。而分區的方案就是把某一個或某幾張相關的表的數據放在一個獨立的數據庫上，這樣就可以把CPU、內存、文件IO、網絡IO分解到多個機器中，從而提升系統處理能力。分區有兩種模式，一種是主從模式，用于做讀寫分離；另外一種模式是分片模式，也就是說把一個表中的數據分解到多個表中。一個分區只能是其中的一種模式。

分庫（片）：分庫只是一個通俗說法，更標準名稱是數據分片，采用類似分布式數據庫理論指導的方法實現，對應用程序達到數據服務的全透明和數據存儲的全透明。分表和分區都是基于同一個數據庫里的數據分離技巧，對數據庫性能有一定提升，對MySQL數據庫的吞吐量無質的變化。當業務系統的數據容量接近或超過單臺X86服務器的容量、QPS/TPS接近或超過單個MySQL數據庫實例的處理極限等，則重點在于擴展MySQL數據庫的吞吐量和數據處理量。此時，往往是采用垂直和水平結合的數據拆分方法，把數據服務和數據存儲分布到多臺MySQL數據庫服務器上。

分表：當數據量大到一定程度的時候，都會導致處理性能的不足，這個時候就沒有辦法了，只能進行分表處理。也就是把數據庫當中數據根據按照分庫原則分到多個數據表當中，這樣，就可以把大表變成多個小表，不同的分表中數據不重復，從而提高處理效率。

可以這樣理解，概念從大到小的排序是：分區（主從模式、分片模式）->分片（分庫）->分表。

2.3、查詢優化

在關系數據庫系統中有著非常重要的地位 ，關系查詢優化是影響RDBMS性能的關鍵因素。分布式查詢優化的目標除了要解決集中式查詢處理的問題如：查詢轉換為代數表達式、從所有等價表達式中選擇最優的代數表達式，還要考慮分布式獨有的問題：站點之間交換數據的操作、選擇最優的執行站點(分布）、數據被傳送的方式等等。

總的查詢優化準則是使得通訊費用最低和響應時間最短，即以最小的總代價，在最短的響應時間內獲得需要的數據。首先，通訊費用與所傳輸的數據量和通信次數有關。再次，響應時間和通信時間有關，也與局部處理時間有關。

分布式數據庫查詢優化的衡量標準：一個查詢策略的選擇是以執行查詢的預期代價為依據的，由集中式系統大都運行在單個處理器的計算機上，所以查詢執行總代價為CPU代價加I/O代價之外。分布式查詢優化可用CPU代價、I/O代價、通信代價3個參數來徇，總代價為三者之和。在分布式數據庫系統中，常以兩種不同的目標來考慮查詢優化：

1. 以總代價最小為標準，除了CPU代價和I/O代價之外，還包括數據通過網絡傳輸的代價。

2. 以每個查詢的響應時間最短為標準。響應時間就是從接收查詢到完成查詢所需要的時間。它既與通信時間有關，又與局部處理時間有關，而通信費用與所傳輸的數據量和通信次數成正比。

2.4、事務管理

事務是訪問或更新各種數據項的最小邏輯工作單位，它是一個操作序列，它可以使數據庫從一個一致狀態到另外一個一致狀態。而在分布式數據庫環境中，一個數據庫事務可以更新多個場地上的數據，這種數據庫事務稱為分布式事務。在分布式數據庫系統中事務必須遵循一致性原理，所以如何分布式數據庫事務處理管理和恢復成為一個關鍵的問題。

設想有一個事務，要求數據變化發生在兩個分離的數據庫中，仍然要求所有的ACID特性測試能夠滿足。基本的事務處理不能滿足要求，因為如果其中一個數據庫服務器失敗，無法確保另外一個數據庫的數據還沒有提交并成為永久的。換句話說，無法協調發生在不同地方的多個事務處理就沒有辦法保證事務的原子性。

2.5、并發控制

通常，數據庫總有若干個事務在運行，這些事務可能并發地存取相同的數據，稱為事務的并發操作。當數據庫中有多個事務并發執行時，系統必須對并發事務之間的相互作用加以控制，這是通過并發控制機制來實現的。并發控制就是負責正確協調并發事務的執行，保證這種并發的存取操作不至于破壞數據庫的完整性和一致性，確保并發執行的多個事務能夠正確地運行并獲得正確的結果。

分布式數據庫中的并發控制解決多個分布式事務對數據并發執行的正確性，保證數據庫的完整性和一致性，所以比集中式并發控制更復雜。

數據庫的一個重要特征是：支持數據共享，也就是說允許多個用戶程序并行地存取數據庫中的數據；那么，多用戶或多事物可能同時對同一數據進行操作，這成為并發操作。并發操作將帶來如下的問題：丟失修改、臟讀、不可重復讀。

三、   方法論

3.0、DDBS設計方法

分布式數據庫的設計方法有三種：自頂向下方法，即重構法；自底向上方法，即組合法；以及兩者的混合方法。

1、自頂向下方法

自頂向下方法的設計特點是：一般是要重新設計數據庫。首先定義數據庫的全局內容，然后再對其進行分片成多個數據庫子集，再分別定義局部數據庫的模式與位置。

自頂向下的設計過程大致是：在邏輯設計與物理設計之間增加分布設計。以一個全局的、與站點無關的模式作為輸入，產生分布式數據庫個站點的子模式（局部概念模式）作為輸出。分布設計包括數據的分片設計和片段的位置分配設計。

2、自底向上方法

自底向上的分布式數據庫設計就是要將現有的各種不同的數據庫模式集成為全局模式。所謂集成就是把公用數據定義合并起來，并解決對同一個數據的不同表示方法之間的沖突。自底向上的設計方法不宜于水平分片關系的設計。自底向上方法的設計特點一般是在現有已分布的數據庫基礎上進行設計。須綜合各站點的規格說明，以便得到分布式數據庫的全局概念模式。

自底向上設計方法需要解決三個問題：選擇公用數據庫模型來描述數據庫的全局模式；把每個站點上的本地模式翻譯成公用數據模型；把各站點上的本地數據模式集成為一公用的全局模式。

3、混合方法

在許多實際情況中，更多的是考慮混合方法，設計者都是一部分使用自頂向下方法，另一部分又使用自底向上方法。

3.1、一致性問題

一致性的解決方案分兩種：強一致性和弱一致性。

1、弱一致性（最終一致）：由于分布式系統在數據同步時的網絡延遲等等因素，無法保證副本數據和主節點時刻保持一致，當出現不一致的時，可以采用以下幾種策略保證最終一致性：

Gossip（Cassandra，Dynamo），是帶冗余容錯算法，也就是最終一致性的算法，無法保證某時刻所有節點數據一致，它是一個去中心化的部署方式，集群中每個節點維護一組狀態，狀態可以用key,value，外帶一個版本號表示，版本大的比版本小的數據新，節點之間相互交流數據的版本信息，并更新數據，類似病毒式的傳遞，這樣數據可以達到最終一致。Cassandra就是采取這種策略來進行數據的同步,并且維護節點的健康狀態。

向量時鐘（Dynamo），是一種數據不一致導致沖突的解決策略，系統采用樂觀鎖的策略，這樣對同一個值進行操作時，就可能會出現多個版本，由向量時鐘來解決一致性；每個元素是（更新值的節點，序列號），每當更新一個值時，都帶上這些信息，從下圖可見，D3和D4出現數據的沖突，那么在下次操作時，會由更新值的節點做沖突的解決。Dynamo采用的就是這種策略進行沖突的解決。

2、強一致性：paxos算法、raft算法。

Paxos算法：總體說來，paxos就是通過兩個階段確定一個決議：

Phase1：確定誰的編號最高，只有編號最高者才有權利提交PRoposal；

Phase2：編號最高者提交proposal，如果沒有其他節點提出更高編號的proposal，則該提案會被順利通過；否則，整個過程就會重來。

你編號高，我比你更高，反復如此，算法永遠無法結束，這叫活鎖。FLP Impossibility已經證明，在異步通信中不存在任何一致性算法，活鎖便是Paxos無法解決的硬傷。Phase1，Phase2非常像2PC中的兩個階段，因此paxos本質上是多個2PC交替執行！

Raft算法：過去, Paxos一直是分布式協議的標準，但是Paxos難于理解，更難以實現。來自Stanford的新的分布式協議研究稱為Raft，它是一個為真實世界應用建立的協議，主要注重協議的落地性和可理解性。Paxos和Raft都是為了實現Consensus一致性這個目標，這個過程如同選舉一樣，參選者需要說服大多數選民(服務器)投票給他，一旦選定后就跟隨其操作。Paxos和Raft的區別在于選舉的具體過程不同。在Raft中，任何時候一個服務器可以扮演下面角色之一：

Leader: 處理所有客戶端交互，日志復制等，一般一次只有一個Leader.

Follower: 類似選民，完全被動

Candidate候選人: 類似Proposer律師，可以被選為一個新的領導人。

Raft階段分為兩個，首先是選舉過程，然后在選舉出來的領導人帶領進行正常操作。如果在這一過程中，發生了網絡分區或者網絡通信故障，使得Leader不能訪問大多數Follwers了，那么Leader只能正常更新它能訪問的那些Follower服務器，而大多數的服務器Follower因為沒有了Leader，他們重新選舉一個候選者作為Leader，然后這個Leader作為代表于外界打交道，如果外界要求其添加新的日志，這個新的Leader就按上述步驟通知大多數Followers，如果這時網絡故障修復了，那么原先的Leader就變成Follower，在失聯階段這個老Leader的任何更新都不能算commit，都回滾，接受新的Leader的新的更新。

3.2、數據分片

分片過程是將全局數據進行邏輯劃分和實際物理分配過程。全局數據將分片成各個片段數據，而各個片段將會分配到不同的場地（服務器）上。是一個這樣的過程：全局數據庫->片段數據庫->物理數據庫。

數據分片需要遵循一定的分片原則。在設計分布式數據庫的時候，設計者必須考慮數據如何分布在各個場地上，也就是全局數據應該如何進行邏輯劃分和物理劃分。哪些數據應該分布式存放，哪些不需要分布式存放，哪些數據需要復制。對系統驚醒全盤考慮，使系統性能最優。但是無論如何進行分片都應該遵循以下原則：1、完備性：所有全局數據都要映射到某個片段上。2、可重構性：所有片段必須可以重新構成全局數據。3、不相交性：劃分的片段所包含的數據無交集。

分片有三種方式：水平分片、垂直分片、混合分片。

1、水平分片

水平分片是將數據按照元組來劃分，在關系數據庫中也就是根據屬性的條件按照行劃分，該屬性叫做分片屬性，條件就是分片條件。又分為：基本水平分片：根據關系表本身的屬性分片。導出水平分片：分片屬性不是該關系表中的屬性。

2、垂直分片

垂直分片是通過將全局對象在其屬性子集上進行投影得到的，垂直分片是把一個關系表按照列來分成片段，各個片段之間除了主鍵外不能有交集。

3、混合分片

通過交替水平分片與垂直分片，可以產生混合分片。

3.3、查詢優化

一般來說，在分布式數據庫中的查詢優化主要考慮以下幾種：1. 操作執行的順序：操作執行順序的改變主要指關系運算及集合運算的改變，它們常常對鐵性能產生重要的影響。2. 關系的存取方法：在關系數據庫系統中，關系或使用索引，如果關系中90%的要被訪問，則掃描整個關系是較好的；如果只有30%的被訪問，則使用索引是更為有效的方法。3. 操作的執行算法（尤其是連接操作）：連接操作是將兩個關系在指定的公共屬性上以相同值為依據進行合并，連接操作通常有多種：自然連接、造價連接、外連接和半連接等。

分布式數據庫數據庫查詢優化的一般過程：分布式查詢處理問題是由E-Wong首先提出的，分布式查詢處理的基本思想認為分布式查詢處理是數據傳遞和局部處理相交織的過程，分布式查詢處理策略由數據傳遞策略與局部處理策略組成;分布式查詢處理的過程實質是利用數據傳遞策略和局部數據處理策略，把分布查詢轉化為局部查詢的過程。分布式數據庫中的查詢過程可分為邏輯分解、評議轉換和優化組合幾分。分布式數據庫系統中，用戶可以用全局查詢評議對多個數據庫同時進行查詢，即為全局查詢。全局查詢一般經過以下幾個過程：首先，對全局查詢進行邏輯分解成幾個子查詢，每個子查詢對應一個局部數據；其次，若全局查詢評議與局部查詢評議不同，則進行語言的等價轉換；最后，各個子查詢的結果優化組合后返回。不同的查詢分解對應不同的系統性能，因此為了達到優化系統性能，需要相應查詢優化器來確定一個相對較好的執行計劃，最后啟動查詢計劃。

分布式查詢處理按不同的層次執行，符合分布式數據庫系統的層次結構。分布式查詢處理可分為如下所示四個層次結構。

1、查詢分解

查詢分解(querydecomposition)是將查詢問題(如SQL語句)轉換成一個定義在全局關系上的關系代數表達式。這一層的做法與集中式DBMS相同，因為并未涉及分布問題。本層轉換所需要信息在全局概念模式中得到。

2、數據本地化

數據本地化(datalocalization)是把一個在全局關系上的查詢進行具體化到合適片段上的查詢。這一變換所需要信息在分片模式和片段的分配模式中獲得。

3、全局優化

全局優化((globaloptimization)輸入是分片查詢，全局優化是找出分片查詢的最佳操作次序，包括使得代價函數最小。全局優化一個重要方面是關于連接操作的優化，全局優化處理層輸出是一個優化的、片段上的關系代數查詢。這層轉換所需要信息來自數據庫的統計信息，包括各站點片段統計信息、資源信息和通信信息等。

4、局部優化

局部優化((localoptimization)由與查詢有關片段的各個站點執行。它由該站點上的DBMS進行優化，采用集中式數據庫系統中查詢優化的算法，所需要信息來自于局部模式。分布式查詢優化通常在分布式查詢層次結構中的數據本地化層和全局優化層。數據本地化階段一般采用的是基于關系代數等價變換的優化算法。而全局優化階段采用的算法，可具體分為基于半連接算法的查詢優化和基于直接連接算法的查詢優化兩大類。

3.4、事務管理

分布式事務必須滿足傳統事務的特性，即原子性，一致性，分離性和持久性。但是分布式事務處理過程中，某些場地(Server)可能發生故障，或 者由于網絡發生故障而無法訪問到某些場地。為了防止分布式系統部分失敗時產生數據的不一致性。在分布式事務的控制中采用了兩階段提交協議（Two- Phase Commit Protocol）。即事務的提交分為兩個階段：預提交階段(Pre-Commit Phase)、決策后階段（Post-Decision Phase）。

兩階段提交用來協調參與一個更新中的多個服務器的活動，以防止分布式系統部分失敗時產生數據的不一致性。例如，如果一個更新操作要求位于三個不同結點上的記錄被改變，且其中只要有一個結點失敗，另外兩個結點必須檢測到這個失敗并取消它們所做的改變?！　榱酥С謨呻A段提交，一個分布式更新事務中涉及到的服務器必須能夠相互通信。一般來說一個服務器會被指定為"控制"或"提交"服務器并監控來自其它服務器的信息。

在一個分布式事務中，必須有一個場地的Server作為協調者(coordinator)，它能向 其它場地的Server發出請求，并對它們的回答作出響應，由它來控制一個分布式事務的提交或撤消。該分布式事務中涉及到的其它場地的Server稱為參 與者（Participant）。事務兩階段提交的過程如下：

Step1、兩階段提交在應用程序向協調者發出一個提交命令時被啟動。這時提交進入第一階段，即預提交階段。在這一階段中：(1) 協調者準備局部（即在本地）提交并在日志中寫入"預提交"日志項，并包含有該事務的所有參與者的名字。(2) 協調者詢問參與者能否提交該事務。一個參與者可能由于多種原因不能提交。例如，該Server提供的約束條件（Constraints）的延遲檢查不符合 限制條件時，不能提交；參與者本身的Server進程或硬件發生故障，不能提交；或者協調者訪問不到某參與者（網絡故障），這時協調者都認為是收到了一個 否定的回答。(3) 如果參與者能夠提交，則在其本身的日志中寫入"準備提交"日志項，該日志項立即寫入硬盤，然后給協調者發回一，已準備好提交"的回答。(4) 協調者等待所有參與者的回答，如果有參與者發回否定的回答，則協調者撤消該事務并給所有參與者發出一個"撤消該事務"的消息，結束該分布式事務，撤消該事務的所有影響。

Step2、如果所有的參與者都送回"已準備好提交"的消息，則該事務的提交進入第二階段，即決策后提交階段。在這一階段中：(1) 協調者在日志中寫入"提交"日志項，并立即寫入硬盤。(2) 協調者向參與者發出"提交該事務"的命令。各參與者接到該命令后，在各自的日志中寫入"提交"日志項，并立即寫入硬盤。然后送回"已提交"的消息，釋放該事務占用的資源。 (3) 當所有的參與者都送回"已提交"的消息后，協調者在日志中寫入"事務提交完成"日志項，釋放協調者占用的資源 。這樣，完成了該分布式事務的提交。

3.5、并發控制

解決分布式數據庫系統的并發問題的常用方式是封鎖。封鎖就是事務T在對某數據對象(例如：表、記錄)操作之前，先向系統發出請求，對其加鎖。加鎖后事務T就對數據對象有了一定的控制，在事務T釋放它的鎖之前，其他的事務不能更新此數據對象。事務的同步化是通過對數據庫的片斷或者數據項進行物理或邏輯封鎖來實現的。其中，封鎖對象的大小通常稱為封鎖粒度。封鎖方法的類型可以根據在哪里進行封鎖來進一步細分：集中式封鎖方法，一個站點被指定為主站點，存放對整個數據庫的封鎖表，并且負責對全系統事務進行封鎖；主副本封鎖法，主副本所在站點封鎖；分布式封鎖法，網絡中的站點共享鎖的管理、

不同的鎖有不同的控制功能，即一個事務對數據對象加鎖后可有怎樣的控制由它的封鎖類型決定。鎖有以下三種類型：

1、排他鎖（簡稱X鎖，或寫鎖）：若事務T對數據對象A加上X鎖，則只允許T讀取和修改A，其他任何事務都不能再對A加任何類型的鎖，直到T釋放A上的鎖。排它鎖保證其他事務在事務T釋放數據對象A上的鎖之前不能在讀和修改A。

2、共享鎖（簡稱S鎖，或讀鎖）：若事務T對數據對象A加上S鎖，則其他事務只能再對A加S鎖，而不能加X鎖，直到T釋放A上的S鎖。共享鎖保證其他事務可以讀數據對象A，但在事務T釋放A上的S鎖之前不能對A做任何修改。

3、更新鎖（U鎖）

鎖的操作有三種：Read_lock(x):讀鎖。Write_lock(x)：寫鎖。unlock(x)：解鎖。數據項的狀態有兩種：read_locked: 讀鎖。Write_locked:寫鎖。具體操作方法是：首先，在系統鎖表中記錄關于鎖的信息，鎖表中每條記錄有四個字段：<數據項名稱，鎖狀態，讀鎖的數目，正在封鎖該數據項的事務>，鎖狀態是上面兩種，沒有被封鎖的數據項，在系統表中沒有記錄。封鎖通常具有3 個環節:第一個環節是申請加鎖，即事務在操作前要對它將使用的數據提出加鎖申請; 第二個環節是獲得鎖，即當條件成熟時，系統允許事務對數據進行加鎖，從而事務獲得數據的控制權；第三個環節是釋放鎖，即完成操作后事務放棄數據的控制權。

對封鎖方式規定不同的規則，就形成了各種不同的封鎖協議。下面介紹三級封鎖協議。三級封鎖協議分別在不同程度上解決了丟失的修改、不可重復讀和讀"臟"數據等不一致性問題，為并發操作的正確調度提供一定的保證。其中，1 級封鎖協議是：事務T在修改數據R之前必須先對其加X鎖，直到事務結束才釋放。事務結束包括正常結束（COMMIT）和非正常結束（ROLLBACK）。 1級封鎖協議可防止丟失修改，并保證事務T是可恢復的。在1級封鎖協議中，如果僅僅是讀數據不對其進行修改，是不需要加鎖的，所以它不能保證可重復讀和不讀"臟"數據。 2級封鎖協議是：1級封鎖協議加上事務T在讀取數據R之前必須先對其加S鎖，讀完后即可釋放S鎖。2級封鎖協議除防止了丟失修改，還可進一步防止讀"臟"數據。 3級封鎖協議是：1級封鎖協議加上事務T在讀取數據R之前必須先對其加S鎖，直到事務結束才釋放。3級封鎖協議除防止了丟失修改和不讀'臟'數據外，還進一步防止了不可重復讀。

四、   DDBS中間件MyCat分析

4.1、Mycat簡介

Mycat是一個開源的分布式數據庫系統，是一個實現了MySQL協議的的Server，前端用戶可以把它看作是一個數據庫代理，用MySQL客戶端工具和命令行訪問，而其后端可以用MySQL原生（Native）協議與多個MySQL服務器通信，也可以用JDBC協議與大多數主流數據庫服務器通信，其核心功能是分表分庫，即將一個大表水平分割為N個小表，存儲在后端MySQL服務器里或者其他數據庫里。它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流數據庫，也支持MongoDB這種新型NoSQL方式的存儲。而在最終用戶看來，無論是那種存儲方式，在Mycat里，都是一個傳統的數據庫表，支持標準的SQL語句進行數據的操作，這樣一來，對前端業務系統來說，可以大幅降低開發難度，提升開發速度。

Mycat是一個強大的數據庫中間件，不僅僅可以用作讀寫分離、以及分表分庫、容災備份，而且可以用于多租戶應用開發、云平臺基礎設施、讓你的架構具備很強的適應性和靈活性，借助于即將發布的Mycat智能優化模塊，系統的數據訪問瓶頸和熱點一目了然，根據這些統計分析數據，你可以自動或手工調整后端存儲，將不同的表映射到不同存儲引擎上，而整個應用的代碼一行也不用改變。

Mycat與MySQL的關系可看作是上層看作是對下層的抽象，例如操作系統是對各類計算機硬件的抽象。那么我們什么時候需要抽象？假如只有一種硬件的時候，我們需要開發一個操作系統嗎？再比如一個項目只需要一個人完成的時候不需要leader，但是當需要幾十人完成時，就應該有一個管理者，發揮溝通協調等作用，而這個管理者對于他的上層來說就是對項目組的抽象。同樣的，當我們的應用只需要一臺數據庫服務器的時候我們并不需要Mycat，而如果你需要分庫甚至分表，這時候應用要面對很多個數據庫的時候，這個時候就需要對數據庫層做一個抽象，來管理這些數據庫，而最上面的應用只需要面對一個數據庫層的抽象或者說數據庫中間件就好了，這就是Mycat的核心作用。所以可以這樣理解：數據庫是對底層存儲文件的抽象，而Mycat是對數據庫的抽象。

4.2、MyCat功能

mycat在一個應用系統中承擔著應用層與數據層之間的中間層角色。結合項目按照自己對mycat的理解，它強大的地方在于：

1、連接過多問題，可以通過MyCat統一管理所有的數據源，后端數據庫集群對前端應用程序透明。支持事務、ACID、可以替代MySQL的加強版數據庫。

2、獨創的ER關系分片，解決E-R分片難處理問題。

3、采用全局分片技術，每個節點同時并發插入和更新數據，每個節點都可以讀取數據。

4、通過人工智能的catlet支持跨分片復雜SQL實現以及存儲過程支持等。

4.3、Mycat結構

Mycat的具體設計構架如下圖。

總體上分成三個部分，最前端的是連接器，線程管理使用了資源池，并且默認采用了AIO的方式，這些基本信息可以再啟動日志里面看到；中間層采用SQL解析器+SQL路由，SQL Executor需要具體看源碼才能了解，通過這段時間對MyCAT的測試，感不覺到SQL Executor的存在，更多的感覺是一個SQL process的東西；DataNode和心跳檢測算是中間層實現的兩個組件，一個是和MySQL的庫（不是實例）相關，一個是常見的監測機制的功能模塊；最下層的存儲就是是MySQL的集群了，而具體如何設計MySQL的集群，由使用者決定。

4.4、Mycat原理簡析

Mycat的原理中最重要的一個動詞可以用“攔截”高度概括：它攔截了用戶發送過來的SQL語句，首先對SQL語句做了一些特定的分析：如分片分析、路由分析、讀寫分離分析、緩存分析等，然后將此SQL發往后端的真實數據庫，并將返回的結果做適當的處理，最終再返回給用戶。

Orders表被分為三個分片datanode（簡稱dn)，這三個分片是分布在兩臺MySQL Server上(DataHost)，即datanode=database@datahost方式，因此你可以用一臺到N臺服務器來分片，分片規則為（sharding rule)典型的字符串枚舉分片規則，一個規則的定義是分片字段（shardingcolumn)+分片函數(rule function)，這里的分片字段為prov而分片函數為字符串枚舉方式。

當Mycat收到一個SQL時，會先解析這個SQL，查找涉及到的表，然后看此表的定義，如果有分片規則，則獲取到SQL里分片字段的值，并匹配分片函數，得到該SQL對應的分片列表，然后將SQL發往這些分片去執行，最后收集和處理所有分片返回的結果數據，并輸出到客戶端。以select* from Orders where prov=?語句為例，查到prov=wuhan，按照分片函數，wuhan返回dn1，于是SQL就發給了MySQL1，去取DB1上的查詢結果，并返回給用戶。

如果上述SQL改為select * from Orders where prov in (‘wuhan’,‘beijing’)，那么，SQL就會發給MySQL1與MySQL2去執行，然后結果集合并后輸出給用戶。但通常業務中我們的SQL會有Order By 以及Limit翻頁語法，此時就涉及到結果集在Mycat端的二次處理，這部分的代碼也比較復雜，而最復雜的則屬兩個表的Jion問題，為此，Mycat提出了創新性的ER分片、全局表、HBT（Human Brain Tech)人工智能的Catlet、以及結合Storm/Spark引擎等十八般武藝的解決辦法，從而成為目前業界最強大的方案。

<ending>

轉載注明出處：Scofield's blog[  http://blog.csdn.net/scotfield_msn/article/details/60344796  ]

references:

****