wordpress 素材站模板,老师用什么网站做ppt,app公司网站建设,什么企业做网站比较方便呢本文我们来讨论下分布式事务的相关知识点。 分布式事务是分布式系统中非常重要的一部分#xff0c;最典型的例子是银行转账和扣款#xff0c;A 和 B 的账户信息在不同的服务器上#xff0c;A 给 B 转账 100 元#xff0c;要完成这个操作#xff0c;需要两个步骤#xff0…本文我们来讨论下分布式事务的相关知识点。 分布式事务是分布式系统中非常重要的一部分最典型的例子是银行转账和扣款A 和 B 的账户信息在不同的服务器上A 给 B 转账 100 元要完成这个操作需要两个步骤从 A 的账户上扣款以及在 B 的账户上增加金额两个步骤必须全部执行成功否则如果有一个失败那么另一个操作也不能执行。
分布式事务的经典应用比如转账扣款下订单扣库存新会员送积分等等涉及多个业务共同参与在一个请求中。
那么像这种转账扣款的例子在业务中如何保证一致性有哪些解决方案呢 分布式事务是什么
顾名思义分布式事务关注的是分布式场景下如何处理事务是指事务的参与者、支持事务操作的服务器、存储等资源分别位于分布式系统的不同节点之上。 简单来说分布式事务就是一个业务操作是由多个细分操作完成的而这些细分操作又分布在不同的服务器上事务就是这些操作要么全部成功执行要么全部不执行。 数据库事务
数据库事务的特性包括原子性Atomicity、一致性Consistency、隔离性Isolation和持久性Durabilily简称 ACID。 在数据库执行中多个并发执行的事务如果涉及到同一份数据的读写就容易出现数据不一致的情况不一致的异常现象有以下几种。 脏读是指一个事务中访问到了另外一个事务未提交的数据。例如事务 T1 中修改的数据项在尚未提交的情况下被其他事务T2读取到如果 T1 进行回滚操作则 T2 刚刚读取到的数据实际并不存在。 不可重复读是指一个事务读取同一条记录 2 次得到的结果不一致。例如事务 T1 第一次读取数据接下来 T2 对其中的数据进行了更新或者删除并且 Commit 成功。这时候 T1 再次读取这些数据那么会得到 T2 修改后的数据发现数据已经变更这样 T1 在一个事务中的两次读取返回的结果集会不一致。 幻读是指一个事务读取 2 次得到的记录条数不一致。例如事务 T1 查询获得一个结果集T2 插入新的数据T2 Commit 成功后T1 再次执行同样的查询此时得到的结果集记录数不同。 脏读、不可重复读和幻读有以下的包含关系如果发生了脏读那么幻读和不可重复读都有可能出现。 不同隔离级别
SQL 标准根据三种不一致的异常现象将隔离性定义为四个隔离级别Isolation Level隔离级别和数据库的性能呈反比隔离级别越低数据库性能越高而隔离级别越高数据库性能越差具体如下 1Read uncommitted 读未提交 在该级别下一个事务对数据修改的过程中不允许另一个事务对该行数据进行修改但允许另一个事务对该行数据进行读不会出现更新丢失但会出现脏读、不可重复读的情况。 2Read committed 读已提交 在该级别下未提交的写事务不允许其他事务访问该行不会出现脏读但是读取数据的事务允许其他事务访问该行数据因此会出现不可重复读的情况。 3Repeatable read 可重复读 在该级别下在同一个事务内的查询都是和事务开始时刻一致的保证对同一字段的多次读取结果都相同除非数据是被本身事务自己所修改不会出现同一事务读到两次不同数据的情况。因为没有约束其他事务的新增Insert操作所以 SQL 标准中可重复读级别会出现幻读。 值得一提的是可重复读是 MySQL InnoDB 引擎的默认隔离级别但是在 MySQL 额外添加了间隙锁Gap Lock可以防止幻读。 4Serializable 序列化 该级别要求所有事务都必须串行执行可以避免各种并发引起的问题效率也最低。 对不同隔离级别的解释其实是为了保持数据库事务中的隔离性Isolation目标是使并发事务的执行效果与串行一致隔离级别的提升带来的是并发能力的下降两者是负相关的关系。 分布式事务产生的原因
分布式事务是伴随着系统拆分出现的前面我们说过分布式系统解决了海量数据服务对扩展性的要求但是增加了架构上的复杂性在这一点上分布式事务就是典型的体现。 在实际开发中分布式事务产生的原因主要来源于存储和服务的拆分。 存储层拆分
存储层拆分最典型的就是数据库分库分表一般来说当单表容量达到千万级就要考虑数据库拆分从单一数据库变成多个分库和多个分表。在业务中如果需要进行跨库或者跨表更新同时要保证数据的一致性就产生了分布式事务问题。在后面的课程中也会专门来讲解数据库拆分相关的内容。 服务层拆分
服务层拆分也就是业务的服务化系统架构的演进是从集中式到分布式业务功能之间越来越解耦合。 比如电商网站系统业务初期可能是一个单体工程支撑整套服务但随着系统规模进一步变大参考康威定律大多数公司都会将核心业务抽取出来以作为独立的服务。商品、订单、库存、账号信息都提供了各自领域的服务业务逻辑的执行散落在不同的服务器上。 用户如果在某网站上进行一个下单操作那么会同时依赖订单服务、库存服务、支付扣款服务这几个操作如果有一个失败那下单操作也就完不成这就需要分布式事务来保证了。 分布式事务解决方案
分布式事务的解决方案典型的有两阶段和三阶段提交协议、 TCC 分段提交和基于消息队列的最终一致性设计。 2PC 两阶段提交
两阶段提交2PCTwo-phase Commit Protocol是非常经典的强一致性、中心化的原子提交协议在各种事务和一致性的解决方案中都能看到两阶段提交的应用。 3PC 三阶段提交
三阶段提交协议3PCThree-phase_commit_protocol是在 2PC 之上扩展的提交协议主要是为了解决两阶段提交协议的阻塞问题从原来的两个阶段扩展为三个阶段增加了超时机制。 TCC 分段提交
TCC 是一个分布式事务的处理模型将事务过程拆分为 Try、Confirm、Cancel 三个步骤在保证强一致性的同时最大限度提高系统的可伸缩性与可用性。 两阶段、三阶段以及 TCC 协议在后面的课程中我会详细介绍接下来介绍几种系统设计中常用的一致性解决方案。 基于消息补偿的最终一致性
异步化在分布式系统设计中随处可见基于消息队列的最终一致性就是一种异步事务机制在业务中广泛应用。 在具体实现上基于消息补偿的一致性主要有本地消息表和第三方可靠消息队列等。 下面介绍一下本地消息表本地消息表的方案最初是由 ebay 的工程师提出核心思想是将分布式事务拆分成本地事务进行处理通过消息日志的方式来异步执行。 本地消息表是一种业务耦合的设计消息生产方需要额外建一个事务消息表并记录消息发送状态消息消费方需要处理这个消息并完成自己的业务逻辑另外会有一个异步机制来定期扫描未完成的消息确保最终一致性。 下面我们用下单减库存业务来简单模拟本地消息表的实现过程 1系统收到下单请求将订单业务数据存入到订单库中并且同时存储该订单对应的消息数据比如购买商品的 ID 和数量消息数据与订单库为同一库更新订单和存储消息为一个本地事务要么都成功要么都失败。
2库存服务通过消息中间件收到库存更新消息调用库存服务进行业务操作同时返回业务处理结果。
3消息生产方也就是订单服务收到处理结果后将本地消息表的数据删除或者设置为已完成。
4设置异步任务定时去扫描本地消息表发现有未完成的任务则重试保证最终一致性。 以上就是基于本地消息表一致性的主流程在具体实践中还有许多分支情况比如消息发送失败、下游业务方处理失败等感兴趣的同学可以思考下。 不要求最终一致性的柔性事务
除了上述几种还有一种不保证最终一致性的柔性事务也称为尽最大努力通知这种方式适合可以接受部分不一致的业务场景。 分布式事务有哪些开源组件
分布式事务开源组件应用比较广泛的是蚂蚁金服开源的 Seata也就是 Fescar前身是阿里中间件团队发布的 TXCTaobao Transaction Constructor和升级后的 GTSGlobal Transaction Service。 Seata 的设计思想是把一个分布式事务拆分成一个包含了若干分支事务Branch Transaction的全局事务Global Transaction。分支事务本身就是一个满足 ACID 的 本地事务全局事务的职责是协调其下管辖的分支事务达成一致要么一起成功提交要么一起失败回滚。 在 Seata 中全局事务对分支事务的协调基于两阶段提交协议类似数据库中的 XA 规范XA 规范定义了三个组件来协调分布式事务分别是 AP 应用程序、TM 事务管理器、RM 资源管理器、CRM 通信资源管理器。关于 XA 规范的详细内容将会在后面的课时中介绍。 总结
掌握分布式事务是学习分布式系统的必经之路今天介绍了分布式事务的概念回顾了数据库事务和不同隔离级别以及分布式事务产生的原因最后介绍了分布式事务的几种解决方案。
