前言

隨著信息量的飛速增加，硬件設(shè)備的發(fā)展已經(jīng)慢慢的無法跟上應(yīng)用系統(tǒng)對處理能力的要求了。此時，我們?nèi)绾蝸斫鉀Q系統(tǒng)對性能的要求？

只有一個辦法，那就是通過改造系統(tǒng)的架構(gòu)體系，提升系統(tǒng)的擴展能力，通過組合多個低處理能力的硬件設(shè)備來達到一個高處理能力的系統(tǒng)，也就是說，我們必須進行可擴展設(shè)計。

一、什么是可擴展性

在討論可擴展性之前，可能很多朋有會問：常聽人說起某某網(wǎng)站某某系統(tǒng)在可擴展性方面設(shè)計的如何如何好，架構(gòu)如何如何出色，到底什么是擴展？怎樣算是可擴展？什么又是可擴展性呢？其實也就是大家常聽到的 Scale，Scalable 和 Scalability 這三個詞。

從數(shù)據(jù)庫的角度來說，Scale（擴展）就是讓我們的數(shù)據(jù)庫能夠提供更強的服務(wù)能力，更強的處理能力。而 Scalable（可擴展）則是表明數(shù)據(jù)庫系統(tǒng)在通過相應(yīng)升級（包括增加單機處理能力或者增加服務(wù)器數(shù)量）之后能夠達到提供更強處理能力。在理論能上來說，任何數(shù)據(jù)庫系統(tǒng)都是 Scalable 的，只不過是所需要的實現(xiàn)方式不一樣而已。

最后， Scalability（擴展性）則是指一個數(shù)據(jù)庫系統(tǒng)通過相應(yīng)的升級之后所帶來處理能力提升的難以程度。雖然理論上任何系統(tǒng)都可以通過相應(yīng)的升級來達到處理能力的提升，但是不同的系統(tǒng)提升相同的處理能力所需要的升級成本（資金和人力）是不一樣的，這也就是我們所說的各個數(shù)據(jù)庫應(yīng)用系統(tǒng)的 Scalability 存在很大的差異。

在這里，我所說的不同數(shù)據(jù)庫應(yīng)用系統(tǒng)并不是指數(shù)據(jù)庫軟件本身的不同（雖然數(shù)據(jù)庫軟件不同也會存在 Scalability 的差異），而是指相同數(shù)據(jù)庫軟件的不同應(yīng)用架構(gòu)設(shè)計。

首先，我們需要清楚一個數(shù)據(jù)庫據(jù)系統(tǒng)的擴展性實際上是主要體現(xiàn)在兩個方面，一個是橫向擴展，另一個則是縱向擴展，也就是我們常說的 Scale Out 和 Scale Up。

Scale Out 就是指橫向的擴展，向外擴展，也就是通過增加處理節(jié)點的方式來提高整體處理能力，說的更實際一點就是通過增加機器來增加整體的處理能力。

Scale Up 則是指縱向的擴展，向上擴展，也就是通過增加當(dāng)前處理節(jié)點的處理能力來提高整體的處理能力，說白了就是通過升級現(xiàn)有服務(wù)器的配置，如增加內(nèi)存，增加 CPU，增加存儲系統(tǒng)的硬件配置，或者是直接更換為處理能力更強的服務(wù)器和更為高端的存儲系統(tǒng)。

通過比較兩種 Scale 方式，我們很容易看出各自的優(yōu)缺點。

Scale Out 優(yōu)點：

1. 成本低，很容易通過價格低廉的 PC Server 搭建出一個處理能力非常強大的計算集群；
2. 不太容易遇到瓶頸，因為很容易通過添加主機來增加處理能力；
3. 單個節(jié)點故障對系統(tǒng)整體影響較?。灰泊嬖谌秉c，更多的計算節(jié)點，大部分時候都是服務(wù)器主機，這自然會帶來整個系統(tǒng)維護復(fù)雜性的提高，在某些方面肯定會增加維護成本，而且對應(yīng)用系統(tǒng)的架構(gòu)要求也會比 Scale Up 更高，需要集群管理軟件的配合。
   

