高性能、高可用、可擴展的MySQL集群如何組建？
組建MySQL集群的幾種方案
LVS+Keepalived+MySQL（有腦裂問題？但似乎很多人推薦這個）DRBD+Heartbeat+MySQL（有一台機器空餘？Heartbeat切換時間較長？有腦裂問題？）MySQL Proxy（不夠成熟與穩定？使用了Lua？是不是用了他做分表則可以不用更改客戶端邏輯？）MySQL Cluster （社區版不支持INNODB引擎？商用案例不足？）MySQL + MHA （如果配上非同步複製，似乎是不錯的選擇，又和問題？）
MySQL + MMM （似乎反映有很多問題，未實踐過，誰能給個說法）哪個（相對）好，或者還有其他方案？各有啥優劣，哪種真正大量的被商用，讀寫分離時如何保證讀到剛寫入的東東？謝謝。
組建MySQL集群的幾種方案
LVS+Keepalived+MySQL（有腦裂問題？但似乎很多人推薦這個）DRBD+Heartbeat+MySQL（有一台機器空餘？Heartbeat切換時間較長？有腦裂問題？）MySQL Proxy（不夠成熟與穩定？使用了Lua？是不是用了他做分表則可以不用更改客戶端邏輯？）MySQL Cluster （社區版不支持INNODB引擎？商用案例不足？）MySQL + MHA （如果配上非同步複製，似乎是不錯的選擇，又和問題？）
MySQL + MMM （似乎反映有很多問題，未實踐過，誰能給個說法）回答：
不管哪種方案都是有其場景限制 或說 規模限制，以及優缺點的。
1. 首先反對大家做讀寫分離，關於這方面的原因解釋太多次數（增加技術複雜度、可能導致讀到落後的數據等），只說一點：99.8%的業務場景沒有必要做讀寫分離，只要做好資料庫設計優化 和配置合適正確的主機即可。
2.Keepalived+MySQL --確實有腦裂的問題，還無法做到準確判斷mysqld是否HANG的情況；
3.DRBD+Heartbeat+MySQL --同樣有腦裂的問題，還無法做到準確判斷mysqld是否HANG的情況，且DRDB是不需要的，增加反而會出問題；
3.MySQL Proxy -- 不錯的項目，可惜官方半途夭折了，不建議用，無法高可用，是一個寫分離；
4.MySQL Cluster -- 社區版本不支持NDB是錯誤的言論，商用案例確實不多，主要是跟其業務場景要求有關係、這幾年發展有點亂不過現在已經上正規了、對網路要求高；
5.MySQL + MHA -- 可以解決腦裂的問題，需要的IP多，小集群是可以的，但是管理大的就麻煩，其次MySQL + MMM 的話且坑很多，有MHA就沒必要採用MMM
建議：
1.若是雙主複製的模式，不用做數據拆分，那麼就可以選擇MHA或 Keepalive 或 heartbeat2.若是雙主複製，還做了數據的拆分，則可以考慮採用Cobar；3.若是雙主複製+Slave，還做了數據的拆分，需要讀寫分類，可以考慮Amoeba；上述所有的內容都要依據公司內部的業務場景、數據量、訪問量、並發量、高可用的要求、DBA人群的數量等 綜合權衡，若是需要可以聯繫我：jinguanding#http://hotpu.cn美團點評資料庫高可用架構的演進與設想 -
本文介紹了美團點評MySQL資料庫高可用架構從MMM到MHA+Zebra以及MHA+Proxy的演進歷程，同時也介紹了業界一些高可用的做法
PS: 基於 paxos/raft的資料庫可參考 phxsql（tencent-wechat/phxsql）和TIDB（pingcap/tidb )
謝邀。-------------------------------------------------------------------恕本人才疏學淺，暫時不能回答此問題。DB菜鳥一枚，對MySQL沒有多大深入的了解。針對這個問題，在OSC（開源中國）、StackOverFlow、CSDN論壇上問或許更合適些。
題主對mysq的高可用及集群方式了解比較充分。應該說按照實際商用的場景來設計資料庫集群架構，這樣才是合理的。如果你追求完美的高可用，避免任何的單點故障，可以在主從、主主同步的基礎上配合keepalived或是heartbeat，這兩者做故障切換都很好用。高性能上，與其指望一套資料庫後端服務搞定所有業務，不如考慮不同業務的在不同伺服器資源上的sharding，但其管理複雜度必定會增加，看你怎麼權衡管理性和性能方面。關於可擴展性，mysql代理（如阿里的amoeba）+mysql一主多從可以考慮。總之沒有最好的方案，只有最合適的！
先介紹幾種方案
- 主從複製，包括一拖一的主從和一拖多的主從
高可用性 ：比較高
高可擴展性 ：無
高一致性 ：比較高
延遲性 ：比較小
並發性 ：無
事務性 ：無
吞吐率 ：比較高
數據丟失 ：不丟失
可切換 ：可以切換
- 環形複製,包括兩個節點和多個節點形成的環形
高可用性 ：比較高
高可擴展性 ：無
高一致性 ：比較高
延遲性 ：比較小
並發性 ：無
事務性 ：無
吞吐率 ：比較高
數據丟失 ：不丟失
可切換 ：可以切換
- 2PC：
高可用性 ： 很高
高可擴展性 ： 可擴展，不能大規模擴展，也無需大規模擴展
高一致性 ： 比較高
延遲性 ： 比較大
並發性 ： 比較小
事務性 ： 有
吞吐率 ： 比較小
數據丟失 ： 不丟失
可切換 ： 無關
- Paxos：元數據的高可用，並發度不高
高可用性 ： 很高
高可擴展性 ： 無關 可擴展，不能大規模擴展，也無需大規模擴展
高一致性 ： 很高
延遲性 ： 比較大
並發性 ： 比較小
事務性 ： 有
吞吐率 ： 比較小
數據丟失 ： 不丟失
可切換 ： 無關
以上純屬個人理解，如有異議，也是沒問題的；
另外按照master是否服務具體業務來分分散式可以分為兩類：
- master管理系統，並且所有請求通過master，很明顯master存在性能瓶頸
- master管理系統，實際請求不通過master，請求分散均勻了
基於這些方案的特點，如何設計一個牛逼滴分散式系統 ？
這裡的牛逼包括
- 可大規模擴展：要求像hadoop那樣，至少幾百條台沒問題
- 高可用：master需要高可用，節點也需要高可用，也就是說任何一個組件的一個實例或者部分實例掛了，都不會影響整個系統
- 高並發：普通機器單節點至少要支持幾千的並發度吧，如果擴展解決了，整個系統的並發其實也擴展的
- 數據一致性:分散式系統，一致性可難了，盡量保證吧，比如主從同步實現一致 ，或者使用兩階段2pc同時寫多個節點，或者使用像paxos一致性協議演算法實現哈
- 事務性：分散式系統，絕對的事務很難吧，哎，我們就用2pc，3pc吧，盡量保證哈
- 自動切換 ： 首先你得想自動切換的條件如何呢？ 比如主從同步，主掛了，我可以自動切換到從，可是如果從數據和主不同步，但是業務要求很高，不允許這種情況出現，那也只好停服維護啦。
好了 你可以開始噴了 ， 怎麼可能。
paxos一致性協議，可用性很高，一致性很高，事務性很不錯 ， 那麼涉及到各種服務都可以用他，非常好。
master和metadata元數據採用paxos一致性協議，所有節點也採用paxos一致性協議 ， 客戶端保持這些信息。架構如下所示 ，master, metadata, node 都實現了paxos協議，也即通過paxos介面訪問
分散式資料庫就是一個例子，貌似目前流行的資料庫都還沒有支持paxos協議的，有誰可以開發下。節點採用paxos的話，有個問題沒想清楚，paxos如何sql結合使用？另外節點的性能會受一點影響。降低一點要求吧，節點採用主主複製，或者環形複製吧。master檢查節點存活，並且做切換，通知客戶端。
架構如下所示 ，master, metadata,實現了paxos協議，也即通過paxos介面訪問;node的各個節點是複製關係，服務節點掛掉的時候，需要master檢測，並且做切換處理。
如果是分散式系統，比如文件系統，或者自己開發的系統， 那節點可以考慮用paxos協議哦。 每個節點採用3個實例，或者你有資源，採用5個實例。
分散式資料庫的sql實現
也是一個難點，即一個複雜的sql，如何實現？
?使用分庫分表的思想實現數據存儲?使用mapred的思想實現sql計算
?將輸入sql經過詞法，語法，語義分析，集合表結構信息和數據分布信息，生成包含多個階段(簡稱stage)的執行計劃，這些階段具有一定的依賴關係，形成多輸入單輸出的任務樹；
?每個階段包括兩種sql，稱為mapsql和redsql，另外每個階段包括三個操作，map，數據洗牌和red；map和red分別執行mapsql和redsql；
子句的處理邏輯和處理順序
：
2.from：選擇表，可以是選擇多張表，也可是join的情況
3.join：from中如果包含join，就要考慮join的各種問題
4.where：單表，多表，join之後的where過濾條件
5.group：分組
6.select：選擇的列
7.distinct：去掉重複的行
8.having：聚合之後的過濾
9.order：將結果排序
10.limit
offset：獲取最終結果的某些記錄
11.子查詢：遇到子查詢獨立解析，跟上層建立依賴關係
連接，包括內連接，左連接，右連接，半連接，外連接
以如下sql為例：
某一註冊時間範圍內的用戶的所有登錄信息
select
t1.u_id,t1.u_name,t2.login_product
from tab_user_info t1 join
tab_login_info t2
on (t1.u_id=t2.u_id and
t1.u_reg_dt&>=? and t1.u_reg_dt&<=?)
生成的執行計劃為：
由於是join，所有的表都要進行查詢操作，並且為每張表打上自己的標籤，具體實施的時候可以加個表名字欄位，在所有存儲節點上執行
select u_id,u_name from tab_user_info t where
u_reg_dt&>=? and t1.u_reg_dt&<=?
select u_id, login_product from tab_login_info t
執行完成之後，這種情況下由於需要按照u_id進行數據洗牌，考慮到u_id的唯一值比較多，所以各個存儲節點上需要按照u_id進行劃分，
例如有N個計算節點，那麼按照（最大u_id-最小u_id）/N平均劃分，將不同存儲節點上的同一範圍的u_id，劃分到同一個計算節點上
然後在計算節點上執行如下操作
select
t1.u_id,t1.u_name,t2.login_product
from tab_user_info t1 join
tab_login_info t2
on (t1.u_id=t2.u_id)
關於分散式sql如何實現的問題，有很多未盡事宜。有興趣的可以相互討論。歡迎切磋
有一篇寫得很有趣的文章，很好地分析了現有的各種方案
「Forget about trying to keep a cluster alive during failure with only two data centers. You are better off making one a DR site. Forget about custom weighting to try to get by on two data centers. The 51% rule will get you anyway! 」Choosing MySQL High Availability Solutions
https://www.percona.com/blog/2016/06/07/choosing-mysql-high-availability-solutions/?from=timelineisappinstalled=0幾點補充：
1.對於需要嚴格保證強一致的場合來說，至少在 MySQL 5.7 之前，DRBD 還是有意義的。5.7 據說能實現真同步複製，若真能實現，就不再需要 DRBD 了。
2.網路分區時的腦裂問題必須避免，應使用基於多數派的選舉演算法來推選 Master。方案很多，比如用 ZooKeeper、etcd、Consul 等進行服務選舉，推選出 Master。
3.MHA 沒深入了解過，但印象里其 Master（Arbiter）節點貌似有單點問題？沒記錯的話此節點用於完成 MySQL 的主節點選舉工作，它自己不 HA 還是有隱患。新版本的mysql 5.7 innodb cluster解決方案推薦使用
InnoDB Cluster 由下面3個核心組件構成：
- 支持 Group Replication 的 MySQL 5.7+ 伺服器
Group Replication 可以把數據同步到集群內的所有成員中，並支持 容錯、自動故障轉移、靈活擴展 等重要特性
- MySQL Shell 1.0+
通過內置的 AdminAPI 來創建和管理整個 InnoDB Clusters
- MySQL Router 2.1+
緩存 InnoDB cluster 的元數據，負責把 client 的 read/write 請求路由到當前的主資料庫節點，還可以對 client 的請求進行負載均衡，並且在主資料庫節點出現故障時，保證 client 的請求被路由到新的主伺服器節點
MySQL大型分散式集群1、主要解決針對大型網站架構中持久化部分中，大量數據存儲以及高並發訪問所帶來是數據讀寫問題。分散式是將一個業務拆分為多個子業務，部署在不同的伺服器上。集群是同一個業務，部署在多個伺服器上。
2、著重對數據切分做了細緻豐富的講解，從數據切分的原理出發，一步一步深入理解數據的切分，通過深入理解各種切分策略來設計和優化我們的系統。這部分中我們還用到了資料庫中間件和客戶端組件來進行數據的切分，讓廣大網友能夠對數據的切分從理論到實戰都會有一個質的飛躍。
沒有人提到AtlasAtlas是由 Qihoo 360, Web平台部基礎架構團隊開發維護的一個基於MySQL協議的數據中間層項目。它是在mysql-proxy 0.8.2版本的基礎上，對其進行了優化，增加了一些新的功能特性。360內部使用Atlas運行的mysql業務，每天承載的讀寫請求數達幾十億條。
推薦閱讀：