分布式事务处理基本原理

事务是有一系列对系统中数据进行访问与更新的操作组成的一个基本的程序逻辑执行单元。引入事务的概念有两个目的,第一,事务对多个并发访问的应用程序进行隔离,防止彼此干扰,第二,事务为数据库操作序列提供了一个失败回复的方法,同时如果数据库处于异常状态,事务提供了保持一致性的方法。

事务具有最基本的四个特性:原子性(Atomicity),一致性(consistency),隔离性(Isolation)和持久性(Durability)。简称为ACID事务特性。

原子性:

事务必须是一个原子的执行序列,即事务包含的一系列操作执行过程只有两个结果:全部执行成功或全部失败,若有任何一项任务失败,则整个事务都被撤销,并回滚到事务执行之前的系统状态。

一致性:

事务的执行过程不可以破坏系统的一致性,事务执行之前和执行之后,系统都必须处于一致性状态,事务的执行会使系统从一个一致性状态跳转的另一个状态,如果事务在执行过程发生错误导致只有一部分任务被写入系统,那事务被重新执行时就会重新执行已写入数据库的操作,导致系统不一致。

隔离性

不同事务的执行过程不能相互干扰,每个事务都有各自独立的数据空间,在标准SQL规范中,有四个事务隔离级别:

1)未授权读取:事务在对数据修改过程中,允许脏读,即允许另外的事务在修改过程访问数据,造成修改前后读取数据不一致

2)授权读取:事务在修改过程不允许其他事务进行读,其他事务只能在修改读取数据的事务执行过程结束后进行读取,但事务执行过程也会允许不可重复读取:例如A将i从1修改到2,B将i从2修改到3,事务C读取i时可以读取到2或3。

3)可重复读取:保证一个事务在读取过程数据永远一致,但会出现幻影数据,即事务被重复执行多次,每次的数据读取结果不同。

4)串行化:所有事务都被串行执行。

为了保证数据库并发性能,一般都支持授权读取,可能出现并发问题时用乐观锁或悲观锁进行事务控制。

持久性:事务提交之后对数据库的影响是永久的,一旦数据库挂掉,执行过的事务结果可以被恢复。

CAP定理:

一个分布式系统不可能同时满足一致性(Consistency),可用性(Availability)和分区容错性(Partition tolerance),最多只能满足两个。

1)一致性:数据多个副本内容是否保持一致。不同副本一般保存在不同节点中。如果对其中一个副本更改,所有用户可获得最新的数据,则系统保持的是强一致性,如果系统中的副本在一段时间后可以达到一致,则系统满足的是最终一致性

2)可用性:系统的服务必须一直处于可用状态,对用户的每一个请求总是能在一段时间内返回结果。一段时间是系统设计之初就指定好的指标,也可称为响应时间。

3)分区容错性:分布式系统在遇到任何网络分区故障时,仍然需要能够对外保持一致性和可用性的服务,除非整个网络都发生了故障。网络分区是指不同的节点在不同的网络间,网络之间无法联通,出现故障,分布式系统被划分成了孤立的区域。

下面是CAP定理的应用:


放弃CAP定理


结果


放弃C


放弃P就是将所有数据都放置在一个节点上,这就放弃了数据的可扩展性。


放弃A


放弃可用性是指系统在发生故障时,收到影响的服务需要等待一段时间,在这段时间内系统是不可用的。


放弃P


放弃一致性是指放弃系统强一致性采用最终一致性

时间: 2024-11-11 01:56:58

分布式事务处理基本原理的相关文章

分布式爬虫基本原理 -《狗嗨默示录》-

分布式爬虫基本原理: 找一台高性能服务器,用于redis队列的维护以及数据的存储. 扩展scrapy程序,让其通过服务器的redis来获取start_urls,并改写pipeline里数据存储部分,把存储地址改为服务器地址. 在服务器上写一些生成url的脚本,并定期执行. 常见的防抓取屏蔽的方法: 设置download_delay,这个方法基本上属于万能的,理论上只要你的delay足够长,网站服务器都没办法判断你是正常浏览还是爬虫.但它带来的副作用也是显然的:大量降低爬取效率.因此这个我们可能需

分布式事务处理学习报告

