10分鐘搞懂：億級使用者的分散式資料儲存解決方案！

來源：IT進階思維原創，轉載請註明原出處

內容提供：李智慧，前阿里巴巴技術專家，《大型網站技術架構》作者

6月6日晚，林志玲與Akira公佈婚訊、徐蔡坤祝福高考同學超常發揮，粉絲們百萬的轉發和點贊造成微博短暫當機。

分散式資料庫和分散式儲存是分散式系統中難度最大、挑戰最大，也是最容易出問題的地方。網際網路公司只有解決分散式資料儲存的問題，才能支撐更多次億級使用者的湧入。

接下來，你將花費十分鐘掌握以下三方面內容：

1、MySQL複製：包括主從複製和主主複製；

2、資料分片：資料分片的原理、分片的方案、分片資料庫的擴容；

3、資料庫分散式部署的幾種方案。

 

一、MySQL複製

1.MySQL的主從複製

MySQL的主從複製，就是將MySQL主資料庫中的資料複製到從資料庫中去。

主要目的是實現資料庫讀寫分離，寫操作訪問主資料庫，讀操作訪問從資料庫，從而使資料庫具有更強大的訪問負載能力，支撐更多的使用者訪問。       

它的主要的複製原理是：當應用程式客戶端傳送一條更新命令到資料庫的時候，資料庫會把這條更新命令同步記錄到Binlog中，然後由另外一個執行緒從Binlog中讀取這條日誌，然後通過遠端通訊的方式將它複製到從伺服器上面去，從伺服器獲得這條更新日誌後，將其加入到自己的Relay log中，然後由另外一個SQL執行執行緒從Relay log中讀取這條新的日誌，並把它在本地的資料庫中重新執行一遍。

這樣當客戶端應用程式執行一個update命令的時候，這個命令會在主資料庫和從資料庫上同步執行，從而實現了主資料庫向從資料庫的複製，讓從資料庫和主資料庫保持一樣的資料。

 

2.MySQL的一主多從複製

MySQL的主從複製是一種資料同步機制，除了可以將一個主資料庫中的資料同步複製到一個從資料庫上，還可以將一個主資料庫上的資料同步複製到多個從資料庫上，也就是所謂的MySQL的一主多從複製。

       

多個從資料庫關聯到主資料庫後，將主資料庫上的Binlog日誌同步地複製到了多個從資料庫上。通過執行日誌，讓每個從資料庫的資料都和主資料庫上的資料保持了一致。這裡面的資料更新操作表示的是所有資料庫的更新操作，除了不包括SELECT之類的查詢讀操作，其他的INSERT、DELETE、UPDATE這樣的DML寫操作，以及CREATE TABLE、DROPT ABLE、ALTER TABLE等DDL操作也都可以同步複製到從資料庫上去。

 

3.一主多從複製的優點

一主多從複製有四大優點，分別是分攤負載、專機專用、便於冷備和高可用。 

a.分攤負載

將只讀操作分佈在多個從資料庫上，從而將負載分攤到多臺伺服器上。

b.專機專用

可以針對不同型別的查詢，使用不同的從伺服器。

c.便於進行冷備

即使資料庫進行了一主多從的複製，在一些極端的情況下。也可能會導致整個資料中心的資料伺服器都丟失。所以通常說來很多公司會對資料做冷備，但是進行冷備的時候有一個困難點在於，資料庫如果正在進行寫操作，冷備的資料就可能不完整，資料檔案可能處於損壞狀態。使用一主多從的複製就就可以實現零停機時間的備份。只需要關閉資料的資料複製程式，檔案就處於關閉狀態了，然後進行資料檔案拷貝，拷貝完成後再重新開啟資料複製就可以了。

d.高可用

如果一臺伺服器當機了，只要不發請求給這臺伺服器就不會出問題。當這臺伺服器恢復的時候，重新發請求到這臺伺服器。所以，在一主多從的情況下，某一臺從伺服器當機不可用，對整個系統的影響是非常小的。

 

4.MySQL的主主複製

但是一主多從只能夠實現從伺服器上的這些優點，當主資料庫當機不可用的時候，資料依然是不能夠寫入的，因為資料不能夠寫入到從伺服器上面去，從伺服器是隻讀的。

為了解決主伺服器的可用性問題，我們可以使用MySQL的主主複製方案。所謂的主主複製方案是指兩臺伺服器都當作主伺服器，任何一臺伺服器上收到的寫操作都會複製到另一臺伺服器上。       

 