Scale Out 缺點：

1. 處理節(jié)點多，造成系統(tǒng)架構(gòu)整體復(fù)雜度提高，應(yīng)用程序復(fù)雜度提高；
2. 集群維護難以程度更高，維護成本更大；

Scale Up 優(yōu)點：

1. 處理節(jié)點少，維護相對簡單；
2. 所有數(shù)據(jù)都集中在一起，應(yīng)用系統(tǒng)架構(gòu)簡單，開發(fā)相對容易；
   

Scale Up 缺點：

高端設(shè)備成本高，且競爭少，容易受到廠家限制；
受到硬件設(shè)備發(fā)展速度限制，單臺主機的處理能力總是有極限的，容易遇到最終無法解決的性能瓶頸；
設(shè)備和數(shù)據(jù)集中，發(fā)生故障后的影響較大；
從短期來看，Scale Up 會有更大的優(yōu)勢，因為可以簡化運維成本，簡化系統(tǒng)架構(gòu)和應(yīng)用系統(tǒng)的開發(fā)，對技術(shù)方面的要求要會更簡單一些。

但是，從長遠影響來看，Scale Out 會有更大的優(yōu)勢，而且也是系統(tǒng)達到一個規(guī)模之后的必然趨勢。因為不管怎樣，單臺機器的處理能力總是會受到硬件技術(shù)的限制，而硬件技術(shù)的發(fā)展速度總是有限的，很多時候很難跟得上業(yè)務(wù)發(fā)展的速度。而且越是高處理能力的高端設(shè)備，其性價比總是會越差。所以通過多臺廉價的 PC Server 構(gòu)建高處理能力的分布式集群，總是會成為各個公司節(jié)約成本，提高整體處理能力的一個目標(biāo)。雖然在實現(xiàn)這個目標(biāo)的時候可能會遇到各種各樣的技術(shù)問題，但總是值得去研究實踐的。

后面的內(nèi)容，我們將重點針對 Scale Out 方面來進行分析設(shè)計。要能夠很好的 Scale Out，勢必需要進行分布式的系統(tǒng)設(shè)計。對于數(shù)據(jù)庫，要想較好的 Scale Out，我們只有兩個方向，一個是通過數(shù)據(jù)的不斷復(fù)制來實現(xiàn)很多個完全一樣的數(shù)據(jù)源來進行擴展，另一個就是通過將一個集中的數(shù)據(jù)源切分成很多個數(shù)據(jù)源來實現(xiàn)擴展。

下面我們先看看在設(shè)計一個具有很好的 Scalability 的數(shù)據(jù)庫應(yīng)用系統(tǒng)架構(gòu)方面，需要遵循一些什么樣的原則。

二、事務(wù)相關(guān)性最小化原則

搭建分布式數(shù)據(jù)庫集群的時候，很多人都會比較關(guān)心事務(wù)的問題。畢竟事務(wù)是數(shù)據(jù)庫中非常核心的一個功能。

在傳統(tǒng)的集中式數(shù)據(jù)庫架構(gòu)中，事務(wù)的問題非常好解決，可以完全依賴數(shù)據(jù)庫本身非常成熟的事務(wù)機制來保證。但是一旦我們的數(shù)據(jù)庫作為分布式的架構(gòu)之后，很多原來在單一數(shù)據(jù)庫中所完成的事務(wù)現(xiàn)在可能需要跨多個數(shù)據(jù)庫主機，這樣原來單機事務(wù)可能就需要引入分布式事務(wù)的概念。

但是大家肯定也有一些了解，分布式事務(wù)本身就是一個非常復(fù)雜的機制，不管是商業(yè)的大型數(shù)據(jù)庫系統(tǒng)還是各開源數(shù)據(jù)庫系統(tǒng)，雖然大多數(shù)數(shù)據(jù)庫廠家基本上都實現(xiàn)了這個功能，但或多或少都存在各種各樣的限制。而且也存在一些 Bug，可能造成某些事務(wù)并不能很好的保證，或者是不能順利的完成。

