? mysql集群方案這里介紹2種，PXC 和 Replication。

大型互聯網程序用戶群體龐大，所以架構設計單節點數據庫已經無法滿足需求。大家也深有體會，有一萬人在學校網站查成績或是選課的時候網站時常是訪問不了或者相應特別特別慢。這種情況就凸顯出來單機單節點上性能的不足。無論你使用什么樣的數據庫免費的或者付費的單機單節點都是無法承受某個點上面的并發的，另外一方面就是數據庫沒有做冗余設計。這時候我們就需要做集群和冗余保證數據庫的高可用和高性能提升用戶體驗。

? ? 下面我們先來用一組數據來做數據庫單節點壓力測試：

?1.使用5000個用戶做5000次查詢，平均下拉每個用戶查詢一次。

我們看到系統結果顯示5000次并發的話執行的時間是 7.671秒，以上5000并發來講的話數據庫發揮還是比較正常的沒有出現崩潰宕機。

2.下面我們把5000次并發和查詢次數都增大1倍改成10000看看會出現什么情況。

如上當并發為10000的時候系統提示 沒有那么多的連接應對并發的訪問，系統拒絕了很多請求。最終執行的結果是48.547秒，這并不是說系統執行了我們所有的請求，它只是執行了一部分用了48秒。那么我們如果在網站上使用單機單節點的部署只要有1000并發訪問那么系統馬上崩潰！這還僅僅是1000個用戶，那么對于搞電商的同學如何來應對運營的秒殺 促銷活動？所以對于我們晨光這樣的大公司在做數據庫設計的時候一定采用集群集群集群這樣的方案。

接下來我們介紹一下晨光科力普數據庫集群是如何去設計搭建以及如何進化的。

1.PXC方案

我們先是采用目前最主流的PXC方案把數據庫集群在一起。PXC它最大的特性就是讀寫強一致并且每個節點都是可以作為讀寫的入口，這種方案的好處就是我們無論在任何一個節點寫入數據那么其他的庫肯定會同步到這條數據，絕對絕對不會出現說在A庫上面寫數據然后B庫查不到這種假設。

我們使用 haproxy 負載均衡中間件，當HA接收到一個增刪改查的請求時他會把你的sql語句路由分發到不同的PXC節點讓他們去分別執行。

那么你以為這樣的設計就Ok了？我告訴你這樣是遠遠不夠的，我們知道mysql有一個性能瓶頸就是單表數據超過2000W 那么它的性能會急劇下降，所以我們在操作的時候要盡量避免單表存儲的數據超過2000W。

那么這時候我們就要涉及到另外一個概念 數據切分,?所以數據切分我們還是采用同樣的PXC集群方案如下圖：

這里我們使用MyCat做數據切分，MyCat是阿里開源的一個mysql數據切分中間件，支持 離散分片（枚舉，程序指定分區，十進制求模，字符串hash,一致hash）和 連續分片（自定義數字范圍，按日期分，按單月小時，按自然月分）等mysql數據庫分片策略。

這里有個術語叫做分片，例如上圖中 集群1是一個分片區 集群2 就是另外一個分片區。

我們在執行一個Insert sql語句的時候mycat就可以根據指定的策略來存儲我們的數據，例如按照月份把 1月 3月 5月的數據存儲到集群1中 其他月份的存儲在集群2中。

采用這種方案我們就避免了mysql單表的性能瓶頸，如果2個集群不夠就在加集群，使勁加加ok。縱覽全局這樣才是一個比較好的mysql集群方案，但是。這樣還沒有完，PXC集群方案是以犧性能為代價的，所以才保證了數據庫的強一致性，所以你的pxc數據庫越多性能就會越低，接下來我介紹另外一種集群方案Replication。

2.Replication方案介紹

Replication這種方案不會犧牲性能，但是有個問題就是非強一致性，例如你在DB1中寫入數據可能會因為網絡抖動在DB2中查詢不到數據，這時候客戶端接收到的狀態是已經操作成功。另外有一點是這種集群方案只能在一個節點中做寫入操作，因為他的底層同步原理是單向同步的。

這種方案我們也會有mysql單表2000W數據瓶頸，我們也要做數據的切分，這里也會用mycat這個中間件來做數據切分，如下圖：

?以上2種方案，一種是數據強一致性，一種是非強一致性，強一致性的話可以用來保存一些有價值的數據例如訂單，支付等，非強一致性方案可以用來保存用戶的操作或者用戶行為瀏覽等數據。一個大型系統中單采用某一種方案是不夠的。下面我們演進為2種方案結合使用如下圖。

我們可以根據不同的業務和數據等級讓MyCat來分片決定要把數據落到哪個庫上！

3. PXC介紹

? ? PXC 全稱 Percona XtraDB Cluster,它是基于mysql自帶的一種集群技術 Galera做的改進來實現的一種數據庫集群方案，它有一個很明顯的特點就是任何節點都是可讀寫的，都可以被充當主節點來使用的。

并且他是數據強一致性的只要在任何一個節點種寫入數據其他的節點種肯定會同步到這條數據的。?

PXC原理：

我們使用UML圖來介紹一下PXC的執行過程。

這里我們用PXC中3個DB節點來介紹其原理，分別是DB1 DB3 和DB3, 數據的同步使用ＰＸＣ。

先從clent說起 clent在執行insert del up 的時候，正常db1會給我們返回執行的結果，如果我們不提交事務的話是不能持久化到數據庫中的。我們想要真實的持久化就必須要提交事務。這里在提交事務的時候不僅僅要在當前節點里面持久化數據還要在其他節點持久化數據畢竟我們是在pxc環境中操作的。

首先在提交事務的時候,db1會把數據傳遞給pxc, pxc會復制當前節點的數據 然后分發給DB2 和DB3，分發后要做的就是持久化這些數據。

事務的執行操作在pxc中會生產一個GTID編號，然后由db2 和db3去分別執行這個事務，每個db執行完成后會把結果返回給db1,然后db1收到其他db的執行結果后在本地也執行一下GTID的這個事務db1執行完成后沒問題問題的話最終會把執行的結果返回給客戶端。

通過這個時序圖我們可以知道在pxc中的數據強一致，肯定是所有的數據庫中的數據都是一致的。

4: pxc與replication 方案優劣：

? ?pxc 采用的是同步復制，事務在所有集群中要么全提交要么不提交，保證了數據的一致性。它寫入數據速度慢

? replication 采用的是異步復制，無法保證數據的一致性。它寫入數據速度快。

這2種方案僅僅是都實現了數據的同步，沒有數據切分功能。

5：pxc與replication 方案組合：

? ?pxc方案存儲高價值數據 如：賬戶 訂單 交易數據等。。

? ?replication 方案存儲低價值數據：如 通知 日志 等。。

? ?用其他的中間件如mycat來切分數據管理集群。

如果你覺得所有收獲請多多支持。

總結

以上是生活随笔為你收集整理的MySQL 集群方案介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。