如何编写一个分布式数据库

如何编写一个分布式数据库,第1张

某种程度上看来,数据库作为整个系统的核心,这句话其实并不夸张,数据库的选型关系到上层业务代码实现的方方面面,现在比较流行的架构方案是上层业务逻辑微服务化,并且结合分布式缓存,这套框架已经基本能做到上层业务的d性扩展,但是最底层的数据存储还是很难去中心化(除非整个技术栈中去除关系型数据库(RDBMS), 全部采用 NoSQL)。所以,经常是 RDBMS 成为整个系统的瓶颈。

在长期的斗争中,大家总结出了很多方式来扩展最底层的关系型数据库:

1 主从,一主多从,双写,通过队列暂存请求 这些方案其实并没有解决问题,写入仍然是单点,而且对于 DBA 的挑战比较大,今天我们暂时就不讨论了。

2 通过中间件 Sharding,常见的开源方案有: Cobar, TDDL, Vitess, Kingshard, MyCat 等,这些方案的思路是拦截 SQL 的请求通过 sharding key 和一定规则,将请求转发/广播到不同的 MySQL 实例上,从而实现水平扩展的效果,这个方案基本解决了单点写入的问题,对于业务来说整体的吞吐也上来了,看上去不错,这个方案是大多数业务遇到性能瓶颈的解决方案,但是缺点也是有的:

1)大多中间件都没有解决动态扩容的问题,多采用了静态的路由策略,扩容一般还处于人工 x2 的状态,对 DBA 要求比较高。

2)从一定程度上来说都放弃了事务,这是由于一条语句有可能会涉及到多个数据库实例,实现分布式 事务是一个比较难的事情,我们后面会详细的介绍。

3)对业务不透明,需要指定 sharding key, 心智负担较大

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

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

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

以上就是关于如何编写一个分布式数据库全部的内容,包括:如何编写一个分布式数据库、现在mysql的分布式数据访问层主流方案有哪些、等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/9813537.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-02
下一篇2023-05-02

发表评论

登录后才能评论

评论列表(0条)

    保存