這時候，我們可能就需要尋求其他的替代方案來解決這個問題，畢竟事務(wù)是不可忽視的 ，不關(guān)我們?nèi)绾稳崿F(xiàn)，總是需要實現(xiàn)的。

就目前來說，主要存在的一些解決方案主要有以下三種：

第一、進行 Scale Out 設(shè)計的時候合理設(shè)計切分規(guī)則，盡可能保證事務(wù)所需數(shù)據(jù)在同一個 MySQL Server 上，避免分布式事務(wù)。

如果可以在設(shè)計數(shù)據(jù)切分規(guī)則的時候就做到所有事務(wù)都能夠在單個 MySQL Server 上面完成，我們的業(yè)務(wù)需求就可以比較容易的實現(xiàn)，應(yīng)用程序就可以做到通過最少的調(diào)整來滿足架構(gòu)的改動，使整體成本大大減少。畢竟，數(shù)據(jù)庫架構(gòu)改造并不僅僅只是 DBA 的事情，還需要很多外圍的配合與支持。即使是在設(shè)計一個全新系統(tǒng)的時候，我們同樣要考慮到各個環(huán)境各項工作的整體投入，既要考慮數(shù)據(jù)庫本身的成本投入，同時也要考慮到相應(yīng)的開發(fā)代價。如果各環(huán)節(jié)之間出現(xiàn)“利益”沖突，那我們就必須要作出一個基于后續(xù)擴展以及總體成本的權(quán)衡，尋找出一個最適合當(dāng)前階段平衡點。

不過，即使我們的切分規(guī)則設(shè)計的再高明，也很難讓所有的事務(wù)所需的數(shù)據(jù)都在同一個 MySQL Server 上。所以，雖然這種解決方案所需要付出的成本最小，但大多數(shù)時候也只能兼顧到一些大部分的核心事務(wù)，也不是一個很完美的解決方案。

第二、大事務(wù)切分成多個小事務(wù)，數(shù)據(jù)庫保證各個小事務(wù)的完整性，應(yīng)用控制各個小事務(wù)之間的整體事務(wù)完整性。

和上一個方案相比，這個方案所帶來的應(yīng)用改造就會更多，對應(yīng)用的要求也會更為苛刻 。應(yīng)用不僅需要分拆原來的很多大事務(wù)，同時還需要保證各個小事務(wù)的之間的完整性。也就是說，應(yīng)用程序自己需要具有一定的事務(wù)能力，這無疑會增加應(yīng)用程序的技術(shù)難度。

但是，這個方案也有不少自己的優(yōu)勢。首先我們的數(shù)據(jù)的切分規(guī)則就會更為簡單，很難遇到限制。而且更簡單，就意味著維護成本更低。其次，沒有數(shù)據(jù)切分規(guī)則的太多限制，數(shù)據(jù)庫方面的可擴展性也會更高，不會受到太多的約束，當(dāng)出現(xiàn)性能瓶頸的時候可以快速進行進一步拆分現(xiàn)有數(shù)據(jù)庫。最后，數(shù)據(jù)庫做到離實際業(yè)務(wù)邏輯更遠，對后續(xù)架構(gòu)擴展也就更為有利。

第三、結(jié)合上述兩種解決方案，整合各自的優(yōu)勢，避免各自的弊端。

前面兩種解決方案都存在各自的優(yōu)缺點，而且基本上都是相互對立的，我們完全可以利用兩者各自的優(yōu)勢，調(diào)整兩個方案的設(shè)計原則，在整個架構(gòu)設(shè)計中做一個平衡。比如我們可以在保證部分核心事務(wù)所需數(shù)據(jù)在同一個 MySQL Server 上，而其他并不是特別重要的事務(wù)，則通過分拆成小事務(wù)和應(yīng)用系統(tǒng)結(jié)合來保證。而且，對于有些并不是特別重要的事務(wù)，我們也可以通過深入分析，看是否不可避免一定需要使用事務(wù)。

