MySQL 可擴(kuò)展設(shè)計(jì)的基本原則

前言

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

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

一、什么是可擴(kuò)展性

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

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

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

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

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

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

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

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

Scale Out 優(yōu)點(diǎn)：

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

Scale Out 缺點(diǎn)：

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

Scale Up 優(yōu)點(diǎn)：

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

Scale Up 缺點(diǎn)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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