1.什么是事务? 事务通俗说就是一个事情分为多个步骤完成: 比如: 2.事务的ACID四大属性: 原子性(Atomicity):意为:即一事务的操作要么全部执行,要么全部不执行.当事务非正常终止时,其中间结果将被取消. 一致性(Consistence):指的是保证数据在变化中只存在一个完整状态.比如修改一个人的信息(姓名,性别,年龄),在更新过程中发生错误,则所做的修改要么全没了,要么全保留. 隔离性(Isolation):一个未完成事务不能在提交前就把其中间结果提供给其它事务使用. 持久性(D

ORA-02049: 超时: 分布式事务处理等待锁诊断

正式环境有两个数据库A和B,在A库上建的dblink,业务是要将A库中的一些表,通过dblink更新到B库中去,更新的时候总是报错:ORA-02049: 超时: 分布式事务处理等待超时. 之前我写过一篇blog:ORA-02049: 超时: 分布式事务处理等待锁模拟,大致的意思是通过A更新B中的数据时,由于B库中的数据有锁,一直都不释放,导致通过A更新报错. 诊断如下: 在B库上执行,找到产生锁的会话 select s.owner, s.object_name, l.SID, l.TYPE, l

【转】错误: ORA-01591: 锁被未决分布式事务处理 7.2.428982 持有--解决方案

SQL 错误: ORA-01591: 锁被未决分布式事务处理 7.2.428982 持有 01591. 00000 -  "lock held by in-doubt distributed transaction %s" *Cause:    Trying to access resource that is locked by a dead two-phase commit transaction that is in prepared state. *Action:   DBA

.NET简谈事务、分布式事务处理

在本人的 " .NET简谈事务本质论"一文中我们从整体上了解了事务模型,在我们脑子里能有一个全局的事务处理结构,消除对数据库事务的依赖理解,重新认识事务编程模型. 今天这篇文章我们将使用.NET C#来进行事务性编程,从浅显.简单的本地事务开始,也就是我们用的最多的ADO.NET事务处理,然后我们逐渐扩大事务处理范围,包括对分布式事务处理的使用,多线程事务处理的使用. 数据库事务处理 数据库事务处理我们基本都很熟悉了,begin Transaction --end Transactio

.NET分布式事务处理总结【下】 - 包含MSMQ的分布式事务处理

转自:http://www.cnblogs.com/daxnet/archive/2011/03/15/1984995.html .NET直接提供对MSMQ的访问支持,只需要添加System.Messaging程序集引用即可方便地操作MSMQ.MSMQ支持两种事务处理模式:内部事务处理以及基于MS-DTC的分布式事务处理. MSMQ的内部事务处理 MSMQ的内部事务处理是指,仅采用MSMQ本身提供的事务处理机制完成事务处理.比如,假设有一系列的消息需要发布到MSMQ,那么,就可以启动一个内部事务

ORA-01591: 锁被未决分布式事务处理解决方案

现场报有一个功能走不下去,后台日志报错:java.sql.SQLException: ORA-01591: 锁被未决分布式事务处理 657.7.39336 持有.    解决方案: rollback force '657.7.39336';--执行可能会比较慢 执行完成后,查询DBA_2PC_PENDING, select * from DBA_2PC_PENDING s  where s.local_tran_id='657.7.39336'; 657.7.39336 SP4GD.a6dfea

【JTA】JTA允许应用程序执行分布式事务处理

JTA,即Java Transaction API,JTA允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据.JDBC驱动程序的JTA支持极大地增强了数据访问能力. http://baike.baidu.com/link?url=SNKjFH-_gd0t4CYnCC_h-yHP9DvgQS6urhSe8ewwAUBm7yfjfR-7f7CM0Aha9WFP1-1YaRmN_lwOuJhrwl5mBa

ORA-02049: 超时: 分布式事务处理等待锁

java.sql.SQLSyntaxErrorException: ORA-02049: 超时: 分布式事务处理等待锁 ORA-06512: 在 "HECDEV.BGT_JOURNAL_BALANCE_PKG", line 107 ORA-06512: 在 "HECDEV.BGT_JOURNAL_BALANCE_PKG", line 902 ORA-06512: 在 "HECDEV.BGT_JOURNAL_BALANCE_PKG", line 1