通過這樣相互平衡設(shè)計的原則，我們既可以避免應(yīng)用程序需要處理太多的小事務(wù)來保證其整體的完整性，同時也能夠避免拆分規(guī)則太多復(fù)雜而帶來后期維護難度的增加及擴展性受阻的情況。

當(dāng)然，并不是所有的應(yīng)用場景都非要結(jié)合以上兩種方案來解決。比如對于那些對事務(wù)要求并不是特別嚴(yán)格，或者事務(wù)本身就非常簡單的應(yīng)用，就完全可以通過稍加設(shè)計的拆分規(guī)則就可滿足相關(guān)要求，我們完全可以僅僅使用第一種方案，就可以避免還需要應(yīng)用程序來維護某些小事務(wù)的整體完整性的支持。這在很大程度上面可以降低應(yīng)用程序的復(fù)雜度。

而對于那些事務(wù)關(guān)系非常復(fù)雜，數(shù)據(jù)之間的關(guān)聯(lián)度非常高的應(yīng)用，我們也就沒有必要為了保持事務(wù)數(shù)據(jù)能夠集中而努力設(shè)計，因為不管我們?nèi)绾闻?，都很難滿足要求，大都是遇到顧此失彼的情景。對于這種情況，我們還不如讓數(shù)據(jù)庫方面盡可能保持簡潔，而讓應(yīng)用程序做出一些犧牲。

在當(dāng)前很多大型的互聯(lián)網(wǎng)應(yīng)用中，不論是上面哪一種解決方案的使用案例都有，如大家所熟知的 Ebay，在很大程度上就是第三種結(jié)合的方案。在結(jié)合過程中以第二種方案為主，第一種方案為輔。選擇這樣的架構(gòu)，除了他們應(yīng)用場景的需求之外，其較強的技術(shù)實力也為開發(fā)足夠強壯的應(yīng)用系統(tǒng)提供了保證。又如某國內(nèi)大型的 BBS 應(yīng)用系統(tǒng)（不便公開其真實名稱），其事務(wù)關(guān)聯(lián)性并不是特別的復(fù)雜，各個功能模塊之間的數(shù)據(jù)關(guān)聯(lián)性并不是特別的高，就是完全采用第一種解決方案，完全通過合理設(shè)計數(shù)據(jù)拆分的規(guī)則來避免事務(wù)的數(shù)據(jù)源跨多個 MySQL Server。

最后，我們還需要明白一個觀點，那就是事務(wù)并不是越多越好，而是越少越好越小越好 。不論我們使用何種解決方案，那就是在我們設(shè)計應(yīng)用程序的時候，都需要盡可能做到讓數(shù)據(jù)的事務(wù)相關(guān)性更小，甚至是不需要事務(wù)相關(guān)性。當(dāng)然，這只是相對的，也肯定只有部分?jǐn)?shù)據(jù)能夠做到。但可能就是某部分?jǐn)?shù)據(jù)做到了無事務(wù)相關(guān)性之后，系統(tǒng)整體復(fù)雜度就會降低很大一個層次，應(yīng)用程序和數(shù)據(jù)庫系統(tǒng)兩方面都可能少付出很多的代價。

三、數(shù)據(jù)一致性原則

不論是 Scale Up 還是 Scale Out，不論我們?nèi)绾卧O(shè)計自己的架構(gòu)，保證數(shù)據(jù)的最終一致性都是絕對不能違背的原則，保證這個原則的重要性我想各位讀者肯定也都是非常明白清楚的。

而且，數(shù)據(jù)一致性的保證就像事務(wù)完整性一樣，在我們對系統(tǒng)進行 Scale Out 設(shè)計的時候，也可能會遇到一些問題。當(dāng)然，如果是 Scale Up，可能就很少會遇到這類麻煩了。當(dāng)然，在很多人眼中，數(shù)據(jù)的一致性在某種程度上面也是屬于事務(wù)完整性的范疇。不過這里為了突出其重要性和相關(guān)特性，我還是將他單獨提出來分析。

