0%

数据库设计以及分布式事务的产生

1
2
3
4
5
6
作者: 夜泊1990
企鹅: 1611756908
鹅群: 948233848
邮箱: hd1611756908@163.com
博客: https://hd1611756908.github.io/
B 站: https://space.bilibili.com/514155929/

一、数据库架构的演进

单点时代

1
在早期互联网或者当前小型网站,一般数据库和APP都采用单点方式进行部署,系统简单,容易维护

读写分离

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
随着互联网的发展,网站访问量越来越大,数据库最先达到瓶颈,这时候开始设计数据库集群方案,读写分离是一个不错的解决方案

由图可以看出一共有两台MySQL,也可以是多台,一台MySQL设计成主库,其他设计成从库;主库用户写操作,从库用于读操作,实现了数据库访问的读写分离.

这时候又会产生一个新问题,我们应用访问数据库的时候(比如发送insert/update/delete/select),将怎么区分这些请求,把他们转发到不同的MySQL服务上呢?

看图里面有一个中间件(或者叫数据库中间件),他可以帮助我们进行请求的转发以及查询的负载均衡,而我们应用直接访问中间件即可,和访问单点数据库一样,不需要做复杂的调整,甚至可以做到不调整.

当前互联网上提供的中间件有很多,下面简单说下:
1. 奇虎360的Atlas
1.1 Atlas是360团队基于MySQL官网的mysql-proxy之上开发而来
1.2 在360内部得以广泛引用,每天承载的请求多大几十亿条.是一个比较成熟的方案
1.3 360对外开源但是不在维护,不过是一个比较成熟的方案(支持MySQL的版本不能低于5.1不能高于5.6)
1.4 地址: https://gitee.com/qihoo360/Atlas/blob/master/README_ZH.md
1.5 防止出现单点故障,可以使用keepalived进行VIP方案设计

2. 美团的DBProxy
2.1 DBProxy中间件是基于奇虎360的Atlas进行的二次开发
2.2 当前在美团内部也得到了大规模使用,同样开源出来的对MySQL的版本有限制不能超过5.6版本

3. MyCat
3.1 这个中间件个人不是很清楚,不知道哪个大公司在用,有没有成熟的技术落地方案
3.2 查看官网文档,有点草根,不清楚哪些公司在用,所以不知道是否稳定
3.3 个人不建议使用,如果不了解一个技术,最好别用,前面不知道有多少坑在等着你.
3.4 增加开发和运维成本,拖累团队和公司

4. MySQL官方的 MySQL Router
4.1 MySQL官网提供的一个数据库中间件,在提供了MySQL Router之后mysql-proxy就不维护了
4.2 在我们MYSQL服务器的安装(Linux)文章中有介绍,想了解可以自己看下,适用于MySQL的InnoDB Cluster集群设置.

分库分表

1
2
3
4
随着互联网的发展,数据库访问量持续增加,从最开始的单点,到读写分离,也已经不能满足当前的系统要求,这时候可以将整合的系统进行差分,将数据库里面的表拆分到不同的数据库里,进一步降低单点的访问压力.


虽然数据库的压力降低了但是又有新的问题产生了,那就是数据库事务问题,可能在一个业务需求里面要操作多个数据库,这时候多个数据库就不能保证事务的正确性,这时分布式事务产生.

二、分布式事务

2.1 分布式事务产生的原因

1
2
3
分库分表
1. 当数据库访问量特别大,并且数据库里面的数据剧增的时候,这个时候为了降低系统压力,提高查询效率就要考虑分库分表
2. 但是这里注意,如果能不进行分库分表就尽量不要分库分表,或者是只进行分库,尽量不要分表,如果设计成分库分表之后,当前系统复杂度就不是上升一个两个的级别,涉及到开发,运维等各种问题.

分库分表产生的多数据源造成的分布式事务

1
2
3
4
多数据源问题产生的分布式事务
1. 首先就是一个业务中涉及到多个数据库操作(多个数据库涉及到多个数据库连接)
2. 如上图所以的操作,比如说一个下单的业务,需要向订单表插入数据,还需要从库存表中减库存
3. 恰好订单表在订单的数据库中,库存表在库存的数据库中,分别在两个数据库中,这个下单操作就不能保证事务

分布式框架产生的多服务造成的分布式事务

1
由图可以看出,服务造成的分布式事务和多数据源造成的分布式事务产生的原因是不一样的,可以有不同的解决方案.

2.2 分布式事务解决方案

2.2.1 多数据源问题产生的分布式事务解决方案

1
2
3
4
5
6
1. 多数据源的分布式事务,Java语言提供了JTA(Java Transaction API)的解决方案
2. SpringBoot通过使用Atomikos或Bitronix嵌入式事务管理器支持跨多个XA资源的分布式JTA事务
3. 需要保证数据库支持XA MySQL数据库5.x以上支持XA协议
4. SpringBoot通过使用Atomikos或Bitronix官网地址:
https://docs.spring.io/spring-boot/docs/2.1.18.RELEASE/reference/html/boot-features-jta.html


2.2.2 多服务问题产生的分布式事务解决方案

1
2
3
4
5
6
7
8
9
10
1. 补偿事务(TCC)
2. MQ 事务消息
3. Seata

由于多服务问题产生的分布式事务,当前比较流行的解决方案是TCC事务补偿,基于TCC事务补偿框架也有很多,但是一般代码侵入性都比较大,很多公司都喜欢自己实现TCC的业务.

常见的TCC框架有:
1. tcc-transaction(官网没说是否兼容JTA)
2. ByteTCC (兼容JTA)
3. Seata(开源的社区共建的一个分布式事务解决方案,不知道后期会不会一直繁荣下去)

以上内容涉及到的内容不止是数据库设计的发展还有应用服务的发展,后面有时间给大家说一下分布式的解决方案的实战.

----------------本文结束感谢您的阅读---------------