浅析SQL Server实现分布式事务的两阶段提交协议2PC

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
日志服务 SLS,月写入数据量 50GB 1个月
简介:

不久之前团队有个新人问我一个很重要的web服务接口如何保证事务的问题。因为涉及到跨库事务,当时我只是回答目前我们的SOA框架都不支持跨库事务。然后就问到了数据库跨库事务是如何实现的,我只能凭印象含糊回答多数是基于数据库日志(后来知道就是所谓的预写日志Write-Ahead Logging),具体数据库内部如何控制数据一致性则真的说不清楚。后来一起查了一下事务的资料,原来DB的事务控制除了基于预写日志还要实现两阶段提交协议(2PC),参考MSDN摘抄两段加深印象。

一、2PC的两个阶段

1、准备阶段(Prepare Phase)

When the transaction manager receives a commit request, it sends a prepare command to all of the resource managers involved in the transaction. Each resource manager then does everything required to make the transaction durable, and all buffers holding log images for the transaction are flushed to disk. As each resource manager completes the prepare phase, it returns success or failure of the prepare to the transaction manager.

2、提交阶段(Commit Phase)

If the transaction manager receives successful prepares from all of the resource managers, it sends commit commands to each resource manager. The resource managers can then complete the commit. If all of the resource managers report a successful commit, the transaction manager then sends a success notification to the application. If any resource manager reported a failure to prepare, the transaction manager sends arollback command to each resource manager and indicates the failure of the commit to the application.

 

二、2PC的原理示例

如何理解2PC实现分布式事务的呢?下面举例说明下。

假设有A、B、C三个数据库,A作为一个事务发起者,称为“主库”,B和C则称为”从库”。假设需要执行一个在A、B和C三个库的某个表中插入一行数据的事务。

准备阶段(Prepare Phase),A锁定表,并将事务写入自己的预写日志;A将事务发给从库B和C,B和C也各自锁定自己的表,并把事务写入预写日志,完成后返回告诉A准备阶段完成;
提交阶段(Commit Phase),A开始执行自己的事务,并通知B和C提交事务。如果在这个过程中没有任何错误,那么操作将在A、B和C库中完成;如果发生错误,比如从库C超时无响应,或者从库C磁盘空间不足…A将通知所有参与事务的B和C回滚该事务,并且回滚A自己的事务。

dbtrans

 

顺便重点再提一下预写日志,因为数据库的这种日志无比重要,普通的增删改查、数据还原、单库事务以及本文的分布式事务都离不开它,没有它绝大多数主流数据库的数据一致性根本无法实现。

到这里大家应该已经看到,相比单库事务,分布式事务控制更加复杂,而且开销极大。虽然一些高级开发框架如.net framework提供了较为强大丰富的类库如TransactionScope来简化开发分布式事务,但是建议能不用则不用,因为它被反映普遍存在性能问题无意识的死锁问题。这种分布式事务的场景如果频繁出现,重新拆分系统合理规划架构才是正道。

 

总结:在大型web应用中如何保持事务这个话题被问得非常多,个人已经是不止一次被问到所维护的站点是如何实现事务的。在分布式多集群环境下,业务逻辑错综复杂,保证数据库完全可靠存储当然并不容易。但是web应用程序的一个典型特点是读多写少,牺牲极少的数据一致性获得系统的高可扩展性可维护性以及高性能,那么一点点的数据不准确在业务上完全可以容忍,何况我们有日志,后续还有很多补偿措施,甚至直接人工介入处理也未尝不可。







本文转自JeffWong博客园博客,原文链接:http://www.cnblogs.com/jeffwongishandsome/p/Talk_About_2PC_In_Implementing_DBTransaction.html,如需转载请自行联系原作者

目录
相关文章
|
11月前
|
JSON 分布式计算 前端开发
前端的全栈之路Meteor篇(七):轻量的NoSql分布式数据协议同步协议DDP深度剖析
本文深入探讨了DDP(Distributed Data Protocol)协议,这是一种在Meteor框架中广泛使用的发布/订阅协议,支持实时数据同步。文章详细介绍了DDP的主要特点、消息类型、协议流程及其在Meteor中的应用,包括实时数据同步、用户界面响应、分布式计算、多客户端协作和离线支持等。通过学习DDP,开发者可以构建响应迅速、适应性强的现代Web应用。
473 2
|
12月前
|
监控
分布式-Zookeeper-Zab协议
分布式-Zookeeper-Zab协议
|
12月前
|
关系型数据库 MySQL 网络安全
5-10Can't connect to MySQL server on 'sh-cynosl-grp-fcs50xoa.sql.tencentcdb.com' (110)")
5-10Can't connect to MySQL server on 'sh-cynosl-grp-fcs50xoa.sql.tencentcdb.com' (110)")
|
12月前
|
网络协议 网络安全 网络架构
分布式基础-网络通信协议讲解
分布式基础-网络通信协议讲解
分布式基础-网络通信协议讲解
|
11月前
|
架构师 Java 数据中心
二阶段提交:确保分布式系统中数据一致性的关键协议
【10月更文挑战第16天】在分布式系统中,数据一致性的维护是一个至关重要的挑战。为了应对这一挑战,二阶段提交(Two-Phase Commit,简称2PC)协议应运而生。作为一种经典的分布式事务协议,2PC旨在确保在分布式系统中的所有节点在进行事务提交时保持一致性。
124 0
|
SQL 分布式计算 MaxCompute
一种基于ODPS SQL的全局字典索引分布式计算思路
本文提供一种能充分利用分布式计算资源来计算全局字典索引的方法,以解决在大数据量下使用上诉方式导致所有数据被分发到单个reducer进行单机排序带来的性能瓶颈。
|
SQL 存储 监控
SQL Server的并行实施如何优化?
【7月更文挑战第23天】SQL Server的并行实施如何优化?
409 13
解锁 SQL Server 2022的时间序列数据功能
【7月更文挑战第14天】要解锁SQL Server 2022的时间序列数据功能,可使用`generate_series`函数生成整数序列,例如:`SELECT value FROM generate_series(1, 10)。此外,`date_bucket`函数能按指定间隔(如周)对日期时间值分组,这些工具结合窗口函数和其他时间日期函数,能高效处理和分析时间序列数据。更多信息请参考官方文档和技术资料。
262 9
|
SQL 存储 网络安全
关系数据库SQLserver 安装 SQL Server
【7月更文挑战第26天】
169 6
|
算法 数据库 OceanBase
共识协议的技术变迁问题之Raft协议对分布式系统有什么贡献
共识协议的技术变迁问题之Raft协议对分布式系统有什么贡献
129 8

热门文章

最新文章