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架構就是遵循分庫分表這個原則的，只不過他們劃分規則會有不少緯度，好比能夠根據地域劃分，能夠根據買家、賣家劃分，能夠根據時間劃分等等。