指系统中所有的数据副本经过一定时间后，最终能够达到一致的状态。
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）定时调用：一般会指定调用的次数上限，如果调用次数达到上限也就不再进行重试。
如果通过服务重启、立即重试、定时调用等策略依旧不能解决问题，则需要通知相关人员进行处理，即人工干预模式。
一个完整的TCC业务由一个主服务和若干个从服务组成，主服务发起并完成整个业务流程。
从服务提供三个接口：Try、Confirm、Cancel：
小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
36515507)]
[外链图片转存中…(img-VWWQrmhi-1710936515507)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
[外链图片转存中…(img-FygNJXeK-1710936515508)]
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
