淺析電商、社區、游戲常用的 MySQL 架構

【原文】

一般、或者必須是這樣遵從：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 5G游戲

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。