前言
1.為什么要分庫分表
分表原因
- 單表容量不足
- 業(yè)務邏輯需要隔離(如按照地區(qū)進行區(qū)別存儲)
- 隔離熱點數(shù)據(jù)(場景較少)
- 單表查詢效率變差倦始，優(yōu)化索引已無效
分庫原因
- 業(yè)務并發(fā)量大蛋叼，單庫io遇到瓶頸
- 服務set化谎痢，在數(shù)據(jù)存儲層面也進行隔離
2.數(shù)據(jù)庫中間件分類
| 種類 | 優(yōu)點 | 缺點 | 開源組件 |
|---|---|---|---|
| 服務端代理類中間件 | 1. 跨平臺遷移簡單座慰； 2. 監(jiān)控比較好做 |
1. 需要獨立部署額外運維膛虫； 2. 對性能有一定影響 |
1. mycat(社區(qū)維護) 2. atlas(360開源) 3. cobar(阿里開源但已不維護) |
| 應用層依賴類中間件 | 1. 無需額外部署宅广，同客戶端一起發(fā)布即可饶碘； 2. 運維成本低笨腥； 3. 直連數(shù)據(jù)庫風險較低 |
無法跨語言 | Sharding-JDBC(apache官方組件較為出名)拓哺；還有一些其他的客戶端組件就不列舉了 |
個人更傾向于使用客戶端模式，服務器成本更低效率更好脖母，但開發(fā)量相比代理模式會多一些
MYCAT
1.架構
MYCAT 系統(tǒng)架構圖
關鍵點：
- mycat通過實現(xiàn)mysql通訊協(xié)議來代理數(shù)據(jù)庫
- 底層通過JDBC來對接非mysql數(shù)據(jù)庫
- mycat會對分庫分表數(shù)據(jù)進行匯總再返回
- mycat可提供一定的監(jiān)控能力
- mycat支持單庫分表士鸥，多庫單表，不支持多庫分表即 A表分為100張 DB1 50張谆级，DB2 50張這種模式是不支持的
2.高可用方案
當前mycat穩(wěn)定版本為1.6烤礁，高可用方案需要借助第三方組件聯(lián)合配置（HAproxy+keepalived）讼积，待mycat2.0搞定后會自動整合zookeeper來實現(xiàn)分布式
以下是官方2.0的餅，能不能吃上看社區(qū)的大佬了
- 完全實現(xiàn)分布式事務脚仔，完全的支持分布式币砂。
- 通過Mycat web（eye）完成可視化配置，及智能監(jiān)控玻侥，自動運維决摧。
- 通過mysql 本地節(jié)點，完整的解決數(shù)據(jù)擴容難度凑兰，實現(xiàn)自動擴容機制掌桩，解決擴容難點。
- 支持基于zookeeper的主從切換及Mycat集群化管理姑食。
- 通過Mycat Balance 替代第三方的Haproxy波岛，LVS等第三方高可用，完整的兼容Mycat集群節(jié)點的動態(tài)上下線音半。
- 接入Spark等第三方工具则拷，解決數(shù)據(jù)分析及大數(shù)據(jù)聚合的業(yè)務場景。
- 通過Mycat智能優(yōu)化曹鸠，分析分片熱點煌茬，提供合理的分片建議，索引建議彻桃，及數(shù)據(jù)切分實時業(yè)務建議坛善。
mycat高可用架構
插件介紹
- HAproxy
Haproxy是一種免費的、非沉诰欤快速和可靠的解決方案眠屎，它提供了高可用性、負載平衡和對TCP和基于http的應用程序的代理肆饶。它特別適用于非常高的流量網(wǎng)站改衩，并且擁有相當多的世界上最受歡迎的網(wǎng)站 - keepalived
keepalived是以VRRP協(xié)議為實現(xiàn)基礎的，VRRP全稱Virtual Router Redundancy Protocol驯镊，即虛擬路由冗余協(xié)議葫督。
虛擬路由冗余協(xié)議，可以認為是實現(xiàn)路由器高可用的協(xié)議阿宅，即將N臺提供相同功能的路由器組成一個路由器組候衍，這個組里面有一個master和多個backup，master上面有一個對外提供服務的vip（該路由器所在局域網(wǎng)內(nèi)其他機器的默認路由為該vip）洒放，master會發(fā)組播蛉鹿，當backup收不到vrrp包時就認為master宕掉了，這時就需要根據(jù)VRRP的優(yōu)先級來選舉一個backup當master往湿。這樣的話就可以保證路由器的高可用了
