雲時代架構之蘑菇街交易平臺數據庫架構演進歷程

蘑菇街交易平臺 數據庫架構演進歷程

　　從數據庫最終用戶角度看，數據庫系統的結構分爲單用戶結構、主從式結構、分佈式結構、客戶/服務器、瀏覽器/應用服務器/數據庫服務器多層結構。這是數據庫外部體系結構。物理存儲結構、邏輯存儲結構、內存結構和實例進程結構。這是內部體系結構。

　　單數據庫架構：一個項目在初期的時候，爲了儘量快地驗證市場，其對業務系統的最大要求是快速實現。在這個階段，代碼開發人員爲了能快速實現業務系統，通常都是將全部層級（MVC）的業務代碼都寫在同一個項目中，全部的業務數據都存放在同一個數據庫中。但隨着項目的不斷推動，用戶量不斷增加，單臺應用服務器已經沒法承受如此巨大的流量了。此時常見的作法是把項目進行分佈式部署，分散單臺服務器的流量，從而能夠暫時緩解用戶增加帶來的應用服務器壓力。

　　主從數據庫架構：這個時候經常使用的解決方案就是將本來單臺數據庫服務器變成主從模式的數據庫服務器，即一臺數據庫做爲主庫支持寫入數據，一臺數據庫做爲讀庫支持查詢數據。

　　咱們經過數據庫主從同步實現了讀寫分離，將全部讀操做都引導到從庫進行，將全部寫操做都引導到主庫進行。由於咱們對數據庫層進行了改造，規定全部讀數據庫操做要訪問從庫，全部寫數據庫操做要訪問主庫，那麼咱們就必須對原來的代碼進行改造。當咱們使用了主從數據庫架構以後，咱們會發現咱們能支撐更多的用戶訪問和請求了。但隨着業務的進一步發展，其實能夠發現會存在一些問題：當咱們修改了註冊模塊的時候，咱們須要整個項目都發布一次，這樣會影響到登陸、購物模塊的正常使用。即便每次改動的代碼即便很小，咱們仍是須要發佈整個項目包，這使得每次發佈的代碼包很是巨大。隨着業務量的不斷增加，咱們會發現即便實現了主從的讀寫分離，數據庫的壓力也是很是大，彷佛快要承受不了了。上面說的這些問題只是實戰中遇到的一部分問題，事實上遇到的問題只會更多不會更少，並且隨着業務的不斷髮展會越發凸顯。

　　垂直切分數據庫架構

　　此時爲了各個業務模塊不互相影響，咱們把應用層進行垂直拆分，即把註冊模塊、登錄模塊、購物模塊都單獨做爲一個應用系統，分別讀寫獨立的數據庫服務器。實現了垂直拆分以後，咱們能夠成功解決上面說到的三個問題：業務模塊相互影響問題、單數據庫壓力問題。可是隨着業務的進一步擴大，咱們又增長了許多業務模塊：客服模塊、錢包模塊、我的中心模塊、收藏夾模塊、訂單模塊等。按照咱們以前所設計的數據庫架構，咱們會存在許多個數據源，這些數據源分散在各個項目中。

　　總結：從單一的數據庫架構，到主從讀寫分離的數據庫架構，再到垂直拆分、水平拆分的數據庫架構。咱們能夠看到 MyCat 幫咱們解決了讀寫數據源判斷、繁雜數據源地址、分表判斷這三個機械的重複性的問題。但 MyCat 發展至今，其功能已經遠遠超過上面說的這三個。例如 MyCat 支持主從切換功能，當數據庫主庫發生網絡問題或其餘故障時，MyCat 能夠自動切換到從庫，從而保證正常讀寫功能的進行。MyCat 的定位是一個數據庫中間件，但凡全部處於應用層和數據層之間的事情，MyCat 均可以作。

文章來源：https://www.cnblogs.com/adeng/p/9012301.html