Go项目（分布式事务）
文章目录
简介
- 目前，项目的主要代码已经开发完毕，其中最关键的是订单系统（钱），不能出错；但这里还有一些问题需要解决
- 整个下单支付的流程没有问题，但是如果出现网络抖动/断网（远程调用其他服务会有网络问题，导致库存扣减不成功回滚）或者业务上没有超时机制，会出现问题或者给用户带来不好的体验
- 这些问题需要用分布式事务解决
分布式事务
- 回顾一下事务的特性
- 分布式事务满足不了 ACID，其实单机应用也并不能完全保证，不然怎么有四个隔离级别呢
- 分布式事务面临最主要的问题就是网络问题，因为涉及到和其他机器的网络连接
- 网络问题：请求没有发送出去，发出去了没有收到返回
- 造成网络问题的常见原因：硬件故障、网络抖动、网络拥塞
- 网络调用和单机不一样，并不能因为出现网络问题就直接像 MySQL 那样触发回滚
CAP
- 简单介绍一下 CAP 理论，分布式系统的理论基石
- Consistency (一致性)
- “all nodes see the same data at the same time”
- 即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性，可以理解为同步操作
- 一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题
- 从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致
- Availability (可用性)
- “Reads and writes always succeed”
- 即服务一直可用，而且是正常响应时间
- 好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况
- Partition Tolerance (分区容错性)
- 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务
- 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体
- 比如现的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响
- 分区容错性必须满足，否则不能称之为分布式系统
- 但 CAP 三个特性一般只能满足其中两个，所以我们只有两种策略可用
- CP
- AP
BASE
- 在分布式系统中，我们希望满足 CAP，只能各方面做出一些让步
- 或者说权衡一致性（C）和可用性（A）
- 满足一致性时，只满足弱一致性，允许有时差，举个例子：转账操作后会提示两小时内到账
- 满足可用性时，只是基本满足，当系统在出现不可预知的故障时，允许损失部分可用性，举个例子：流量激增时，会将一部分用户引导到降级页面，提示当前系统繁忙，10s后刷新重试
- BASE 是 Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）的缩写，BASE 理论就是对 CAP 中一致性和可用性权衡的结果
- 基本可用上面已经解释了
- 软状态：允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
- 最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态
- 总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统的事务 ACID 特性是相反的
- 注：在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的
- 因此在具体的分布式系统架构设计过程中，ACID 特性和 BASE 理论往往又会结合在一起
- 理论知识需要逐步深化理解，不可能一蹴而就
常见方案
rocketmq
