|
|
|
|
移动端

1.3.2 分布式事务

《深入理解Spring Cloud与微服务构建》第1章微服务简介,本章介绍什么是微服务、为什么需要微服务、微服务的优缺点和挑战,并且将单体架构的系统和微服务架构的系统进行了比较。本节为大家介绍分布式事务。

作者:方志朋来源:人民邮电出版社|2018-03-06 15:01

技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战

1.3.2 分布式事务

微服务架构所设计的系统是分布式系统。分布式系统有一个著名的CAP 理论,即同时满足“一致性”“可用性”和“分区容错”是一件不可能的事。CAP理论是由Eric Brewer在2000年PODC会议上提出的,该理论在两年后被证明成立。CAP理论告诉架构师不要妄想设计出同时满足三者的系统,应该有所取舍,设计出适合业务的系统。CAP理论如图1-9所示。

Consistency:指数据的强一致性。如果写入某个数据成功,之后读取,读到的都是新写入的数据;如果写入失败,之后读取的都不是写入失败的数据。

Availability:指服务的可用性。

Partition-tolerance:指分区容错。

在分布式系统中,P是基本要求,而单体服务是CA系统。微服务系统通常是一个AP系统,即同时满足了可用性和分区容错。这就有了一个难题:在分布式系统中如何保证数据的一致性?这就是大家经常讨论的分布式事务。

在微服务系统中,每个服务都是独立的进程单元,每个服务都有自己的数据库。通常情况下,只有关系型数据库在特定的数据引擎下才支持事务,而大多数非关系型数据库是不支持事务的,例如MongDB是不支持事务的,而Redis是支持事务的。在微服务架构中,分布式事务一直都是一个难以解决的问题,业界给出的解决办法通常是两阶段提交。

网上购物在日常生活中是一个非常普通的场景,假设我在淘宝上购买了一部手机,需要从我的账户中扣除1000元钱,同时手机的库存数量需要减1。当然需要在卖方的账户中加1000元钱,为了使案例简单化,暂时不用考虑。

如果这是一个单体应用,并且使用支持事务的MySQL数据库(InnoDB数据库引擎才支持事务),我们可能这样写代码:

  1. @Transactional  
  2. public void update() throws RuntimeException{  
  3. updateAccountTable(); //更新账户表  
  4. updateGoodsTable(); //更新商品表  

如果是微服务架构,账户是一个服务,而商品是一个服务,这时不能用数据库自带的事务,因为这两个数据表不在一个数据库中。因此常常用到两阶段提交,两阶段提交的过程如图1-10所示。

第一阶段,service-account 发起一个分布式事务,交给事务协调器TC处理,事务协调器TC向所有参与的事务的节点发送处理事务操作的准备操作。所有的参与节点执行准备操作,将Undo和Redo信息写进日志,并向事务管理器返回准备操作是否成功。

第二阶段,事务管理器收集所有节点的准备操作是否成功,如果都成功,则通知所有的节点执行提交操作;如果有一个失败,则执行回滚操作。

两阶段提交,将事务分成两部分能够大大提高分布式事务成功的概率。如果在第一阶段都成功了,而执行第二阶段的某一个节点失败,仍然导致数据的不准确,这时一般需要人工去处理,这就是当初在第一步记录日志的原因。另外,如果分布式事务涉及的节点很多,某一个节点的网络出现异常会导致整个事务处于阻塞状态,大大降低数据库的性能。所以一般情况下,尽量少用分布式事务。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

非常网管——网络应用

在网络应用越来越复杂的今天,传统的网络应用已经不能满足企业和用户的需要,这就对网络管理员、信息管理部门提出了更高的要求。本书介绍了...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