漫谈分布式事务

随着互联网的普及，互联网公司像雨后春笋一样伴随着投资公司的红利发展壮大，所以分布式技术以及分布式的解决方案也随着普及起来，分库分表以及分布式事务成了解决分布式问题跨不过的难题，那么我们今天就来聊聊什么是分布式事务，为什么需要它，它到底是用来解决什么问题的？

现在越来越多项目将自己定位为超大并发和数据的项目，所以在项目启动前就需要为未来考虑，超大大数据怎么存储和检索就是这些项目需要考虑的问题。根据经验对于单机系统来说只需要把数据存储在关系数据就可以，因为关系数据库帮我们解决了这些问题，我们完全不需要考虑事务一致性和怎么检索的问题，但是超大数据一般不会只使用一个库，分治思想是解决分布式问题的一般准则，所以我们需要把数据存储在多个表或者多个库，这样就解决超大数据存储的问题。

为什么要分开存储？
分开存储主要是为了解决快速检索的问题，在关系数据库中检索单表的数据是非常慢的，原因在于，我们不可能在表上无限建立索引，因为一般关系数据库都不建议在表上建立太多索引，因为索引需要管理，太多索引会影响到CUD的性能，即使有索引，数据库的执行计划也不一定能用上，因为如果扫描的数据太多会导致执行执行计划认为直接全表扫描性能更好。

数据分开存储带来的问题？

之前在一个数据库，事务问题可以由数据库代劳解决，但是在多个数据库的情况下就需要自己解决了。

那么一般是如何是如何解决分布式事务问题的？

具体来说要根据业务的性质来决定使用何种解决方案，我们把分布式的事务的解决方案分为两类：一种是最终一致性的解决方案，一种强一致性的解决方案

最终一致性解决方案

• 事务性发件箱机制（本地消息事务机制）

• MQ

• CDC技术

• Cadence，基于事务性发件箱机制实现，和KillBill类似

强一致性的解决方案

• 2PC
• TCC
• Saga

在分布式事务解决方面，典型的技术框架有：

• Seata，支持多种模式，AT模式（加强版2PC），TCC，Saga,在生产实践方面主推AT模式。

2PC就是两阶段提交协议，2PC协议主要是有两种角色组成，本地资源管理器和事务协调器，提交阶段分为两个阶段，一个是准备阶段，一个是提交阶段，提交的过程完全由事务协调器协调和完成，具体可以看这篇2PC的介绍

对于最终一致性方案来说主要是用于一些实时性要求不高一场景，强一致性的解决方案主要是解决订单支付，扣库存等对实时业务要求较高的场景，所以需要选择何种方案需要问问用户最多能容忍的延迟是多少。

今天我们主要介绍强一致性的解决方案的解决方案，因为对于最终一致的方案难度不是太大，门槛较低。

强一致性的解决方案首推Seata，Seata支持了很多模式，比如：AT，TCC，SAGA,XA等，对于这些模式首推AT模式。

AT模式是Seata的首创，在AT模式出来之前我们一般使用的是TCC或者SAGA，如果你使用过TCC或者SAGA你就会知道AT模式带给开发人员的便利，在现代社会，效率和性能依然是企业和架构师首先要考虑的问题。

Seata的AT模式是如何实现的？

AT模式是提供无侵入自动补偿的事务模式，对于开发人员来说不需要知道细节，分布式事务框架自动帮我们完成事务的提交和回滚，正如关系数据库做得一样，所以AT模式也实现了读已提交模式。如果你对数据库的事务实现原理有所了解的话那么你应该不会太难理解AT模式的实现方式。

对于关系数据库实现事务主要是由UNDO日志实现，我们知道在数据库进行CUD时需要将反向操作记录下来，比如，如果是新增只需要记录id，便于回滚时进行删除，如果是修改，需要修改修改的内容，对于删除需要记录整条记录，这个记录的地方就是 UNDO日志。那么Seata的原理就是和上面的过程类似。

其实除了上面的这些，Seata还需要做其它事情，从上面的内容我们知道要实现2PC必须要与事务协调器进行交互，那么这个交互过程就是框架需要实现的东西。

还有一点，Seata是如何做到无侵入的？其实很简单，JDBC提供了良好的扩展模型，我们只需要继承实现自己的connection,statement等内容就可以对JDBC的请求进行拦截了，至于其它方案spring框架为我们提供了良好的扩展接入点，所以最终我们只需要一个标签就完成所有事情，就是Seata的 AT模式带给我们的便利。