MySQL集羣(PXC)入門

1、學習動機

伴隨互聯網行業的興起，愈來愈多的領域須要相應的技術方案，好比：打出軟件、電商平臺、直播平臺、電子支付、媒體社交。

身邊常見的，校園出成績那一年，咱們會感受網站異常的卡頓，由於訪問人數太多。

單機單點的數據庫，一旦這臺機子宕機(機器出現故障、機房停電、...)，那整個網站將沒法正常訪問。這時候集羣就出現了，一臺機器出現問題了，另外的機器還在正常運行，網站依舊能夠訪問。

集羣案例：滴滴出行、淘寶、京東、鬥魚直播、支付寶、微信、QQ

 

2、案例

1.天貓雙十一

　　2017年天貓雙十一的交易額達到1682億元，3分鐘破百億，9小時破千億

　　交易峯值(下訂單的峯值)：32.5萬/秒

　　支付峯值：25.6萬/秒

　　數據庫峯值：4200萬/秒

　　支持這麼漂亮的數字完美運行，除了數據庫集羣技術還有云服務器、負載均衡、RDS雲數據庫等技術

2.微信紅包

　　2017年除夕當天，全國人民總共收發142億個紅包，峯值42萬/秒

　　央視春晚微信搖一搖互動總量達110萬億次，峯值8.1億/秒

 

3、學習目標和方式

1.學習目標：

　　1）向大型互聯網應用看起，學習架構設計和業務處理

　　2）掌握PXC集羣MySQL方案的原理

　　3）掌握PXC集羣的強一致性

　　4）掌握PXC集羣的高可用方案

2.學習方式：由淺入深，按部就班；案例有小到大，逐步擴展

 

4、硬件環境需求

1.win10 x64專業版或者企業版（PXC不支持windows，須要用到虛擬機，因此最好不要使用home版或者32位的系統）/Linux/MacOS

2.Docker虛擬機

3.內存8GB以上

 

5、單節點數據庫的弊端

1.大型互聯網程序用戶羣裏龐大，因此架構必需要特殊設計

2.單節點的數據庫沒法知足性能上的要求，就像校園網查成績的時候，若是1萬人同時查，你可能拿到就是一個白屏，不管你是收費的仍是免費的數據庫，單節點都知足不了這種併發需求

3.單節點的數據庫沒有冗餘設計，沒法知足高可用，一旦這個機器出現問題，沒有其餘節點的數據庫頂替，那網站將沒法正常訪問

單節點數據庫測試，5000個鏈接，5000個併發查詢，平均就1個鏈接1個查詢，安裝好數據庫，配置好環境變量，[mysqld]下面配置最大鏈接量爲6000（max_connections=6000），執行下面的命令：

mysqlslap -hlocalhost -uroot -pabc123456 -P3306 --concurrency=5000 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement --engine=innodb --number-of-queries=5000

獲得下面的結論：

這才5000個併發，須要的時間就達到了34秒，若是設置10000個併發，將如何呢？

數據庫拒絕了不少請求，把沒有拒絕的執行了，須要的時間是167秒，這就是單擊單點在面對併發的時候數據庫的承受能力。

 

 6、PXC高可用集羣方案

這樣一個最基本的PXC集羣，它保證了每一個節點的的數據都是一致的，不會出現數據寫入了數據庫1而沒有寫入數據庫2的狀況，這種的集羣在遇到單表數據量超過2000萬的時候，mysql性能會受損，因此一個集羣還不夠，咱們須要把數據分到另外一個集羣，這個稱爲「切片」，就是把大量的數據拆分到不一樣的集羣中，每一個集羣的數據都是不同的，看下面的截圖：

這樣一來，PXC集羣1存前面1000萬條數據，PXC集羣2存後面1000萬條數據，當一個sql語句請求的時候，經過MyCat這個阿里巴巴的開源中間件，能夠把sql分到不一樣的集羣裏面去。這種的分片按照數量就是2個分片。

這個切分算法也比較多，好比按照日期、月份、年份、某一列的固定值，或者最簡單的按照主鍵值切分，主鍵對2求模，餘0的存分片1，餘1的存分片2，這樣MyCat就會把2000萬條數據均勻地分配到2個集羣上。

PXC雖然保證了數據的強一致性，可是這是以犧牲性能爲代價的，因此適合保存重要的數據，好比訂單。

 

7、Replication集羣方案

這種集羣，在第一個節點插入之後，就立刻返回給客戶端執行成功了，而後再作每一個節點之間的同步，若是某一個同步操做失敗了，那用戶請求的時候拿到的數據就不一樣步了，可是它的優點是速度快，不會犧牲任何地性能，適合保存不那麼重要的數據，好比日誌。

 

8、PXC與Replication集羣結合

 

9、系統架構方案

更加清晰和詳細架構請看下面的截圖

 

10、APP的架構設計

 客戶端包括web瀏覽器端，移動手機端，用戶經過客戶端發送一個請求後，Nginx接收到請求後，會作負載均衡，定向到當前最適合（相對沒那麼繁忙）處理這個請求的服務器端，服務端接收到請求後，再訪問數據庫，一些熱點數據須要作緩存，好比淘寶首頁的商品。從上面的圖中看，服務器端的某一個出現故障後，nginx會將請求定向到剩下的能正常運行的服務器上面，而數據庫端也是採用的集羣，這樣就達到了高可用，就是任意一臺機器出現故障，對整個網站的運行不會產生太大的影響，這裏可能有人會問若是nginx這臺服務器出現問題了怎麼辦？能夠作虛擬ip（vip）,配置主從入口，就是nginx1和nginx2的虛擬ip是同樣的，其中有一個是主入口，在主入口沒有出現問題的時候，從機是不會工做的，當主入口機出現問題了，從入口機就會頂替，若是主從都出現問題了，那網站將沒法訪問。

服務器端的spring與spring之間的調用又是如何的？如今都是分佈式調用，比較經典的是dubbo+zookeeper。這裏有同步調用和異步調用

同步調用：提出問題的一方直接調用處理問題的一方

異步調用：提出問題的一方將問題交個消息中間件，由消息中間件去將問題發放給處理問題的一方，在這裏，提出問題的一方稱爲「生產者」，處理問題的一方稱爲「消費者」，他們彼此是不知道對方是誰，達到業務解耦的效果，這樣作的好處是之後在部署項目、程序的升級、接口的變動的時候，它的影響面就很小。好比說生產者項目開發地有問題，而後用其餘語言再作了一個項目，對消費者不會產生任何影響，只要生產生能正常往消息隊列裏面發送消息就好；再好比用戶註冊一個淘寶帳號，咱們連帶着把支付寶帳號也給你開通，而後其餘的投資的項目也給用戶一些優惠（給你2張淘票票的電影票，免費一個月的蝦米音樂會員等等），對應淘寶這一端，它發起一個消息傳達給消息隊列，至於接收端是支付寶仍是淘票票仍是蝦米音樂，淘寶這一端不知道也不須要關心，等之後阿里再有什麼投資項目須要給新用戶優惠的時候，只須要從消息隊列裏接收消息就能夠，對生產者而言，沒有任何影響。若是是同步調用（dubbo或者webservice調用），其中一端有修改，另外一端必然也要改，這種強耦合是很差的。

如下是異步調用方案圖：