淺析電商、社區、遊戲常用的 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）或雙主多從，前端結合讀及寫分別負載平衡