那我們又如何在 Scale Out 的同時又較好的保證數(shù)據(jù)一致性呢？很多時候這個問題和保證事務(wù)完整性一樣讓我們頭疼，也同樣受到了很多架構(gòu)師的關(guān)注。經(jīng)過很多人的實踐，大家最后總結(jié)出了 BASE 模型。即：基本可用，柔性狀態(tài)，基本一致和最終一致。 這幾個詞看著挺復(fù)雜挺深奧，其實大家可以簡單的理解為非實時的一致性原則。

也就是說，應(yīng)用系統(tǒng)通過相關(guān)的技術(shù)實現(xiàn)，讓整個系統(tǒng)在滿足用戶使用的基礎(chǔ)上，允許數(shù)據(jù)短時間內(nèi)處于非實時狀態(tài)，而通過后續(xù)技術(shù)來保證數(shù)據(jù)在最終保證處于一致狀態(tài)。這個理論模型說起來確實聽簡單，但實際實現(xiàn)過程中我們也會遇到不少難題。

首先，第一個問題就是我們需要讓所有數(shù)據(jù)都是非實時一致嗎？我想大多數(shù)讀者朋友肯定是投反對票的。那如果不是所有的數(shù)據(jù)都是非實時一致，那我們又該如何來確定哪些數(shù)據(jù)需要實時一致哪些數(shù)據(jù)又只需要非實時的最終一致呢？其實這基本可以說是一個各模塊業(yè)務(wù)優(yōu)先級的劃分，對于優(yōu)先級高的自然是規(guī)屬于保證數(shù)據(jù)實時一致性的陣營，而優(yōu)先級略低的應(yīng)用，則可以考慮劃分到允許短時間端內(nèi)不一致而最終一致的陣營。這是一個非常棘手的問題。我們不能隨便拍腦袋就決定，而是需要通過非常詳細的分析和仔細的評估才能作出決定。因為不是所有數(shù)據(jù)都可以出現(xiàn)在系統(tǒng)能不短時間段內(nèi)不一致狀態(tài)，也不是所有數(shù)據(jù)都可以通過后期處理的使數(shù)據(jù)最終達到一致的狀態(tài)，所以之少這兩類數(shù)據(jù)就是需要實時一致的。而如何區(qū)分出這兩類數(shù)據(jù)，就必須經(jīng)過詳細的分析業(yè)務(wù)場景商業(yè)需求后進行充分的評估才能得出結(jié)論。

其次，如何讓系統(tǒng)中的不一致數(shù)據(jù)達到最終一致？一般來說，我們必須將這類數(shù)據(jù)所設(shè)計到的業(yè)務(wù)模塊和需要實時一致數(shù)據(jù)的業(yè)務(wù)模塊明確的劃分開來。然后通過相關(guān)的異步機制技術(shù)，利用相應(yīng)的后臺進程，通過系統(tǒng)中的數(shù)據(jù)，日志等信息將當(dāng)前并不一致的數(shù)據(jù)進行進一步處理，使最終數(shù)據(jù)處于完全一致狀態(tài)。對于不同的模塊，使用不同的后臺進程，既可以避免數(shù)據(jù)出現(xiàn)紊亂，也可以并發(fā)執(zhí)行，提高處理效率。如對用戶的消息通知之類的信息，就沒有必要做到嚴(yán)格的實時一致性，只需要現(xiàn)記錄下需要處理的消息，然后讓后臺的處理進程依次處理，避免造成前臺業(yè)務(wù)的擁塞。

