MySQL架構由小變大的演進過程的詳情

假設一個網站（discuz）從最開始訪問量很小做到日pv千萬，我們來推測一下它的mysql伺服器架構演變過程。

第一階段
網站訪問量日pv量級在1w以下。 單一機器跑web和db，不需要做架構層調優（例如，不需要增加memcached快取）。此時，資料往往都是每日冷備份的，但有時候如果考慮資料安全性，會建立一個mysql主從。

第二階段
網站訪問量日pv達到數萬。此時單一機器已經有點負載，需要我們把web和db分開，需要搭建memcached服務作為快取。也就是說，在這個階段，我們也可以使用單一機器來跑mysql去承擔整個網站的資料儲存和查詢。如果做 MySQL 主從，目的也是為了資料安全性。

第三階段
網站訪問量日pv達到幾十萬。單台機器雖然也可以支撐，但是需要的機器配置比之前的機器好很多。如果經費允許，可以購買配置很高的機器來跑mysql服務，但是並不是說，配置翻倍，性能也翻倍，到了一定階段配置增加已經不能帶來性能的增加。所以，此階段，我們會想到做mysql服務的集群，也就是說我們可以拿多台機器來跑MySQL。但，MySQL的叢集和web叢集是不一樣的，我們需要考慮資料的一致性，所以不能簡單套用做web叢集的方式（lvs，nginx代理程式）。可以做的架構是，mysql主從，一主多從。為了確保架構的健壯和資料完整，主只能是一個，從可以是多個。

還有一個問題，我們需要想到，就是在前端web層，我們的程式裡面指定了MySQL機器的ip，那麼當mysql機器有多台時，程式裡面如何去配置？ discuz，其實有一個功能，支援MySQL讀寫分離。即，我們可以拿多台機器跑MySQL，其中一台寫，其他多台是讀，我們只需要把讀和寫的 IP 分別配置到程式中，程式自動會去區分機器。當然，如果不使用 discuz 自帶的配置，我們也可以引用一個軟體叫做 mysql-proxy, 使用他來實現讀寫分離。它支援一主多從的模式。

第四階段
網站訪問量日pv到數百萬。之前的一主多從模式已經遇到瓶頸，因為當網站訪問量變大，讀取資料庫的量也會越來越大，我們需要多加一些從進來，但是從的數量增加到數十台時，由於主需要把bin-log全部分發到所有從上，那麼這個過程本身就是一件很繁瑣的事情，再加上頻繁讀取，勢必會造成從上同步過來的資料有很大延遲。所以，我們可以做一個優化，把mysql原來的一主多從變成一主一從，然後從作為其他從的主，而前面的主只負責網站業務的寫入，而後面的從不負責網站任何業務，只負責給其他從同步bin-log。 這樣還可以繼續多疊加幾個從函式庫。

第五階段
網站訪問量日pv到1千萬的時候，我們發現，網站的寫入量非常大，我們之前架構只有一個主，這裡的主已經變成瓶頸了。所以，需要再近一步來做出調整。例如，我們可以把業務分模組，把用戶相關的單獨分離出來，把權限、積分等也可以分離出來單獨跑一個庫，然後再做主從，也就是所謂的分庫。當然也可以換一個緯度，把訪問量或寫入量大的表單獨分離出來，跑在一台伺服器上，也可以把一個表分成多個小表。這一步操作，牽涉到一些程式上的改動，所以需要事先和發展同事做好溝通設計。總之，這一步要做的就是分庫分錶。

寫在後面
再往後發展，繼續把大表分小表即可。 而國內阿里淘寶網站的資料量是巨量的，他們的資料庫全部都是MySQL，他們的MySQL 架構就是遵循分庫分錶這個原則的，只不過他們劃分規則會有很多緯度，比如可以根據地域劃分，可以依買家、賣家劃分，可以依時間劃分等等。

以上就是MySQL架構由小變大的演進過程的詳情的內容，更多相關內容請關注PHP中文網（www.php.cn）！