以下内容为结合网上文章和个人工作遇到的问题整合整理，若有版权问题或者引用问题，随时联系更改或删除
Cap的意思
- P 分区容错 partition tolerance
- C 一致性 consistency
- A 可用性 availability
dubbo 和 spring-cloud 是目前比较好的微服务框架，zookeeper 可以用来做注册中心，redis 更多的使用来用作分布式缓存，同时通过 zookeeper 和 redis 都可以实现分布式锁，因此都是分布式系统中常用的中间件。
分布式事务是为了分布式系统中保证不同数据库的数据一致性，它是分布式系统中至关重要但是又很难的一点，很多大厂和大神已经做过了很多的实践。首先我们来回顾一下数据库事务的 ACID 特性：
1. 原子性（A）：在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。
2. 一致性（C）：事务的执行必须保证系统的一致性。
3. 隔离性（I）：事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。
4. 持久性（D）：单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。
所谓事务都是要满足 ACID 的要求，对于 Java 应用而言，本地事务更多的是通过 Spring 来进行本地事务管理。分布式事务实现方式一般有以下几种常用的解决方案：
1、两阶段提交（2PC）:
• 优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。
• 缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。
2、补偿事务（TCC）：核心思想是针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作，它大致分为三个阶段：（1）Try 阶段主要是对业务系统做检测及资源预留（2）Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。（3）Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
• 优点： 跟 2PC 比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
• 缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
3、本地消息表（异步确保）：核心思想是将分布式事务拆分成本地事务进行处理，基本思路是消息生产方和消息消费方都执行本地事务，如果消息消费方执行失败则发送失败消息给生产方，进行相应的业务补偿，实现最终一致性。
• 优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。
• 缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会增加很多工作量。
4、MQ 事务消息：通过第三方 MQ 的事务消息实现，比如阿里的 RocketMQ 或 升级的 消息队列服务，要实现事务消息大概有三个步骤：(1) 发送Prepared消息 (2) update DB (3) 根据update DB结果成功或失败，Confirm或者取消Prepared消息。
• 优点： 实现了最终一致性，不需要依赖本地数据库事务。
• 缺点： 实现难度大，主流MQ不支持。
网友评论