我來扯扯分布式數(shù)據(jù)庫系統(tǒng)DDBS的設(shè)計

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

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

一、   引入

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

1.1、概念

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

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

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

1.2、構(gòu)建之前的思考

       1、項目考慮構(gòu)建分布式數(shù)據(jù)庫的時機。

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

       2、考慮分布式數(shù)據(jù)庫中間件的有效性

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

       3、中間件對復(fù)雜SQL場景的支持度

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

二、   考慮的問題

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

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

2.1、一致性問題

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

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

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

2.2、數(shù)據(jù)分片

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

另外，在分布式數(shù)據(jù)庫中，存在著分區(qū)、分片、分庫、分表等的概念。

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

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

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

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

2.3、查詢優(yōu)化

在關(guān)系數(shù)據(jù)庫系統(tǒng)中有著非常重要的地位 ，關(guān)系查詢優(yōu)化是影響RDBMS性能的關(guān)鍵因素。分布式查詢優(yōu)化的目標(biāo)除了要解決集中式查詢處理的問題如：查詢轉(zhuǎn)換為代數(shù)表達(dá)式、從所有等價表達(dá)式中選擇最優(yōu)的代數(shù)表達(dá)式，還要考慮分布式獨有的問題：站點之間交換數(shù)據(jù)的操作、選擇最優(yōu)的執(zhí)行站點(分布）、數(shù)據(jù)被傳送的方式等等。

總的查詢優(yōu)化準(zhǔn)則是使得通訊費用最低和響應(yīng)時間最短，即以最小的總代價，在最短的響應(yīng)時間內(nèi)獲得需要的數(shù)據(jù)。首先，通訊費用與所傳輸?shù)臄?shù)據(jù)量和通信次數(shù)有關(guān)。再次，響應(yīng)時間和通信時間有關(guān)，也與局部處理時間有關(guān)。

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

1. 以總代價最小為標(biāo)準(zhǔn)，除了CPU代價和I/O代價之外，還包括數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)拇鷥r。

2. 以每個查詢的響應(yīng)時間最短為標(biāo)準(zhǔn)。響應(yīng)時間就是從接收查詢到完成查詢所需要的時間。它既與通信時間有關(guān)，又與局部處理時間有關(guān)，而通信費用與所傳輸?shù)臄?shù)據(jù)量和通信次數(shù)成正比。

2.4、事務(wù)管理

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

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

2.5、并發(fā)控制

通常，數(shù)據(jù)庫總有若干個事務(wù)在運行，這些事務(wù)可能并發(fā)地存取相同的數(shù)據(jù)，稱為事務(wù)的并發(fā)操作。當(dāng)數(shù)據(jù)庫中有多個事務(wù)并發(fā)執(zhí)行時，系統(tǒng)必須對并發(fā)事務(wù)之間的相互作用加以控制，這是通過并發(fā)控制機制來實現(xiàn)的。并發(fā)控制就是負(fù)責(zé)正確協(xié)調(diào)并發(fā)事務(wù)的執(zhí)行，保證這種并發(fā)的存取操作不至于破壞數(shù)據(jù)庫的完整性和一致性，確保并發(fā)執(zhí)行的多個事務(wù)能夠正確地運行并獲得正確的結(jié)果。

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

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

三、   方法論

3.0、DDBS設(shè)計方法

分布式數(shù)據(jù)庫的設(shè)計方法有三種：自頂向下方法，即重構(gòu)法；自底向上方法，即組合法；以及兩者的混合方法。

1、自頂向下方法

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

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

2、自底向上方法

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

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

3、混合方法

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

3.1、一致性問題

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

1、弱一致性（最終一致）：由于分布式系統(tǒng)在數(shù)據(jù)同步時的網(wǎng)絡(luò)延遲等等因素，無法保證副本數(shù)據(jù)和主節(jié)點時刻保持一致，當(dāng)出現(xiàn)不一致的時，可以采用以下幾種策略保證最終一致性：

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

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

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

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

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

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

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

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

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

Follower: 類似選民，完全被動

Candidate候選人: 類似Proposer律師，可以被選為一個新的領(lǐng)導(dǎo)人。

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

3.2、數(shù)據(jù)分片

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

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

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

1、水平分片

水平分片是將數(shù)據(jù)按照元組來劃分，在關(guān)系數(shù)據(jù)庫中也就是根據(jù)屬性的條件按照行劃分，該屬性叫做分片屬性，條件就是分片條件。又分為：基本水平分片：根據(jù)關(guān)系表本身的屬性分片。導(dǎo)出水平分片：分片屬性不是該關(guān)系表中的屬性。

2、垂直分片

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

3、混合分片

通過交替水平分片與垂直分片，可以產(chǎn)生混合分片。

3.3、查詢優(yōu)化

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

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

分布式查詢處理按不同的層次執(zhí)行，符合分布式數(shù)據(jù)庫系統(tǒng)的層次結(jié)構(gòu)。分布式查詢處理可分為如下所示四個層次結(jié)構(gòu)。

1、查詢分解

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

2、數(shù)據(jù)本地化

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

3、全局優(yōu)化

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

4、局部優(yōu)化

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

3.4、事務(wù)管理

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

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

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

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

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

3.5、并發(fā)控制

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

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

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

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

3、更新鎖（U鎖）

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

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

四、   DDBS中間件MyCat分析

4.1、Mycat簡介

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

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

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

4.2、MyCat功能

mycat在一個應(yīng)用系統(tǒng)中承擔(dān)著應(yīng)用層與數(shù)據(jù)層之間的中間層角色。結(jié)合項目按照自己對mycat的理解，它強大的地方在于：

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

2、獨創(chuàng)的ER關(guān)系分片，解決E-R分片難處理問題。

3、采用全局分片技術(shù)，每個節(jié)點同時并發(fā)插入和更新數(shù)據(jù)，每個節(jié)點都可以讀取數(shù)據(jù)。

4、通過人工智能的catlet支持跨分片復(fù)雜SQL實現(xiàn)以及存儲過程支持等。

4.3、Mycat結(jié)構(gòu)

Mycat的具體設(shè)計構(gòu)架如下圖。

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

4.4、Mycat原理簡析

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

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

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

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

<ending>

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

references:

****