由于高并發(fā)和分布式的興起厘熟，使得MySQL數(shù)據(jù)庫單節(jié)點(diǎn)已經(jīng)不能滿足生產(chǎn)日常的要求了颁湖。所以就有了MySQL集群的搭建俗他。
針對于常用的MySQL集群屎媳，主要有PXC和RP兩種模式夺溢。本篇主要以理論為主。
PXC
全寫Percona XtraDB Cluster烛谊。通過MySQL自帶的一種集群技術(shù)——Galera將不同的MySQL連接起來风响，形成多主集群。
PXC模式.png
其事務(wù)的執(zhí)行時(shí)序圖為：
PXC事務(wù)時(shí)序圖.png
以上是以3節(jié)點(diǎn)為例丹禀，具體步驟：
- 客戶端寫入到數(shù)據(jù)庫DB1状勤，返回結(jié)果，但此時(shí)并未持久化双泪；
- 客戶端提交事務(wù)到DB1持搜；
- DB1將數(shù)據(jù)復(fù)制給PXC，然后由PXC分別復(fù)制給DB2焙矛，DB3葫盼；
- 由PXC生成GTID，在DB2薄扁，DB3分別執(zhí)行GTID并返回執(zhí)行結(jié)果剪返；
- 4返回?zé)o問題，在DB1中執(zhí)行GTID邓梅，返回最終事務(wù)結(jié)果。4有問題直接返回事務(wù)失敗結(jié)果邑滨。
ps：
- 在PXC中日缨，生成的ID有可能是不連續(xù)的，如果期望連續(xù)就需要將ID生成策略提高一級掖看，比如放在數(shù)據(jù)切分中間件中匣距，如mycat等“タ牵或者在程序中執(zhí)行ID的賦予問題毅待。
在賦予ID時(shí)需要考慮到后期可能遷徙數(shù)據(jù)庫的問題。 - PXC集群數(shù)量建議為奇數(shù)归榕，防止腦裂尸红。
RP
RP即Replication，主從復(fù)制。即只能從主到從進(jìn)行同步外里。采用主寫副讀怎爵，只有主節(jié)點(diǎn)有事務(wù)。（從節(jié)點(diǎn)即副節(jié)點(diǎn)）
RP模式.png
ps：RP方式盅蝗，如果主節(jié)點(diǎn)沒有同步到從節(jié)點(diǎn)鳖链，會(huì)出現(xiàn)數(shù)據(jù)不一致性。
PXC和RP比較
| PXC | RP | |
|---|---|---|
| 同步方式 | 同步 | 異步 |
| 主節(jié)點(diǎn)數(shù)量 | 全部都是 | 只有1個(gè) |
| 同步方向 | 互相同步 | 只能主到從 |
| 讀寫關(guān)系 | 全部讀寫 | 主寫副讀 |
| 是否有事務(wù) | 所有節(jié)點(diǎn)都有 | 主節(jié)點(diǎn)有 |
| 強(qiáng)一致性 | 是 | 否 |
| 執(zhí)行效率 | 低 | 高 |
| 適用場景 | 訂單墩莫、紅包等貴重功能 | 通知芙委、日志等次要功能 |
HAproxy高可用方案
HAproxy是可以支持TCP/IP協(xié)議的負(fù)載均衡方案。程序接入到HA數(shù)據(jù)源狂秦，由HAproxy來分發(fā)任務(wù)灌侣。