如上主主複製原理圖，當客戶端程式對主伺服器A進行資料更新操作的時候，主伺服器A會把更新操作寫入到Binlog日誌中。然後Binlog會將資料日誌同步到主伺服器B，寫入到主伺服器的Relay log中，然後執Relay log，獲得Relay log中的更新日誌，執行SQL操作寫入到資料庫伺服器B的本地資料庫中。B伺服器上的更新也同樣通過Binlog複製到了伺服器A的Relay log中，然後通過Relay log將資料更新到伺服器A中。

通過這種方式，伺服器A或者B任何一臺伺服器收到了資料的寫的操作都會同步更新到另一臺伺服器，實現了資料庫主主複製。主主複製可以提高系統的寫可用，實現寫操作的高可用。

 

5.MySQL的主主失效恢復

使用MySQL伺服器實現主主複製時，資料庫伺服器失效該如何應對？

正常情況下使用者會寫入到主伺服器A中，然後資料從A複製到主伺服器B上。當主伺服器A失效的時候，寫操作會被髮送到主伺服器B中去，資料從B伺服器複製到A伺服器。

主主失效的維護過程如下：

       

最開始的時候，所有的主伺服器都可以正常使用，當主伺服器A失效的時候，進入故障狀態，應用程式檢測到主伺服器A失效，檢測到這個失效可能需要幾秒鐘或者幾分鐘的時間，然後應用程式需要進行失效轉移，將寫操作傳送到備份主伺服器B上面去，將讀操作傳送到B伺服器對應的從伺服器上面去。

一段時間後故障結束，A伺服器需要重建失效期間丟失的資料，也就是把自己當作從伺服器從B伺服器上面去同步資料。同步完成後系統才能恢復正常。這個時候B伺服器是使用者的主要訪問伺服器，A伺服器當作備份伺服器。

 

5.MySQL複製注意事項

使用MySQL進行主主複製的時候需要注意的事項如下：

a.不要對兩個資料庫同時進行資料寫操作，因為這種情況會導致資料衝突。

b.複製只是增加了資料的讀併發處理能力，並沒有增加寫併發的能力和系統儲存能力。

c.更新資料表的結構會導致巨大的同步延遲。

需要更新表結構的操作，不要寫入到到Binlog中，要關閉更新表結構的Binlog。如果要對錶結構進行更新，應該由運維工程師DBA對所有主從資料庫分別手工進行資料表結構的更新操作。

 

二、資料分片

資料複製只能提高資料讀併發操作能力，並不能提高資料寫操作併發的能力以及資料整個的儲存容量，也就是並不能提高資料庫總儲存記錄數。如果我們資料庫的寫操作也有大量的併發請求需要滿足，或者是我們的資料表特別大，單一的伺服器甚至連一張表都無法儲存。解決方案就是資料分片。

 

1.資料分片介紹     

a.主要目標：將一張資料表切分成較小的片，不同的片儲存到不同的伺服器上面去，通過分片的方式使用多臺伺服器儲存一張資料表，避免一臺伺服器記錄儲存處理整張資料錶帶來的儲存及訪問壓力。

b.主要特點：資料庫伺服器之間互相獨立，不共享任何資訊，即使有部分伺服器故障，也不影響整個系統的可用性。第二個特點是通過分片鍵定位分片，也就是說一個分片儲存到哪個伺服器上面去，到哪個服伺服器上面去查詢，是通過分片鍵進行路由分割槽演算法計算出來的。在SQL語句裡面，只要包含分片鍵，就可以訪問特定的伺服器，而不需要連線所有的伺服器，跟其他的伺服器進行通訊。

c.主要原理：將資料以某種方式進行切分，通常就是用剛才提到的分片鍵的路由演算法。通過分片鍵，根據某種路由演算法進行計算，使每臺伺服器都只儲存一部分資料。

 

2.硬編碼實現資料分片

如圖例子，通過應用程式硬編碼的方式實現資料分片。假設我們的資料庫將資料表根據使用者ID進行分片，分片的邏輯是使用者ID為奇數的資料儲存在伺服器2中，使用者ID為偶數的資料儲存在伺服器1中。那麼，應用程式在編碼的時候，就可以直接通過使用者ID進行雜湊計算，通常是餘數計算。如果餘數為奇數就連線到伺服器2上，如果餘數為偶數，就連線到伺服器1上，這樣就實現了一張使用者表分片在兩個伺服器上。

這種硬編碼主要的缺點在於，資料庫的分片邏輯是應用程式自身實現的，應用程式需要耦合資料庫分片邏輯，不利於應用程式的維護和擴充套件。一個簡單的解決辦法就是將對映關係儲存在外面。

 

3.對映表外部儲存       

