MySQL架構必須結合前端業務進行設計和優化，所以無論采用哪種架構，最好都要結合業務需求來滿足，不能一概而論，同時要注意數據安全（如ipsec、ssh、vpn傳輸）。

(二）常見的MySQL架構

MySQL的常見架構是業務分割、前端緩存、分庫分表。如果查詢量超過1億，就會從業務、bbs、web、blog中拆成幾組，然后做成主多從少、讀寫分離。

而且，在表的設計上，一般情況下，備份庫往往充當備份查詢，至于讀寫分離，在程序設計之初，讀寫是通過不同的IP入口，這是一個思路，或者定義類，或者用代理層，比如MySQL-proxy最多的場合，一般在應用層做讀寫分離，然后MySQL通過復制來實現，優點多，可控性非常好。

(三）常見的游戲架構

游戲中的好友關系、排行榜、計數器、隊列、緩存等都很適合通過Redis來實現，不用在Redis的事務能力上花太多的心思。此外，Redis比Memcached要穩定得多。

(四) 電子商務的常見架構

在電子商務方面：生產環境也是主從架構，然后用DRBD+HA做主備，主備不推薦，高可用還是推薦DRBD方案，DRBD注意不要設置為自動啟動，手動重啟，腦裂的情況很少。但在工作中，基本不重啟DRBD，更不重啟服務器，基本沒有遇到腦裂的問題，DRBD這種在災備方面有風險，但不能起到擴容的作用，結合LVS相信是一個完美的解決方案，比如說。LVS+Keepalived可以通過腳本消除來自MySQL機器的緩慢延遲或故障，而且LVS是軟件負載均衡器中最強的，在后端節點超過10個的情況下，估計只有LVS可以勝任了

(五）公司的規模（如新浪、淘寶）

1、不用集群是說mysql自己的集群用的不多（目前看還可以用）。

2、主站和從站可以是多個組，若干個

3、每個組可以是一個主站和多個從站（1/N的業務數據）。

4、3每個組在讀或寫時可能是一個前端調度器RS

5. 調度器的分布可以是哈希分組，數據可以根據用戶ID進行切分，當然還有更高級的手段

提示：新浪開發經理承認，他們的SAE平臺還是主從式的，甚至還有單點式的（通過監控和人工處理））。

(六）中型公司（如CSDN）

1、mysql一個主程序和多個從程序讀寫分離（甚至還沒有實現），多組。出現問題后直接手動或自動切入更改主站（用腳本或程序來實現）

2、drbd+ha實現高可用（也是雙主多從，自動切換M，正常備份M無法提供服務）。

3、或雙主多從，前端結合，分別實現讀寫負載均衡