目錄
緩存（Memcached/Redis...）+MySQL+垂直拆分
單機MySQL的美好年代
在那個時候，更多的是靜態網頁，動態交互類型的網站不多。
上述架構下，我們來看看數據存儲的瓶頸是什麼？
- 數據量的總大小，一個機器放不下時；
- 數據的索引（B+Tree）一個及其內存放不下時；
- 訪問量（讀寫混合）一個實例不能承受。
如果滿足上述任意條件，我們該怎麼辦？
緩存（Memcached/Redis...）+MySQL+垂直拆分
互聯網發展至今，隨着訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都出現了性能問題，然而我們的程序不再僅僅專注在功能上，同時也需要追求性能。猿猴們開始大量使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。最開始比較流行的是通過文件緩存來緩解數據庫壓力，但是每當訪問量增大的時候，多臺web服務器通過文件緩存的方式不能共享，大量的小文件緩存也帶來了比較高的IO壓力。此時，Memcached/Redis...自然成爲一個非常時尚的技術產品。
MySQL主從讀寫分離
由於數據庫的寫入壓力增加，Memcached/Redis...只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從複製的技術來達到讀寫分離，從而提高讀寫性能和數據庫的可擴展性。MySQL的master-slave模式成爲這個時候的網站標配了。
分庫分表+水平拆分+MySQL集羣
在Memcached的高速緩存、MySQL的主從複製、讀寫分離的基礎上，這時MySQL主庫的寫入壓力開始出現瓶頸，而數據量的持續猛增，由於MyISAM使用表鎖，在高併發下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。
與此同時，開始流行使用分庫分表來緩解寫壓力和數據增長的擴展問題。這個時候，分庫分表成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集羣，但新跟那個也不能很好滿足互聯網的要求，只是在高可用上提供了非常大的保證。
MySQL的擴展性瓶頸
MySQL數據庫亞特進場存儲一些大文本字段，導致數據庫表非常的大，在做數據庫恢復的時候就導致非常的慢，不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL中省去，MySQL將變得非常的小。關係數據庫很強大，但是它並不能很好的應付所有的應用場景。MySQL的擴展性差（需要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正式當前使用MySQL的開發人員面臨的問題。
現在的樣子
經過時間的洗磨，我們對於整個項目的架構變得越來越通用化、可用性越來越高，各種服務都有相應的技術以及服務器去支撐，慢慢的解決了單個服務承載多個功能的問題。比如說，原本MySQL存儲的信息包括：基本數據、圖片二進制流、自媒體文件、長文本...，然而現在都有相應的服務去做專門的存儲，比如單獨搭建FastDFS去存儲文件資源，使得MySQL不在去存儲各種文件的二進制數據，只需要存儲該文件在FastDFS節點的位置即可。
