谈谈本人结合实际,对分布式系统事务的应用与理解。
我们在架构系统时,通常会做N层,分层的意义在于系统结构更清晰,易于维护,易于扩展等。我将拿四层结构举例,谈谈对分布式系统事务的实际应用。
首先,系统四层做如下定义:模型层,数据层,业务层,服务层.
然后,阐述四层的意义:
模型层:作为ORM的Object,不作详细说明
数据层:访问具体DB,实现SQL执行
业务层:实现简单,独立业务
服务层:实现大粒度业务,需要各业务层协作完成的业务逻辑
实例说明,完成一个用户注册场景:
假设,用户登录与用户基本信息存储不同的DB,DB处于不同服务器。
完成这个逻辑,1写入数据至用户登录表,2写入数据至基本信息表;而这两个动作是完整,需保持一致性。
没有采用分布式系统事务
伪代码如下:
object bllobject1=new
userbll();
//创建一个BLL对象
bllobject1.adduserpassport(userpassport u);
//保存用户登录信息
object bllobject2=new
userbll();
//创建一个BLL对象
bllobject2.adduserinfo(userinfo
u);
//保存用户基本信息
采用分布式系统事务
伪代码如下:
Using
(CommittableTransaction tran=new
CommittableTransaction())
{
object bllobject1=new
userbll();
//创建一个BLL对象
bllobject1.adduserpassport(userpassport u);
//保存用户登录信息
object bllobject2=new
userbll();
//创建一个BLL对象
bllobject2.adduserinfo(userinfo
u);
//保存用户基本信息
try
{
…
tran.Commit();//事务提交
}
catch
{…
tran.Rollback();//事务回退
}
}
调用服务层分布式系统事务
伪代码如下:
class userservice
{
void register(object user) //注册信息类,继承userpassport ,
userinfo
{
Using
(CommittableTransaction tran=new
CommittableTransaction())
{
object bllobject1=new
userbll();
//创建一个BLL对象
bllobject1.adduserpassport(userpassport u);
//保存用户登录信息
object bllobject2=new
userbll();
//创建一个BLL对象
bllobject2.adduserinfo(userinfo
u);
//保存用户基本信息
try
{
…
tran.Commit();//事务提交
}
catch
{…
tran.Rollback();//事务回退
}
}
}
}
调用服务层 new userservice ().register(object
user)
为实现分布式事务的一致性,还需要分DB或不同的DB驱动
做不同的配置
MSSQL 配置MSDTC(后续跟进)
XA可针对不同的DB(后续跟进)
总结,很多时候,程序员喜欢写存储过程,将事务放在存储过程处理;具体情况具体处理,个人认为,不利于系统的维护,增加了数据间的偶合;对后期分库分表,优化DB带来大量的维护工作。
分布式系统事务 浅析
时间: 2024-08-25 20:14:45
分布式系统事务 浅析的相关文章
分布式系统事务
丁码农 专注大规模互联网架构... 分布式系统事务 本文首发于InfoQ,版权所有,请勿转载!!! http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency 开篇 在OLTP系统领域,我们在很多业务场景下都会面临事务一致性方面的需求,例如最经典的Bob给Smith转账的案例.传统的企业开发,系统往往是以单体应用形式存在的,也没有横跨多个数据库.我们通常只需借助开发平台中特有数据访
分布式系统事务一致性
单数据库一致性: 1. 利用事务 分布式系统事务一致性: 1. 本地事务消息队列:两段提交,利用本地事务保证消息的可靠性 生产者: 1). 在数据库(mysql)增加一个消息表,将本地数据修改和消息记录放到同一个事务中,保证同时成功或失败. 2). 本地数据修改成功后,事务提交完毕.producer向MQ发送一个消息,发送成功,更新消息表消息为已读 3). 为避免producer消息发送失败的情况.有一个定时任务,定时查询消息表,将未消费的消息放到MQ的消息队列中 消费者: 1). consum
分布式系统事务随笔。
刚做后端大概10个月,从游戏前端开发转向后端,看似熟悉的编程语言,在不同的领域内实际上要考虑的事情也是全然不同的. 当我们谈论后端开发,自然而然联想到,后端是服务于前端的,也是承载.服务于业务的一个重要组成部分.系统的稳定性,正确性以及可用性都是需要考虑的问题. 做后端,说简单也简单,说难也很难,简单是因为你只需要对数据进行增删查改,聚合统计就完事了,说难是因为一旦涉及到可用性,必然离不开分布式,然而我们知道,由分布式而引出的一系列问题才是最为棘手的,更不用说系统安全.部署.监控等一些列的落地措
分布式系统事务一致性解决方案
开篇 在OLTP系统领域,我们在很多业务场景下都会面临事务一致性方面的需求,例如最经典的Bob给Smith转账的案例.传统的企业开发,系统往往是以单体应用形式存在的,也没有横跨多个数据库.我们通常只需借助开发平台中特有数据访问技术和框架(例如Spring.JDBC.ADO.NET),结合关系型数据库自带的事务管理机制来实现事务性的需求.关系型数据库通常具有ACID特性:原子性(Atomicity).一致性(Consistency).隔离性(Isolation).持久性(Durability).
聊聊分布式事务&;分布式系统事务一致性解决方案
事务就是一个会话过程中,对上下文的影响是一致的,要么所有的更改都做了,要么所有的更变都撤销掉.就要么生,要么死.没有半死不死的中间不可预期状态. 参考下薛定谔的猫. 事务是为了保障业务数据的完整性和准确性的. 分布式事务,常见的两个处理办法就是两段式提交和补偿. 两段式提交典型的就是XA,有个事务协调器,告诉大家,来都准备好提交,大家回复,都准备好了,然后协调器告诉大家,一起提交,大家都提交了. 补偿比较好理解,先处理业务,然后定时或者回调里,检查状态是不是一致的,如果不一致采用某个策略,强制状
二:分布式系统事务
一:事务--->是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元.保证数据在业务逻辑上是正确的.--->事务的四大特征:原子性,一致性,隔离性,持久性.简称事务的ACID特性.●原子性 要么全部成功执行,要么全部失败.●一致性 事务的一致性,数据合乎逻辑.只能从一个一致性状态变到另一个一致性状态.不允许出现中间状态的数据.●隔离性 事务的隔离性是指在并发环境中.并发的事务是相互隔离的.一个事务的执行不能被其他事务干扰.即一个事务内
事务浅析
Ⅰ.事务概述 事务是一个程序的执行单元 事务由一组sql组成(可以是1条或者多条) tips: 一个事务可以有多条sql组成,tps是每秒的事务量,仅仅通过tps判断业务量高和低是不太准确的,如果事物里面sql比较多,即使tps比较低,那实际qps又是比较高的 Ⅱ.事务的特性 大家都知道事务的特性叫ACID,我们这把用很通俗的语言来描述这四个特性,具体实现后面再分析 A--atomicity(原子性) 一个事务内所有sql操作是原子的,要么都做要么都不做 原子性由redo保证 C--consis
分布式系统事务一致性解决方案大对比,谁最好使?
http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650992884&idx=1&sn=17a7e218a5087faf9dac2d369202089f&scene=4&ptlang=2052&ADUIN=1219704545&ADSESSION=1465865470&ADTAG=CLIENT.QQ.5467_.0&ADPUBNO=26567#wechat_redirect
如何解决分布式系统数据事务一致性问题(HBase加Solr)
如何解决分布式系统数据事务一致性问题 (HBase加Solr) 摘要:对于所有的分布式系统,我想事务一致性问题是极其非常重要的问题,因为它直接影响到系统的可用性.本文以下所述所要解决的问题是:对于入HBase和Solr的过程,如何保证HBase中写入的数据与Solr中写入的数据完全一致. 关键词:HBase, Solr, 分布式, 事务, 系统架构, 大数据 作者:王安琪(博客:http://www.cnblogs.com/wgp13x/) 一.关于分布式系统事务一致性问题 Java 中有三种可