1pc事务提交协议

Posted 2021-03-20 lay2017

所有文章

https://www.cnblogs.com/lay2017/p/12078232.html

 

正文

在事务的基本概念一文中，我们知道了事务必须要满足ACID四个基本特性。如果你要让程序提供事务的特性，要满足ACID的特性，就得试着遵从一些规范。当然，如果有足够的能力，也可以自定义一些规范。

本文将学习了解相对比较简单的一阶段(1pc)事务提交协议。

1pc事务提交协议

先来看一个序列图

一阶段提交协议只有两部分

1）开启一个事务

2）正常commit事务，或者异常的时候rollback事务

1pc的优点非常显而易见。非常的简单，只需要跟一个服务端交互，在交互上的损耗明显更少，所以性能上相对是很好的。

而它的缺点也很明显。如果超过一个服务端的时候，它无法对多个服务端进行协调。所以使用场景就比较有限。

这么一看，1pc提交协议是不是很像JDBC关于事务的接口设计呢？

假设用1pc处理多个服务端？

前面，我们说1pc比较适合单个服务端的情况。如果是多个服务端，那么1pc不能够协调多个服务端的事务。

那么，我们假设1pc处理多个服务端会是怎么样？

我们看到，活动图中开启了3个事务，如果一路commit成功，那么都没问题。

如果其中一个失败，那么rollback当前事务，并需要人工干预之前提交过事务导致的数据不一致问题。

当然，在某些场景下，我们也可以选择不断地重试commit，直到成功为止（比如mq，发送消息可以重复发送，消费消息维持幂等性即可。而且mq也很少出现commit失败的情况，即使有也相对容易恢复）。但在大多数场景下，1pc很明显不适合于多数据源。

总结

我们可以这么认为，如果只针对一个数据源，或者我们可以不断重试commit（维持最终一致性）的场景下我们选择1pc事务提交协议是一个简单高效的方案。