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

一、数据库架构的演进

单点时代

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

---

读写分离

---

分库分表

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(开源的社区共建的一个分布式事务解决方案,不知道后期会不会一直繁荣下去)

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