mysql fabric 是一个可靠的 HA 和 Sharding 方案吗？为什么

现在还不是，性能有点差，之前看到过测试报告，MySQL-python直接连数据库qps可以到3W，通过fabric连的话，大概只有300多一点。但是SHARDING的话有人测出来用不同的驱动性能差异比较巨大。没在实际生产总用过，不过看了看，HA效果应该不错，分片的话，建议针对服务测一下。

1. proxy sharding，目前由cobar，mycat，drds，atlas修改，这几个产品的起源一般是mysqlproxy 或 ameoba，特点是mysql协议基本兼容，业务不需要做太多修改，缺点是分库分表的算法很烂，业务要自己做大堆配置

2. jdbc中间件sharding，这个和协议差不多，就是把服务实现为了一个中间件，好处是协议损失时间可以补回来，坏处是只有java可以使用，开源的有当当的jdbc sharding

3.mysql的ndbcluster和fabric，这是mysql 引擎层面做的sharding，直接用mysql的协议层和计划生成，这个做的好处是原生的协议层都是百分百支持，事务用mysql xa支持也算马马虎虎，坏处是单机引擎，不能支持大数据的sql

这3种，被统称为“share-nothing”的数据库sharing模式，share-nothing很容易理解，就是每个被sharding的数据库之间没有共享任何数据。这种模式的缺点，主要就是：

1. sharding的时候必须带sharding key，或者不带sharding key就全表扫描

2. 必须预设sharding key，但是sharding key设计是很考验架构师对体系了解的，比如这里的sharding key 会和事务息息相关

3. 对事务的支持仅限于单库，跨库事务要走二阶段，不支持read repeated和串行事务

4. 扩容意味着sharding key计算方式改变，需要停写

5. 调度角度来看，proxy部分cpu是很浪费的，流量大的时候容易变成瓶颈，流量小的时候cpu都浪费了

当然share nothing的模式也是有谷歌参与一腿的，那就是youtube的vitess，他用设计和取舍很好规避了上述的很多问题：

1. proxy 转换两次协议的浪费，vitess直接用grpc来做sql转发，这样不用自己转mysql协议

2. 扩容难题，vitess用的是范围sharding，也就是拟定每个分库key值上下限，扩容只涉及三个库，扩容一般是split模式，不需要伤经动骨

3. 语句支持，这个基本上能上层做的优化大家都有做，不赘述

4. 运维和调度模式简单，部署模式用了 kubernetes的模型，proxy被暴露为service，后面多个服务都变成pod，把部署扔给了一个好的调度模型，而且里面mysql单例是启动在docker上，再把存储挂载在普通硬盘上，实现了存储和进程基本分离

5. 事务不赘述，基本上其他几个能不能做是意愿问题，不是设计问题

6. 自建二级索引，方便查找，方便不用先定sharding key

所以没有把vitess归类在上面任意一个层里，它比较独立，看起来vitess是不是完美了？并不是，毕竟share nothing模式的思路一开始就是有问题的，等我接下来细细分析为何vitess这个设计这么牛逼的项目 在谷歌基本上属于边缘甚至被淘汰项目

---