区别
| Mycat | Sharding-JDBC | Sharding-Proxy | Sharding-Sidecar | |
|---|---|---|---|---|
| 官方网站 | 官方网站 | 官方网站 | 官方网站 | 官方网站 |
| 源码地址 | GitHub | GitHub | GitHub | GitHub |
| 官方文档 | Mycat 权威指南 | 官方文档 | 官方文档 | 官方文档 |
| 开发语言 | Java | Java | Java | Java |
| 开源协议 | GPL-2.0/GPL-3.0 | Apache-2.0 | Apache-2.0 | Apache-2.0 |
| 数据库 | MySQL Oracle SQL Server PostgreSQL DB2 MongoDB SequoiaDB |
MySQL Oracle SQLServer PostgreSQL 任何遵循 SQL92 标准的数据库 |
MySQL/PostgreSQL | MySQL/PostgreSQL |
| 连接数 | 低 | 高 | 低 | 高 |
| 应用语言 | 任意 | Java | 任意 | 任意 |
| 代码入侵 | 无 | 需要修改代码 | 无 | 无 |
| 性能 | 损耗略高 | 损耗低 | 损耗略高 | 损耗低 |
| 无中心化 | 否 | 是 | 否 | 是 |
| 静态入口 | 有 | 无 | 有 | 无 |
| 管理控制台 | Mycat服务器托管网-web | Sharding-UI | Sharding-UI | Sharding-UI |
| 分库分表 | 单库多表/多库单表 | ✔️ | ✔️ | ✔️ |
| 多租户方案 | ✔️ | — | — | — |
| 读写分离 | ✔️ | ✔️ | ✔️ | ✔️ |
| 分片策略定制化 | ✔️ | ✔️ | ✔️ | ✔️ |
| 分布式主键 | ✔️ | ✔️ | ✔️ | ✔️ |
| 标准化事务接口 | ✔️ | ✔️ | ✔️ | ✔️ |
| XA强一致事务 | ✔️ | ✔️ | ✔️ | ✔️ |
| 柔性事务 | — | ✔️ | ✔️ | ✔️ |
| 配置动态化 | 开发中 | ✔️ | ✔️ | ✔️ |
| 编排治理 | 开发中 | ✔️ | ✔️ | ✔️ |
| 数据脱敏 | — | ✔️ | ✔️ | ✔️ |
| 可视化链路追踪 | — | ✔️ | ✔️ | ✔️ |
| 弹性伸缩 | 开发中 | 开发中 | 开发中 | 开发中 |
| 多节点操作 | 分页 去重 排序 分组 聚合 |
分页 去重 排序 分组 聚合 |
分页 去重 排序 分组 聚合 |
分页 去重 排序 分组 聚合 |
| 跨库关联 | 跨库 2 表 Join ER Join 基于 caltlet 的多表 Join |
— | — | — |
| IP 白名单 | ✔️ | — | — | — |
| SQL 黑名单 | ✔️ | — | — | — |
| 存储过程 | ✔️ | — | — | — |
一、ShardingSphere
- ShardingSphere-JDBC
- ShardingSphere-Proxy
- ShardingSphere-Sidecar（TODO）
混合架构
ShardingSphere-JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；ShardingSphere-Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。 Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应用系统，使得架构师更加自由地调整适合与当前业务的最佳系统架构。
这里的代理服务，是单机
Sharding-Proxy整合Haproxy实现高可用
这里Haproxy负载了多MySQL节点，不是多Sharding-Proxy服务节点，如果用NGINX服务反向代理做负载均衡能否实现Proxy代理服务高可用
Apache ShardingSphere Proxy 负载均衡小练习
这个是结合zookper来处理的高可用，里面有服务注册，和节点注册，需要研究看看
二、Mycat
HaProxy+Keepalived+Mycat高可用集群配置
集群部署图理解： 服务器托管网1、keepalived和haproxy必须装在同一台机器上（如192.168.46.161机器上，keepalived和haproxy都要安装），keepalived负责为该服务器抢占vip（虚拟ip），抢占到vip后，对该主机的访问可以通过原来的ip（192.168.46.161）访问，也可以直接通过vip（192.168.46.180）访问。 2、192.168.46.162上的keepalived也会去抢占vip，抢占vip时有优先级，配置keepalived.conf中的（priority 150 #数值愈大，优先级越高,192.168.46.162上改为120，master和slave上该值配置不同）决定。但是一般哪台主机上的keepalived服务先启动就会抢占到vip，即使是slave，只要先启动也能抢到。 3、haproxy负责将对vip的请求分发到mycat上。起到负载均衡的作用，同时haproxy也能检测到mycat是否存活，haproxy只会将请求转发到存活的mycat上。 4、如果一台服务器（keepalived+haproxy服务器）宕机，另外一台上的keepalived会立刻抢占vip并接管服务。如果一台mycat服务器宕机，haporxy转发时不会转发到宕机的mycat上，所以mycat依然可用。
三、痛点和选型
| 功能 | MyCat | ShardingShpere |
| 联合查询 | 最多支持2表（Share Join） | 不支持 |
| 高可用 | HaProxy+Keepalived+Mycat | zk方式需要调研 |
| 动态建表 | 不支持 | 不支持 |
| 侵入性 | 除多表联合查询外，不需要修改代码， 要么修改mycat相关源码， 要么查出相关数据，使用java代码做关联 |
需要修改代码 |
| 代码集成 | 不需要集成到服务 | 需要集成到服务中 |
| 故障转移 | 节点自判断，会有误判断操作，若多节点下， 单节点服务存在误判断，其他节点与服务不知道，此时会出现多点写入，若按照时间分片，此时数据错乱。 |
sharding-ui界面下线，非自动 |
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
