当前位置: 首页 > >

mysql 分布式集群方案

发布时间:







这些做sharding的产品一般分为三个层次,我来简单说下:
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


? 腾讯的


4. tidb 谷歌的全世界数据库. 融合 ol olpq 在线查询和在线分析两方面.? 增加事务. 要求时间排序.




这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这个设计这么牛逼的项目 在谷歌基本上属于边缘甚至被淘汰项目

大家也可以关注我,我会在个人专栏专门撰文论述,分析各个数据库扩容方案和办法,欢迎探讨








分布式事务数据库中的 事务顺序确认


图来自 2010 谭俊青 mysql 数据库集群的高可用设计及应用





友情链接: