MySQL 的架構(gòu)設(shè)計(jì)

MySQL 架構(gòu)一定要結(jié)合前臺業(yè)務(wù)來設(shè)計(jì)、優(yōu)化，所以不管是哪種架構(gòu)、根據(jù)業(yè)務(wù)要求組合成符合需求的即是最好的、不能泛泛而談同時(shí)、也必須注意數(shù)據(jù)的安全（如ipsec,ssh，vpn傳輸）

MySQL常見的架構(gòu)

MySQL常見的架構(gòu)都是進(jìn)行業(yè)務(wù)切分、前端緩存、分庫分表。若是過億的查詢量則先從業(yè)務(wù)上拆分、將 bbs、web、blog 分成幾個(gè)組、然后再做成一主多從、讀寫分離的方式
而且、在設(shè)計(jì)表的時(shí)候、一般情況下、備庫常充當(dāng)起備份查詢的作用，至于、讀寫分離、在程序設(shè)計(jì)之初、讀和寫是通過不同的IP入口、這是思路一、或者定義類、或者用代理層，比如 MySQL-proxy大多數(shù)的場合、一般在應(yīng)用層做讀寫分離、然后 MySQL 通過復(fù)制來實(shí)現(xiàn)、優(yōu)點(diǎn)比較多，可控性非常好、

游戲常見的架構(gòu)
游戲中的：好友關(guān)系、排行榜、計(jì)數(shù)器、隊(duì)列、cache 都很適合通過 Redis 來實(shí)現(xiàn)，至于 Redis 的事務(wù)功能、可以不必放太多的心思去關(guān)心。另外、Redis 相對 Memcached 而言、也穩(wěn)定很多

電商常見的架構(gòu)

電商中：生產(chǎn)環(huán)境也都是主從架構(gòu)、然后用 DRBD + HA 做 Master 備份，主主不推薦、高可用還是推薦 DRBD 方案，DRBD 注意不設(shè)置自動啟動、重啟時(shí)候手動啟動、腦裂的情況發(fā)生非常的少。不過、工作中基本不重啟 DRBD、更不會重啟服務(wù)器了、基本上沒遇到腦裂的問題，DRBD 這個(gè)在做風(fēng)險(xiǎn)容災(zāi)的時(shí)候有一定作用、但不能起到擴(kuò)展、結(jié)合 LVS相信也是一種 perfect方案，如：LVS+Keepalived 可以通過腳本剔除延遲慢或失效的從MySQL機(jī)器、而且LVS在軟件負(fù)載均衡器中是最強(qiáng)的、在后端節(jié)點(diǎn)超過10臺以上的情況、估計(jì)只有LVS能勝任

規(guī)模大的公司（如Sina、taobao）
1、不用集群是說mysql自身的集群用的不多（目前看也是可以用的）
2、主從可以是多組，數(shù)個(gè)
3、每組都可能一主多從（業(yè)務(wù)數(shù)據(jù)的1/N）
4、3中每一組里的讀或?qū)?都可能是前端調(diào)度器的一個(gè)RS
5、調(diào)度器分發(fā)可以hash分組，可以根據(jù)用戶ID切分?jǐn)?shù)據(jù)，當(dāng)然還有更高級的手段
提示：SINA開發(fā)經(jīng)理承認(rèn)，他們的SAE平臺還是主從，甚至還有單點(diǎn)（靠監(jiān)控和手工處理））

規(guī)模中等的公司（如CSDN）
1）mysql一主多從程序讀寫分離（甚至還沒實(shí)現(xiàn)），多組。出問題直接手工或自動切從后在change master（腳本或程序?qū)崿F(xiàn)）
2）drbd+ha實(shí)現(xiàn)高可用（也是雙主多從，自動切換M，正常備M不可提供服務(wù)）
3）或雙主多從，前端結(jié)合讀及寫分別負(fù)載均衡