本文純屬個人見解，是對前面學習的總結，如有描述不正確的地方還請高手指正~

? ?

???? 一般

????、或者必須是這樣、MySQL 架構必定要結合業務來分析、設計、優化
? ?所以不論是那種架構、根據業務要求組合成符合需求的等于最好的、不能泛泛而談
? ?同時、也必須注意數據的安全（如ipsec,ssh，vpn傳輸）
? ?
? ?

???? 常

????見的架構都是進行業務切分、前端緩存、分庫分表、若是過億的查詢量、
? ?先從業務上拆分、將 bbs、web、blog 分紅幾個組、然后再做成一主多從、讀寫分離的方法
? ?而且、在設計表的時候、一般情況下、備庫常充當起備份查詢的作用
? ?至于、讀寫分離、在程序設計之初、讀和寫是通過不同的IP進口、這是思路一、或者定義類、或者用代理層，比如 MySQL-proxy
? ?
? ?

???? 大多

????數的場合、一般在應用層做讀寫分離、然后 MySQL 通過復制來實現、優點比較多，可控性非常好、
? ?MySQL Replication、這個是王道、最少當初是、未來說不準哈
? ?相比復制而言、Cluster 在出產環境核心環節基本不必、或者當初罕用
? ?因為、前期投入的硬件本錢(絕對于主從)較高、一般的小項目不會使用、Cluster的本錢（大部分是維護本錢）還是比較高的
? ?但隨著后續版本的發布、估計案例會越來越多、畢竟是非常好的 sharding-nothing 的方案
? ?
? ?
? ?

???? 游

????戲中的：摯友關系、排行榜、計數器、隊列、cache 都很合適通過 Redis 來實現

???? ? ?至于 Redis 的事務功能、可以不必放太多的心思去關懷

???? ? ?另外、Redis 絕對 Memcached 而言、也穩定很多

? ?
? ?
? ?

???? 電商

????中、出產環境也都是主從架構、然后用 DRBD + HA 做 Master 備份
? ?主主不推薦、高可用還是推薦 DRBD 方案
? ?DRBD 注意不設置主動啟動、重啟時候手動啟動、腦裂的情況產生非常的少
? ?不過、工作中基本不重啟 DRBD、更不會重啟服務器了、基本上沒遇到腦裂的問題
? ?DRBD 這個在做風險容災的時候有必定作用、但不能起到擴展、結合 LVS相信也是一種 perfect方案
? ?如：LVS+Keepalived 可以通過腳本剔除延遲慢或失效的從MySQL呆板、
? ?而且LVS在軟件負載均衡器中是最強的、在后端節點超過10臺以上的情況、估計只有LVS能勝任
? ?
? ? ??
? ?

???? 規

????模大的公司（如Sina、taobao）
? ?1、不必集群是說mysql自身的集群用的不多（目前看也是可以用的）
? ?2、主從可所以多組，數個
? ?3、每組都可能一主多從（業務數據的1/N）
? ?4、3中每一組里的讀或寫 都多是前端調度器的一個RS
? ?5、調度器分發可以hash分組，可以根據用戶ID切分數據，當然還有更高等的手腕
? ?提示：SINA開發經理承認，他們的SAE平臺還是主從，甚至還有單點（靠監控和手工處置））
? ?
? ?

???? 規模

????中等的公司（如CSDN）
? ?1）mysql一主多從程序讀寫分離（甚至還沒實現），多組。出問題直接手工或主動切從后在change master（腳本或程序實現）
? ?2）drbd+ha實現高可用（也是雙主多從，主動切換M，正常備M不可提供服務）
? ?3）或雙主多從，前端結合讀及寫分別負載均衡

文章結束給大家分享下程序員的一些笑話語錄： 聯想——對內高價，補貼對外傾銷的偉大“民族”企業。

實現分離淺析電商、社區、游戲常用的 MySQL 架構