前言

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

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

一、什么是可擴展性

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

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

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

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

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

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

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

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

Scale Out 優(yōu)點：

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

Scale Out 缺點：

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

Scale Up 優(yōu)點：

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

Scale Up 缺點：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

也就是說，應用系統(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è)務優(yōu)先級的劃分，對于優(yōu)先級高的自然是規(guī)屬于保證數(shù)據(jù)實時一致性的陣營，而優(yōu)先級略低的應用，則可以考慮劃分到允許短時間端內(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è)務場景商業(yè)需求后進行充分的評估才能得出結(jié)論。

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

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

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

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

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

所以，這里很自然就引出了我們在進行 Scale Out 設計過程中另一個原則，也就是高可用性的原則。不論如何調(diào)整設計系統(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ù)庫應用系統(tǒng)最核心的資源，絕對不能丟失這一原則也是毋庸置疑的。

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

總結(jié)

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

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

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

最新評論