前言
在生產環境中，我們往往需要冗餘節點，也就是避免線上事故的產生。
PXC集羣推薦教程：https://coding.imooc.com/class/274.html
業務場景
| 場景 | 對應行業 | 解決方案 |
|---|---|---|
| 讀多寫少 | 電商、新聞、論壇 | MYSQL + NOSQL |
| 寫多讀少 | 滴滴、校園成績 | 低價值數據：使用NoSQL存儲 高價值數據：使用TokuDB來存儲 |
| 寫多讀多 | 微信、QQ | 藉助Redis，NoSQL等解決方法 |
MySQL 衍生版對比
綜合對比之下，建議選擇 Percona Server
| 產品 | 版本 | 收費情況 | 是否開源 | 性能 | 兼容性 |
|---|---|---|---|---|---|
| MySQL | 官方原版 | 免費 | 未來可能閉源 | 不好 | 好 |
| MariaDB | 社區版 | 免費 | 繼續開源 | 較好 | 一般 |
| Percona | 企業版 | 免費 | 繼續開源 | 最好 | 好 |
MySQL 存儲引擎
其中 TokuDB 是要自己安裝擴展的，Percona公司官網上有
| 引擎名稱 | 事務 | 說明 |
|---|---|---|
| MyISAM | N | MySQL5.6之前的默認引擎，最常用的非事務存儲引擎 |
| CSV | N | 以CSV格式存儲的非事務型存儲引擎 |
| Archive | N | 只允許查詢和新增數據而不允許修改的非事務性存儲引擎 |
| Memory | N | 是一種易失性非事務存儲引擎（保存在內存中，重啓則無） |
| InnoDB | Y | 最常用的事務型存儲引擎 |
| TokuDB | Y | Percona旗下產品(TokuTek研發)，適合寫多讀少，冷數據業務 |
數據切分中間件
綜合對比之下，我們選擇 MyCat
| 產品 | 收費情況 | 是否開源 | 普及率 | 功能 |
|---|---|---|---|---|
| MyCat | 免費 | 開源 | 高 | 分片算法豐富、讀寫分離、全局主鍵、分佈式事務 |
| Atlas | 免費 | 開源 | 低 | 分片算法較少、讀寫分離 |
| One Proxy | 免費版/企業版 | 閉源 | 低 | 分片算法較少、讀寫分離 |
| Proxy SQL | 免費 | 開源 | 一般 | 分片算法較少、讀寫分離 |
負載均衡中間件對比
綜合考慮之下，使用 Haproxy 因爲nginx剛剛支持沒多久，先看看情況
| 比較 | Haproxy | Nginx | Apache | LVS |
|---|---|---|---|---|
| 是否免費 | 免費 | 免費 | 免費 | 免費 |
| 支持虛擬機 | 支持 | 支持 | 支持 | 否 |
| HTTP協議 | 支持 | 支持 | 支持 | 支持 |
| ICP/IP協議 | 支持 | 剛剛支持 | 不支持 | 支持 |
| 支持插件 | 不支持 | 支持 | 不支持 | 不支持 |
| 性能 | 好 | 好 | 一般 | 最好 |
數據庫負載均衡的必要性
- 雖然搭建了集羣，但是不使用數據庫負載均衡，單節點處理所有請求，負載高，性能差
- 使用Haproxy做負載均衡，請求被均勻分發到每個節點，單節點負載低，性能好
單節點數據庫的弊病
- 大型互聯網程序用戶羣體龐大，所以架構必須要特殊設計
- 單節點的數據庫無法滿足性能上的要求
- 單節點的數據庫沒有冗餘設計，無法滿足高可用
常見集羣架構
數據集羣方案
| 方案 | 強一致性 | 寫入速度 | 寫入方式 | 適合場景 |
|---|---|---|---|---|
| PXC | 是 | 慢 | 任意節點 | 高價值數據 |
| Replication | 否 | 快 | 主寫，從讀 | 低價值數據 |
集羣方法的優點
- 數據庫集羣能支持更大規模的併發訪問，並且存放更多的數據
- 降低單表數量，不讓他超過2000萬，使用MyCat做數據切分
PXC的數據強一致性
- 同步複製，事務在所有集羣節點上要麼同時提交，要麼不提交
- Replication採用異步複製，無法保證數據的一致性
PXC和Replication方案優劣
- Replication寫入數據快，但是不能保證數據的一致性
- PXC可以保證數據的一致性，但是寫入速度慢
- PXC方案實雙向的，任意一個MySQL節點上都可以讀寫數據
- Replication方案，單向的，不是每一個節點都可以讀寫
兩者優勢各不同，生成環境我們可以採用組合方案
- PXC方案存儲高價值數據，如：賬號、訂單、交易等等
- Replication方案存儲低價值數據，如：權限、通知、日誌等等
- 用MyCat 或者 JDBC-Sharding切分數據管理集羣
存在風險注意問題：
- PXC集羣最好使用 奇數方案，不要使用偶數 (避免腦裂)
PXC方案寫入圖解
- 可以看到，在提交時通過事務，確保所有節點都寫入成功後，返回成功
- 這也就是爲什麼PXC集羣，每個主機配置要一致的問題，因爲都要等節點寫入成功
![PXC方案圖解]()
Replication方法寫入圖解
- 可以看到，在提交時，主成功了也就直接返回了
- 這時如果從服務在同步時出問題，就會導致數據不一致 (從查找不到訂單這類問題)
![Replication圖解]()
最終架構
https://www.processon.com/view/link/5dac1642e4b0335f1d3c0086
知名公司記錄
- 2016年春節，微信紅包支付峯值153.8萬次/秒，創下世界紀錄
- 2017天貓雙11，數據庫峯值4200萬次/秒，支付峯值25.6萬次/秒
