小王面试某互联网公司高级开发岗位，介绍项目的时候，谈到公司业务量和研发团队暴增后，自己主导完成公司项目的架构升级，从传统的单体架构升级到微服务架构，面试官接下来就问了一道经典面试题：你们架构升级过程中，分布式事务是如何解决的？请介绍一下。
主要围绕三个大方向：
1. 事务相关概念介绍；
2. 分布式事务常见方案；
3. 柔性事务之最大努力通知型落地实现；
事务是一系列的动作,它们综合在一起才是一个完整的工作单元,这些动作必须全部完成,如果有一个失败的话,那么事务就会回滚到最开始的状态,仿佛什么都没发生过一样。
应用多次数据库操作，通过用事务进行管理，来保证ACID原则。
原子性（A）：操作这些指令时，要么全部执行成功，要么全部不执行。只要其中一个指令执行失败，所有的指令都执行失败，数据进行回滚，回到执行指令前的数据状态。
一致性（C）：事务的执行使数据从一个状态转换为另一个状态，事务在执行之前和之后，数据库都必须处于一致性状态。
隔离性（I）：在该事务执行的过程中，无论发生的任何数据的改变都应该只存在于该事务之中，对外界不存在任何影响。只有在事务确定正确提交之后，才会显示该事务对数据的改变。其他事务才能获取到这些改变后的数据。
持久性（D）：当事务正确完成后，它对于数据的改变是永久性的。
C：一致性，数据一致性：强一致性、弱一致性、最终一致性。
强一致性：流程涉及的各个环节数据必须实时一致性
弱一致性：流程涉及的各个环节数据允许存在部分数据不一致
最终一致性：允许存在中间状态，只要求经过一段时间后，数据最终是一致的
A：可用性：系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
P：分区容错性（一定会存在）：分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务。
无法同时满足CAP，常见组合：AP：互联网业务 CP：金融业务
base理论是CAP理论中AP方案的延伸，核心思想是即时无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
Basically Available（基本可用）Soft state（软状态，中间状态）Eventually consistent（最终一致性）
分布式场景下，多个服务同时对服务一个流程，比如电商下单场景，需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败，或者网络不通引起的请求丢失，那么整个系统可能出现数据不一致的原因。
常见方案：
1. 设计方案尽可能规避分布式事务方案（相似的业务放在一起，不要过度拆分）
2. 强事务(CP, 低并发短事务)和柔性事务(AP，高性能)
强事务：满足CP理论，XA协议（2PC、JTA、JTS）、3PC，但由于同步阻塞，处理效率低，适合低并发、短事务业务。
2PC：Seeta(AT)、LCN(2PC)，适合分布式系统 JTA：atomikos(适合单系统多数据源)
柔性事务：满足AP，base理论，适合异步更新数据，并且对数据的实时性要求较低的场景，主要分为： .补偿型（TCC、saga） .最大努力通知型（MQ、本地消息表） .异步确保型（MQ、本地消息表）
实现方式：TCC(seeta-tcc,lcn-tcc)、Saga（seeta-saga状态机模式、Aop模式）、本地事务消息、事务消息MQ
互联网业务，一般的流量比较大，涉及很多高并发场景，我们一般采用柔性事务，这样系统的性能好。
互联网应用最广泛：
本文链接：http://www.28at.com/showinfo-26-96756-0.html面试官问到分布式事务？这样回答就对了！
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
