文章探讨了分布式系统中的强一致性、最终一致性以及如何在微服务架构中通过2PC、3PC和补偿模式实现。重点介绍了CAP理论和BASE原则，并分析了2PC和3PC的优缺点，以及补偿模式作为最终一致性解决方案的应用关键点。
一致性Consistency
指分布式系统中的所有数据备份在同一时刻是否拥有同样的值。
可用性Availability
指在集群中一部分节点故障后，集群整体是否还能正常响应请求。
分区容错性PartitionTolerance
指你这个分布式系统如果不能非常及时保证数据一致性，那这个容错的时间间隔是多少。
相当于通信的时限要求，系统如果不能在一定时限内达到数据一致性，那系统应该怎么做。
由于当前网络硬件肯定会出现延迟丢包等通信异常问题，所以分区容错性必须实现。
BASE思想
BASE理论是对CAP理论的延伸，基本思想是即使无法做到强一致性，应用可以采用适合的方式达到最终一致性。
也可以简单理解Wie一个分布式系统的底线。
基本可用BasicallyAvailiable
指分布式系统在出现故障的时候，可以损失部分可用性，需要保证和核心可用。服务限流和降级就是其基本表现。
软状态SoftState
指允许系统存在中间状态，而中间状态不会影响整体可用状态。分布式存储中一般一份数据都有有若干个副本，允许不同节点间副本同步的延时就是软状态的体现。
最终一致性EventualConsistency
指系统中所有的数据副本经过一定时间后，最终能够达到一致的状态。
CAP的一致性就是强一致性，这种一致性级别是最符合用户直觉的，用户体验好，但实现起来对系统性能影响较大弱一致性正好相反。BASE中的最终一致性可以看做是弱一致性的一种特殊情况。
对比总结
CAP理论和BASE思想讨论的意义在于即使无法做到强一致性，我们也可以采用合适的方式达到最终一致性。
对于微服务架构，建议采用一种更为松散的方式来维护一致性，也就是所谓的最终一致性，对于开发者而言，实现最终一致性的方案可以根据不同的业务场景做不同的选择。
2PC
2PC分布式事务主要分为俩个阶段。
- 第一阶段：
准备阶段：由协调者提议并收集其他参与者的反馈（提议的节点为协调者，参与决议的节点为参与者）。然后将事务逻辑如果都ok的话直接将事务逻辑发放给给个参与者。
- 第二阶段：
执行阶段：根据反馈决定提交或中止事务。每个节点依据协调者发来的事务逻辑自己执行并且自己记录redolog和undolog，如果执行完都没有发生错误就给协调者返回正常，如果都返回正常协调者就会让参与者提交事务，只要有一个节点给协调者返回错误，协调者就会通知其他节点回滚数据。
总之就是，协调者发起一个提议分别询问各参与者是否接受场景，然后协调者根据参与者的反馈，提交或中止事务。
2PC的延迟问题。
问题一：同步阻塞问题
执行过程中，所有参与者都是事务阻塞型的。当参与者占用公共资源时，其他第三方节点访问公共资源就不得不处于阻塞状态。
问题二：单点故障
一旦协调者发生故障，参与者会一直阻塞下去。特别是在第二阶段，协调者发生故障，则所有参与者还处于锁定资源的状态中，但是无法完成后续的事务操作。
问题三：数据不一致
当协调者向参与者发送提交请求后发生了局部网络异常，或者在发送提交请求过程中协调者发生了故障，就会导致只有一部分参与者接收到了提交请求，这部分参与者接到请求后就会执行提交操作，而未接收到提交请求的机器就无法执行事务提交，于是就出现了数据不一致的问题。
3PC
与2PC相比，3PC主要有两个改动点：在协调者和参与者之间都引入了超时机制+把准备阶段一分为二。
3PC：CanCommit + PreCommit + DoCommit，具体操作如下。
CanCommit阶段：协调者向参与者发送提交请求，参与者如果可以事务操作就返回Yes响应，否则返回No响应。此处如果有参与者不能进行事务操作，协调者就直接终止事务，降低了参与者阻塞的时间。
PreCommit阶段：协调者根据参与者的响应情况来决定是否可以进行事务的PreCommit操作。
如果协调者从所有参与者获得反馈都是Yes响应，那么就派发任务让参与者执行事务的逻辑。
如果有任何一个参与者向在接受任务期间向协调发送了No响应，或者协调者派发任务后等待超时没有收到参与者的ACK响应，那么就通知其他参与者执行事务的中断。
DoCommit阶段：执行提交或中断事务，并且参与者自己记录事务的redolog和undolog。当协调者收到异常或者等待超时没有收到Commited，就通知其他参与者回滚。
可见，3PC主要解决了2PC的单点问题和同步阻塞问题。就是使用多一次询问，最后执行来见降低阻塞时间，提高事务执行的成功率，降低回滚率。
补偿模式
基本思路在于使用一个额外的补偿服务来协调各个需要保证一致性的微服务，补偿服务按顺序依次调用各个微服务，如果某个微服务调用失败就撤销之前所有已经完成的微服务，补偿服务对需要保证一致性的微服务提供补偿操作。
举例当中涉及两个微服务，订单微服务和支付微服务，为其提供补偿操作，如果支付服务失败，就需要取消之前的下单服务。
关键点
对于补偿服务而言，所有服务的操作记录是一个关键点，操作记录是执行取消操作的前提。
举例中，订单服务与支付服务需要保存详细的操作记录和日志，这些日志和记录有助于确定失败的步骤和状态，进而明确需要补偿的范围，然后获取所需补偿的业务数据。
如果只是订单服务失败，那么只需要补偿一个服务就可以，如果支付服务也失败了，对两个服务进行回滚。
补偿操作要求业务数据包括支付时的业务流水号、账号和金额。理论上可以根据唯一的业务流水号就能完成补偿操作，但提供更多的数据有益于微服务健壮性。
解决方案
实现补偿模式的关键要素就是记录完整的业务流水，可以通过业务流水为补偿操作提供需要的业务数据。
补偿服务可以从业务流水的状态中知道补偿的范围，补偿过程中需要的业务数据同样可以从记录的业务流水中获取。
补偿服务作为一个服务调用过程同样存在调用不成功的情况，需要通过一定的健壮性机制来保证补偿的成功率，补偿的相关操作本身需要具有幂等性。
（1）服务重启：如果失败的原因不是暂时的，而是由业务因素导致的业务错误，需要对问题进行修正后重新执行。
（2）立即重试：对于网络失败或数据库锁等瞬时异常，重试在很大程度上能够确保任务正常执行。
（3）定时调用：一般会指定调用的次数上限，如果调用次数达到上限也就不再进行重试。
最后
针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。
下面的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题（都整理成文档，小部分截图）
最新整理电子书
最后
针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。
下面的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题（都整理成文档，小部分截图）
[外链图片转存中…(img-cif3KQtD-1714793374825)]
最新整理电子书
[外链图片转存中…(img-XzJb8eG3-1714793374825)]
扫一扫
1037
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
