共计 3100 个字符，预计需要花费 8 分钟才能阅读完成。
目录
面试题 1：说说什么分布式事务？解释一下什么是 CAP？
CAP 了解：
诘问 1：怎么了解强一致性、弱一致性和最终一致性？
面试题 2：理解 BASE 实践么？
诘问 1：基于 BASE 实践，举几个理论的例子
面试题 3：实现分布式事务一致性（Consistency）的办法有哪些?
诘问 1：说一下二阶段提交（2PC）的原理吧
总结
面试题 1：说说什么分布式事务？解释一下什么是 CAP？
当初互联网开发多应用微服务架构，一个简略的操作，在服务端可能就是由多个服务和数据库实例协同实现的。但在一致性要求较高且高 QPS 的场景下，多个独立操作之间的一致性问题和服务高可用问题就显得分外辣手。
基于对程度扩容能力和老本思考，针对除非敏感业务（如领取、转账等）外的大量其余业务，传统的强统一的解决方案逐步被淘汰。
其理论依据就是 CAP 原理。在分布式系统中，同时满足 CAP 定律中的一致性 Consistency、可用性 Availability 和分区容错性 Partition Tolerance 三者是不可能的。在绝大多数的场景，为了可用性和分区容错性，都须要就义强一致性来换取零碎的高可用性，零碎往往只须要保障最终一致性。
CAP 了解：
Consistency：一致性就是在客户端任何时候看到各节点的数据都是统一的。
Availability：可用性就是在任何时刻都能够提供读写。
Partition Tolerance：分区容错性是在网络故障、某些节点不能通信的时候零碎仍能持续工作。
具体地讲在分布式系统中，在任何数据库设计中，一个 Web 利用最多只能同时反对下面的两个属性。显然，任何横向扩大策略都要依赖于数据分区。因而，设计人员必须在一致性与可用性之间做出抉择。
AP（高可用 && 分区容错）:
容许至多一个节点更新状态会导致数据不统一，即丢失了 C 性质（一致性）。会导致全局的数据不统一。
CP（统一 && 分区容错）:
为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丢失了 A 性质（可用性）。分区同步会导致同步工夫有限缩短（也就是等数据同步实现之后能力失常拜访）
CA（统一 && 高可用）:
两个节点能够相互通信，能力既保证 C（一致性）又保障 A（可用性），这又会导致丢失 P 性质（分区容错性）。这样的话就分布式节点碰壁，无奈部署子节点, 放弃了分布式系统的可扩展性。因为分布式系统与单机零碎不同，它波及到多节点间的通信和交互，节点间的分区故障是必然产生的，所以在分布式系统中分区容错性是必须要思考的。
分布式事务服务
分布式事务服务（Distributed Transaction Service，DTS）是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。
CAP 实践通知咱们在分布式存储系统中，最多只能实现下面的两点。而因为以后的网络硬件必定会呈现提早丢包等问题，所以分区容忍性是咱们必须须要实现的，所以咱们只能在一致性和可用性之间进行衡量。
为了保障系统的可用性，互联网零碎大多将强一致性需要转换成最终一致性的需要，并通过零碎执行幂等性的保障，保证数据的最终一致性。
诘问 1：怎么了解强一致性、弱一致性和最终一致性？
强一致性：当更新操作实现之后，任何多个后续过程或者线程的拜访都会返回最新的更新过的值。这种是对用户最敌对的，就是用户上一次写什么，下一次就保障能读到什么。依据 CAP 实践，这种实现须要就义可用性。
弱一致性：零碎并不保障后续过程或者线程的拜访都会返回最新的更新过的值。零碎在数据写入胜利之后，不承诺立刻能够读到最新写入的值，也不会具体的承诺多久之后能够读到。
最终一致性：弱一致性的特定模式。零碎保障在没有后续更新的前提下，零碎最终返回上一次更新操作的值。在没有故障产生的前提下，不统一窗口的工夫次要受通信提早，零碎负载和复制正本的个数影响。DNS 是一个典型的最终一致性零碎。
最终一致性是指零碎中所有的正本通过一段时间的异步同步之后，最终可能达到一个一致性的状态，也就是说在数据的一致性上存在一个短暂的提早。
简直所有的互联网零碎采纳的都是终一致性，只有在切实无奈应用终一致性，才应用强一致性或事务，比方，对于决定零碎运行的敏感数据，须要思考采纳强一致性，对于与钱无关的领取零碎或金融零碎的数据，须要思考采纳事务。
也就是说可能应用最终一致性的业务就尽量应用最终一致性，因为强一致性会升高零碎的可用性。
面试题 2：理解 BASE 实践么？
在分布式系统中，咱们往往谋求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？前人曾经给咱们提出来了另外一个实践，就是 BASE 实践，它是用来对 CAP 定理进行进一步裁减的。BASE 实践指的是：
Basically Available（根本可用）
Soft state（软状态）
Eventually consistent（最终一致性）
BASE 实践是对 CAP 中的一致性和可用性进行一个衡量的后果，是对互联网大规模分布式系统的实际总结，强调可用性。
实践的核心思想就是：根本可用（Basically Available）和最终一致性（Eventually consistent）。尽管无奈做到强统一，但每个利用都能够依据本身的业务特点，采纳适当的形式来使零碎达到最终一致性（Eventual consistency）。
诘问 1：基于 BASE 实践，举几个理论的例子
咱们以 12306 订票零碎为例
1. 流量削峰
能够在不同的工夫，发售不同区域的票，将拜访申请错开，减弱申请峰值。比方，在春运期间，深圳登程的火车票在 8 点开售，北京登程的火车票在 9 点开售。
2. 提早响应
在春运期间，本人提交的购票申请，往往会在队列中排队期待解决，可能几分钟或十几分钟后，零碎才开始解决，而后响应处理结果。
3. 体验降级
比方用小图片来代替原始图片，通过升高图片的清晰度和 大小，晋升零碎的解决能力。
4. 过载爱护
比方把接管到的申请放在指定的队列中排队解决，如果申请等 待工夫超时了（假如是 100ms），这个时候间接回绝超时申请；再比方队列满了之后，就 革除队列中肯定数量的排队申请，爱护零碎不过载，实现零碎的根本可用。
面试题 3：实现分布式事务一致性（Consistency）的办法有哪些?
为了解决分布式系统的一致性问题，在长期的摸索钻研过程中，涌现出了一大批经典的一致性协定和算法，其中最驰名的就是二阶段提交协定、三阶段提交协定和 Paxos 算法。
诘问 1：说一下二阶段提交（2PC）的原理吧
二阶段提交（two-phase commit）减少了事务处理器和事务执行者的角色。由事务处理器来进行整个事务的解决。次要流程如上面的图
两阶段提交协定
prepare(筹备阶段)
当开始事务调用的时候，事务处理器向事务执行者（有可能是数据库自身反对）收回命令，事务执行者进行 prepare 操作。
当所有事务执行者都实现了 prepare 操作，就进行下一步行为。
如果有一个事务执行者在执行 prepare 的时候失败了，那么告诉事务处理器，事务处理器再告诉所有的事务执行者执行回滚操作。
commit(提交阶段)
当所有事务执行者都 prepare 胜利当前，事务处理器会再次发送 commit 申请给事务执行者，所有事务执行者进行 commit 解决。
当所有 commit 解决都胜利了，那么事务执行完结。
如果有一个事务执行者的 commit 解决不胜利，这个时候就要告诉事务处理器，事务处理器告诉所有的事务执行者执行回滚 (abort) 操作。
然而两阶段提交的诟病就是在于性能问题。比方因为执行链比拟长，锁定资源的工夫也变长了。所以在高性能的零碎中都会防止应用二阶段提交。
总结
本篇文章就到这里了，心愿能给你带来帮忙
