三、1pc事务提交协议

三、1pc事务提交协议所有文章https://www.cnblogs.com/lay2017/p/12078232.html正文在事务的基本概念一文中,我们知道了事务必须要满足ACID四个基本特性。如果你要让程序提供事务的特性,要满足ACID的特性,就得试着遵从一些规范。当然,如果有足够的能力,也可以自定义一些规范

大家好,欢迎来到IT知识分享网。

所有文章

三、1pc事务提交协议

 

正文

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

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

1pc事务提交协议

先来看一个序列图

三、1pc事务提交协议

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

1)开启一个事务

2)正常commit事务,或者异常的时候rollback事务

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

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

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

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

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

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

三、1pc事务提交协议

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

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

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

总结

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

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/32361.html

(0)

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注微信