关于微服务:关于分布式事务的理解

业务场景

电商业务

上图是一个电商零碎，当一个订单领取实现后的业务场景：

1. 更改订单的状态为“已领取”
2. 扣减商品库存
3. 给会员减少积分
4. 创立出库单告诉仓库发货

设想一下，当订单领取实现后，集体积分提早几分钟变更，这能够承受吗？

火车票购票

想想生存中火车票购票场景。

设想一下，当最初一张火车票同时被两个人购买，去检票口检票时被告知车票有效，这能够承受吗？

银行转账

想想生存中银行转账场景。

设想一下，当银行转账时，转账胜利后，本人账户金额缩小了，对方账户却始终未进账，这能够承受吗？

对于上述的三种业务需要场景，你是怎么了解和解决的？

在解决上述问题之前，咱们先来了解以下几个概念。

什么是事务？

事务是指作为单个逻辑工作单元执行的一系列操作，要么齐全地执行，要么齐全地不执行。

数据库事务大家必定都很相熟，在开发过程中会常常应用到。

事务的个性

• Atomicity(原子性)
• Consistency(一致性)
• Isolation(隔离性)
• Durability(持久性)

原子性 是指事务中的操作要么都不做，要么就全做。

一致性 是指事务必须是使数据库从一个一致性状态变到另一个一致性状态。

隔离性 是指一个事务的执行不能被其余事务烦扰。

持久性 是指一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的。

什么是分布式事务？

分布式事务是指一次大的操作由不同的小操作组成的，而这些小的操作散布在不同的服务器上，分布式事务须要保障这些小操作要么齐全地执行，要么实现地不执行。

产生分布式事务的起因

• 业务的微服务化，例如：文章结尾所形容的电商业务场景。
• 数据库分库分表，例如：当产生数据库分库分表后，有一个需要既要操作 01 库，又要操作 02 库。

分布式实践

CAP 实践

• Consistency(一致性)
• Availability(可用性)
• Partition tolerance(分区容错性)

一致性 是指数据的强一致性，如果在某个节点更新了数据，那么在其余节点须要同时看到更新后的数据。

可用性 是指每个申请都能在正当的工夫内取得合乎预期的响应后果。

分区容错性 是指遇到任何网络分区故障的时候，零碎依然可能失常提供服务，除非是整个网络环境都产生了故障。

CAP 实践认为一个分布式系统最多只能同时满足其中的两项。因为分区容错性是必然存在的，所以大部分分布式软件系统都在 CP 和 AP 中做取舍。

例如：Zookeeper 采纳 CP 一致性，强调一致性，弱化可用性，Eureka 采纳 AP 可用性，强调可用性，弱化一致性。

BASE 实践

• Basically Available(根本可用)
• Soft state(软状态)
• Eventually consistent(最终一致性)

根本可用 是指不谋求强可用性，而且强调零碎根本可能始终运行对外提供服务。当分布式系统遇到不可预估的故障时，容许肯定水平上的不可用，比方：对申请进行限流排队，对非核心服务进行降级。

软状态 是指容许零碎中的数据存在中间状态，而不是事务的原子性：要么全副胜利，要不全副不胜利。

最终一致性 是指数据不可能始终都是软状态，必须在一个工夫期限之后达到各个节点的一致性，在此之后，所有的节点的数据都是统一的，零碎达到最终一致性。

BASE 实践的核心思想是：即便无奈做到强一致性，但每个利用都能够依据本身业务特点，采纳适当的形式来使零碎达到最终一致性。

解决方案

2PC(两阶段提交协定)

3PC(三阶段提交协定)

TCC

本地音讯表

RocketMQ 事务音讯

小结

本文纯属抛砖引玉，有问题，欢送批评指正。

对于分布式事务的可落地计划，我会在后续文章中进行介绍。

举荐浏览

• 对于解决电商零碎订单状态的流转，分享下我的技术计划（附带源码）
• 我是怎么写 Git Commit message 的？