前言
1.为什么要分库分表
分表原因
- 单表容量不足
- 业务逻辑需要隔离(如按照地区进行区别存储)
- 隔离热点数据(场景较少)
- 单表查询效率变差，优化索引已无效
分库原因
- 业务并发量大，单库io遇到瓶颈
- 服务set化，在数据存储层面也进行隔离
2.数据库中间件分类
| 种类 | 优点 | 缺点 | 开源组件 |
|---|---|---|---|
| 服务端代理类中间件 | 1. 跨平台迁移简单； 2. 监控比较好做 |
1. 需要独立部署额外运维； 2. 对性能有一定影响 |
1. mycat(社区维护) 2. atlas(360开源) 3. cobar(阿里开源但已不维护) |
| 应用层依赖类中间件 | 1. 无需额外部署，同客户端一起发布即可； 2. 运维成本低； 3. 直连数据库风险较低 |
无法跨语言 | Sharding-JDBC(apache官方组件较为出名)；还有一些其他的客户端组件就不列举了 |
个人更倾向于使用客户端模式，服务器成本更低效率更好，但开发量相比代理模式会多一些
MYCAT
1.架构
MYCAT 系统架构图
关键点：
- mycat通过实现mysql通讯协议来代理数据库
- 底层通过JDBC来对接非mysql数据库
- mycat会对分库分表数据进行汇总再返回
- mycat可提供一定的监控能力
- mycat支持单库分表，多库单表，不支持多库分表即 A表分为100张 DB1 50张，DB2 50张这种模式是不支持的
2.高可用方案
当前mycat稳定版本为1.6，高可用方案需要借助第三方组件联合配置（HAproxy+keepalived），待mycat2.0搞定后会自动整合zookeeper来实现分布式
以下是官方2.0的饼，能不能吃上看社区的大佬了
- 完全实现分布式事务，完全的支持分布式。
- 通过Mycat web（eye）完成可视化配置，及智能监控，自动运维。
- 通过mysql 本地节点，完整的解决数据扩容难度，实现自动扩容机制，解决扩容难点。
- 支持基于zookeeper的主从切换及Mycat集群化管理。
- 通过Mycat Balance 替代第三方的Haproxy，LVS等第三方高可用，完整的兼容Mycat集群节点的动态上下线。
- 接入Spark等第三方工具，解决数据分析及大数据聚合的业务场景。
- 通过Mycat智能优化，分析分片热点，提供合理的分片建议，索引建议，及数据切分实时业务建议。
mycat高可用架构
插件介绍
- HAproxy
Haproxy是一种免费的、非常快速和可靠的解决方案，它提供了高可用性、负载平衡和对TCP和基于http的应用程序的代理。它特别适用于非常高的流量网站，并且拥有相当多的世界上最受欢迎的网站 - keepalived
keepalived是以VRRP协议为实现基础的，VRRP全称Virtual Router Redundancy Protocol，即虚拟路由冗余协议。
虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip（该路由器所在局域网内其他机器的默认路由为该vip），master会发组播，当backup收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了