應用程式在連線資料庫進行SQL操作的時候，通過查詢外部的資料儲存查詢自己應該連線到哪臺伺服器上面去，然後根據返回的伺服器的編號，連線對應的伺服器執行相應的操作。在這個例子中，使用者ID=33查詢伺服器是2，使用者ID=94查詢伺服器也是2，它們根據查詢到的使用者伺服器的編號，連線對應的伺服器，將資料寫入到對應的伺服器分片中。

 

4.資料分片的挑戰及解決方案  

資料庫分片面臨如圖的挑戰：    

現在有一些專門的分散式資料庫中介軟體來解決上述這些問題，比較知名的有Mycat。Mycat是一個專門的分散式資料庫中介軟體，應用程式像連線資料庫一樣的連線Mycat，而資料分片的操作完全交給了Mycat去完成。

如下這個例子中，有3個分片資料庫伺服器，資料庫伺服器dn1、dn2和dn3，它們的分片規則是根據prov欄位進行分片。那麼，當我們執行一個查詢操作”select * from orders where prov='wuhan'“的時候，Mycat會根據分片規則將這條SQL操作路由到dn1這個伺服器節點上。dn1執行資料查詢操作返回結果後，Mycat再返回給應用程式。通過使用Mycat這樣的分散式資料庫中介軟體，應用程式可以透明的無感知的使用分片資料庫。同時，Mycat還一定程度上支援分片資料庫的聯合join查詢以及資料庫事務。

               

5.分片資料庫擴容伸縮

一開始，資料量還不是太多，兩個資料庫伺服器就夠了。但是隨著資料的不斷增長，可能需要增加第三個第四個第五個甚至更多的伺服器。在增加伺服器的過程中，分片規則需要改變。分片規則改變後，以前寫入到原來的資料庫中的資料，根據新的分片規則，可能要訪問新的伺服器，所以還需要進行資料遷移。

不管是更改分片的路由演算法規則，還是進行資料遷移，都是一些比較麻煩和複雜的事情。因此在實踐中通常的做法是資料分片使用邏輯資料庫，也就是說一開始雖然只需要兩個伺服器就可以完成資料分片儲存，但是依然在邏輯上把它切分成多個邏輯資料庫。具體的操作辦法，本文不用大篇幅進行闡述了。

 

三、資料庫部署方案

 

1.單一服務和單一資料庫      

這是最簡單的部署方案。應用伺服器可能有多個，但是它們完成的功能是單一的功能。多個完成單一功能的伺服器，通過負載均衡對外提供服務。它們只連一臺單一資料庫伺服器，這是應用系統早期使用者量比較低的時候的一種架構方法。

 

2.主從複製實現伸縮              

如果對系統的可用性和對資料庫的訪問效能提出更高要求的時候，就可以通過資料庫的主從複製進行初步的伸縮。通過主從複製，實現一主多從。應用伺服器的寫操作連線主資料庫，讀操作從從伺服器上進行讀取。

 

3.兩個Web服務及兩個資料庫            

隨著業務更加複雜，為了提供更高的資料庫處理能力，可以進行資料的業務分庫。資料的業務分庫是一種邏輯上的，是基於功能的一種分割，將不同用途的資料表儲存在不同的物理資料庫上面去。

在這個例子中，有產品類目服務和使用者服務，兩個應用伺服器叢集，對應的也將資料庫也拆分成兩個，一個叫做類目資料庫，一個叫做使用者資料庫。每個資料庫依然使用主從複製。通過業務分庫的方式，在同一個系統中，提供了更多的資料庫儲存，同時也就提供了更強大的資料訪問能力，同時也使系統變得更加簡單，系統的耦合變得更低。

 

4.綜合部署方案              

根據不同資料的訪問特點，使用不同的解決方案進行應對。比如說類目資料庫，也許通過主從複製就能夠滿足所有的訪問要求。但是如果使用者量特別大，進行主從複製或主主複製，還是不能夠滿足資料儲存以及寫操作的訪問壓力，這時候就就可以對使用者資料庫進行資料分片儲存了。同時每個分片資料庫也使用主從複製的方式進行部署。

以上為分散式資料庫的部署方案，如果你的應用不是非要使用關聯式資料庫的話，你還可以選擇NoSQL資料庫，NoSQL資料庫會提供更強大的資料儲存能力和併發讀寫能力。但是NoSQL資料庫因為CAP原理的約束可能會遇到資料不一致的問題。解決資料不一致的問題，可以通過時間戳合併、客戶端判斷以及投票這樣的幾種機制解決，實現最終一致性。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31545816/viewspace-2649037/，如需轉載，請註明出處，否則將追究法律責任。