最后，避免實時一致與最終一致兩類數(shù)據(jù)的前臺在線交互。由于兩類數(shù)據(jù)狀態(tài)的不一致性，很可能會導(dǎo)致兩類數(shù)據(jù)在交互過程中出現(xiàn)紊亂，應(yīng)該盡量讓所有非實時一致的數(shù)據(jù)和實時一致數(shù)據(jù)在應(yīng)用程序中得到有效的隔離。甚至在有些特別的場景下，記錄在不同的 MySQL Server 中來進行物理隔離都是有必要的。

四、高可用及數(shù)據(jù)安全原則

除了上面兩個原則之外，我還想提一下系統(tǒng)高可用及數(shù)據(jù)安這兩方面。經(jīng)過我們的 Scale Out 設(shè)計之后，系統(tǒng)整體可擴展性確實是會得到很大的提高，整體性能自然也很容易得到較大的改善。但是，系統(tǒng)整體的可用性維護方面卻是變得比以前更為困難。因為系統(tǒng)整體架構(gòu)復(fù)雜了，不論是應(yīng)用程序還是數(shù)據(jù)庫環(huán)境方面都會比原來更為龐大，更為復(fù)雜。這樣所帶來的最直接影響就是維護難度更大，系統(tǒng)監(jiān)控更難。

如果這樣的設(shè)計改造所帶來的結(jié)果是我們系統(tǒng)經(jīng)常性的 Crash，經(jīng)常性的出現(xiàn) Down 機事故，我想大家肯定是無法接受的，所以我們必須通過各種技術(shù)手段來保證系統(tǒng)的可用性不會降低，甚至在整體上有所提高。

所以，這里很自然就引出了我們在進行 Scale Out 設(shè)計過程中另一個原則，也就是高可用性的原則。不論如何調(diào)整設(shè)計系統(tǒng)的架構(gòu)，系統(tǒng)的整體可用性不能被降低。

其實在討論系統(tǒng)可用性的同時，還會很自然的引出另外一個與之密切相關(guān)的原則，那就是數(shù)據(jù)安全原則。要想達到高可用，數(shù)據(jù)庫中的數(shù)據(jù)就必須是足夠安全的。這里所指的安全并不針對惡意攻擊或者竊取方面來說，而是針對異常丟失。也就是說，我們必須保證在出現(xiàn) 軟/硬件故障 的時候，能夠保證我們的數(shù)據(jù)不會出現(xiàn)丟失。數(shù)據(jù)一旦丟失，根本就無可用性可言了。而且，數(shù)據(jù)本身就是數(shù)據(jù)庫應(yīng)用系統(tǒng)最核心的資源，絕對不能丟失這一原則也是毋庸置疑的。

要確保高可用及數(shù)據(jù)安全原則，最好的辦法就是通過冗余機制來保證。所有軟硬件設(shè)備都去除單點隱患，所有數(shù)據(jù)都存在多份拷貝。這樣才能夠較好的確保這一原則。在技術(shù)方面 ，我們可以通過 MySQL Replication，MySQL Cluster 等技術(shù)來實現(xiàn)。

總結(jié)

不論我們?nèi)绾卧O(shè)計架構(gòu)，不管我們的可擴展性如何變化，本章中所提到的一些原則都是非常重要的。不論是解決某些問題的原則，還是保證性的原則，不論是保證可用性的原則，還是保證數(shù)據(jù)安全的原則，我們都應(yīng)該在設(shè)計中時時刻刻都關(guān)注，謹(jǐn)記。

MySQL 數(shù)據(jù)庫之所以在互聯(lián)網(wǎng)行業(yè)如此火爆，除了其開源的特性，使用簡單之外，還有一個非常重要的因素就是在擴展性方面有較大的優(yōu)勢。其不同存儲引擎各自所擁有的特性可以應(yīng)對各種不同的應(yīng)用場景。其 Replication 以及 Cluster 等特性更是提升擴展性非常有效的手段。

以上就是MySQL 可擴展設(shè)計的基本原則的詳細內(nèi)容，更多關(guān)于MySQL 可擴展設(shè)計的資料請關(guān)注腳本之家其它相關(guān)文章！