前言
隨着互聯網行業的高速發展，一些商業的存儲解決方案的成本越來越高;大部分企業開始尋求開源的存儲解決方案，成爲互聯網商業存儲的首選。下面以mysql爲例，介紹下數據庫的擴展方案。
根據業務域垂直拆分
首先是根據業務域進行拆分。以前可能所有的業務表是耦合在一個數據庫中，這種模式下，系統的複雜性越來越大，開發維護成本越來越大，開發效率越來越低，系統的資源成本也會越來越大。
優點：所以需要從業務域的粒度層面進行拆分，每一塊業務域都有自己的單獨數據庫，不同的業務訪問不同的庫，這樣庫的壓力自然而然下降了。
缺點：由於拆分成不同的業務域，多表的CURD會有分佈式事務以及跨庫join等問題。
當然解決方式有很多，跨庫join可以考慮全局表，可以生成以查詢唯獨的異步。
分佈式事務可以考慮通過補償達到最終一致性，這也是目前微服務架構中最常用的一種解決方案。
主從複製，讀寫分離
隨着業務量的不斷髮展，單張業務表可能會遇到瓶頸；很多表可能會存在讀多寫少的問題，這時候我們可能考慮需要通過主從複製，讀寫分離來解決，將讀與寫分成幾個庫。開啓master的Binary log；數據複製是slave通過master獲取binary log，在本地鏡像的執行日誌中記錄的操作。
大概有以下2種複製架構
1.單master，多slave的架構
缺點：單master會存在單點故障的問題，不利於升級維護；Master停機可能會導致整體應用都無法訪問。
2.雙master，多slave的架構
兩臺mysql服務器互相將對方作爲自己的master，自己作爲對方的slave;通過主從複製機制同步到對方的服務器數據。一般情況下,只會讓其中一臺master提供寫入服務，另外一臺作爲讀庫。
分庫分表
分表：
數量量達到千萬級以後，主從架構可能還是不太合適，只能對讀數據庫進行擴展，無法對寫進行擴展，寫基本上還是集中在master中。 所以我們還是需要減少單表的記錄條數，進而減少數據查詢的時間，提高吞吐量，也就是我們說的分表。可以通過對一個關鍵字對分庫數量取模的方式，
分庫：
分表能解決單表數據量太大的問題， 但是無法解決數據庫的併發處理能力，我們可以通過對一個關鍵字對分庫數量取模的方式，對數據訪問進行數據庫的路由。
分庫分表：
既可以解決單表海量數據的問題， 又可以提高數據庫的併發處理能力。
