[TOC] ## 1.事务ACID特性： 　　①原子性（A）：整个事务的所有操作要么全部完成，要么全部不做，没有中间状态，一旦其中一个操作发生错误，所有执行过的操作都回滚。 　　②一致性(C)：事务的执行必须保证系统的一致性，只要事务执行成功，所有操作的数据都必须正常。 　　③隔离性（I）：事务与事务直接不会相互影响。 　　④持久性（D）: 一个事务完成，对数据的变更实现了持久化。 ## 2. CAP理论：  　　CAP理论是指：一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）。任何分布式系统最多只能满足其中的两种，如spring cloud满足AP规则，分布式事务满足AP或者CP。 　　一致性是指分布式下多节点数据是否一致； 可用性是指分布式服务保持持续可用状态；分区容忍性是指分区网络下的容忍性，这在分布式环境是必须的。 ## 3. BASE理论：  　　BASE理论是指：基本可用性（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）. 　　基本可用性指分布式故障时，允许损失部分的可用性来保证核心 功能可用； 　　软状态指允许分布式系统存在中间状态，该中间状态不影响系统整体可用性； 　　最终一致性指分布式系统中所有副本数据经过一定时间后，最终达到一致的状态； ## 4. 一致性模型 　　数据一致性模型分为三种： 　　①强一致性：要求任何时候副本中的数据必须保持一致，一般采用同步更新操作。 　　②弱一致性：不承诺立即更新读取的数据，也不承诺多久可以读取。 　　③最终一致性：弱一致性的一种形式，数据更新后，系统不承诺立即更新读取到的数据，但是会保证最终可以读取更新的数据。 ## 5. 分布式解决方案 　　1. 2PC（强一致性）：分阶段提交，记录事务提交所处的阶段状态，组件重启之后，可通过日志恢复事务提交的阶段状态并重试，数据节点需要保证提交的幂等。 　　2PC存在的问题是当某阶段提交比较耗时会影响整个流程造成阻塞。 　　2. eBay事件队列方案(最终一致性)：它的核心思想是将需要分布式处理的任务通过消息或者日志的方式来异步执行，消息或日志可以存到本地文件、数据库或消息队列，再通过业务规则进行失败重试，它要求各服务的接口是幂等的。 　　3. TCC(Try-Confirm-Cancel)补偿模式（最终一致性）：在多服务依次请求调用中，弱其中一个环节出错，则前面之前成功的环节回滚，回滚成功后，系统数据是一致的。 　　实现的关键要素：服务调用链必须被记录下来；每个服务提供者需要提供业务回滚操作；按照失败原因执行不同的回滚策略。 ## 6.XA 事务： XA（eXtended Architecture）是指由X/Open 组织提出的分布式交易处理的规范。XA 是一个分布式事务协议，由Tuxedo 提出，所以分布式事务也称为XA 事务。XA 协议主要定义了事务管理器TM（Transaction Manager，协调者）和资源管理器RM（Resource Manager，参与者）之间的接口。其中，资源管理器往往由数据库实现，如Oracle、DB2、MySQL，这些商业数据库都实现了XA 接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA 事务是基于两阶段提交（Two-phaseCommit，2PC）协议实现的，可以保证数据的强一致性，许多分布式关系型数据管理系统都采用此协议来完成分布式。阶段一为准备阶段，即所有的参与者准备执行事务并锁住需要的资源。当参与者Ready时，向TM 汇报自己已经准备好。阶段二为提交阶段。当TM 确认所有参与者都Ready 后，向所有参与者发送COMMIT 命令。 XA 事务允许不同数据库的分布式事务，只要参与在全局事务中的每个结点都支持XA 事务。Oracle、MySQL 和SQL Server 都支持XA 事务。 XA 事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。 资源管理器：提供访问事务资源的方法。通常一个数据库就是一个资源管理器。 事务管理器：协调参与全局事务中的各个事务。需要和参与全局事务的所有资源管理器进行通信。 应用程序：定义事务的边界。 XA 事务的缺点是性能不好，且无法满足高并发场景。一个数据库的事务和多个数据库间的XA 事务性能会相差很多。因此，要尽量避免XA 事务，如可以将数据写入本地，用高性能的消息系统分发数据，或使用数据库复制等技术。只有在其他办法都无法实现业务需求，且性能不是瓶颈时才使用XA。 >[info]幂等：是指任意多次执行与一次执行的结果都相同，例如支付场景下网络异常，用户多次点击支付，最后只扣除一次余额。