MySQL架構由小變大的演變過程

2022-01-10 17:00:57 字數 1655 閱讀 1506

假設乙個**(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架構由小變大的演變過程

假設乙個 discuz 從最開始訪問量很小做到日pv千萬,我們來推測一下它的mysql伺服器架構演變過程。第一階段 訪問量日pv量級在1w以下。單台機器跑web和db,不需要做架構層調優 比如,不需要增加memcached快取 此時,資料往往都是每日冷備份的,但有時候如果考慮資料安全性,會搭建乙個m...

MySQL架構由小變大的演變過程

假設乙個 discuz 從最開始訪問量很小做到日pv千萬,我們來推測一下它的mysql伺服器架構演變過程。第一階段 訪問量日pv量級在1w以下。單台機器跑web和db,不需要做架構層調優 比如,不需要增加memcached快取 此時,資料往往都是每日冷備份的,但有時候如果考慮資料安全性,會搭建乙個m...

MySQL架構由小變大的演變過程

假設乙個 discuz 從最開始訪問量很小做到日pv千萬,我們來推測一下它的mysql伺服器架構演變過程。第一階段 訪問量日pv量級在1w以下。單台機器跑web和db,不需要做架構層調優 比如,不需要增加memcached快取 此時,資料往往都是每日冷備份的,但有時候如果考慮資料安全性,會搭建乙個m...