微服务架构如何保证数据一致性.docxVIP

微服务架构如何保证数据全都性 1.1 本地事务 传统单机应用使用一个RDBMS作为数据源，应用开启事务，进行CRUD，提交或回滚事务，统统发生在本地事务中，由资源管理器（RM）直接供应事务支持。数据的全都性在一个本地事务中得到保证。 1.2 分布式事务 1.2.1 两阶段提交（2PC） 当应用渐渐扩展，消灭一个应用使用多个数据源的情况，这个时候本地事务已经无法满足数据全都性的要求。由于多个数据源的同时访问，事务需要跨多个数据源管理，分布式事务应运而生。其中最流行的就是两阶段提交（2PC），分布式事务由事务管理器（TM）统一管理。 两阶段提交分为预备阶段和提交阶段。 两阶段提交-commit 两阶段提交-rollback 然而两阶段提交也不能完全保证数据全都性问题，并且有同步堵塞的问题，所以其优化版本三阶段提交（3PC）被创造了出来。 1.2.2 三阶段提交（3PC） 三阶段提交 然而3PC也只能保证绝大多数情况下的数据全都性。 具体分布式事务2PC和3PC的具体引见请见 ?关于分布式事务、两阶段提交协议、三阶提交协议。分布式事务不是本文的重点，故不开放。 2. 微服务下的事务管理 那么，分布式事务2PC或者3PC能否适合于微服务下的事务管理呢？答案能否定的，缘由有三点： 由于微服务间无法直接进行数据访问，微服务间相互调用通常通过RPC（dubbo）或Http API（SpringCloud）进行，所以已经无法使用TM统一管理微服务的RM。 不同的微服务使用的数据源类型可能完全不同，假如微服务使用了NoSQL之类不支持事务的数据库，则事务根本无从谈起。 即便微服务使用的数据源都支持事务，那么假如使用一个大事务将很多微服务的事务管理起来，这个大事务维持的时间，将比本地事务长几个数量级。如此长时间的事务及跨服务的事务，将为产生很多锁及数据不行用，严峻影响系统功能。 由此可见，传统的分布式事务已经无法满足微服务架构下的事务管理需求。那么，既然无法满足传统的ACID事务，在微服务下的事务管理必定要遵照新的法则－－BASE理论。 BASE理论由eBay的架构师DanPritchett提出，BASE理论是对CAP理论的延长，核心思想是即便无法做到强全都性，应用应当可以接受合适的方式达到最终全都性。BASE是指基本可用（BasicallyAvailable）、软形态（ Soft State）、最终全都性（ Eventual Consistency）。 基本可用 ：指分布式系统在消灭毛病的时候，允许损失部分可用性，即保证核心可用。 软形态：允许系统存在两头形态，而该两头形态不会影响系统全体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软形态的体现。 最终全都性 ：最终全都性是指系统中的全部数据副本经过肯定时间后，最终能够达到全都的形态。弱全都性和强全都性相反，最终全都性是弱全都性的一种特殊情况。 BASE中的 最终全都性是对于微服务下的事务管理的根本要求，既基于微服务的事务管理无法达到强全都性，但必需保证最重全都性。那么，有哪些方法可以保证微服务下的事务管理的最终全都性呢，依据实现原理分次要有两类，大事通知型和补偿型，其中大事通知型又可分为牢靠大事通知模式及最大努力通知模式，而补偿型又可分为TCC模式、和业务补偿模式两种。这四种模式都可以达到微服务下的数据最终全都性。 3. 实现微服务下数据全都性的方式 3.1 牢靠大事通知模式 3.1.1 同步大事 牢靠大事通知模式的设计理念比较简约理解，即是主服务完成后将结果通过大事（经常是消息队列）传递给从服务，从服务在接遭到消息后进行消费，完成业务，从而达到主服务与从服务间的消息全都性。首先能想到的也是最简约的就是同步大事通知，业务处理与消息发送同步执行，实现规律见下方代码准时序图。 public void trans() { try { // 1. 操作数据库 bool result = dao.update(data);// 操作数据库失败，会抛出特别 // 2. 假如数据库操作成功则发送消息 if(result){ mq.send(data);// 假如方法执行失败，会抛出特别 } } catch (Exception e) { roolback();// 假如发生特别，就回滚 } } 上面的规律看上去天衣无缝，假如数据库操作失败则直接退出，不发送消息；假如发送消息失败，则数据库回滚；假如数据库操作成功且消息发送成功，则业务成功，消息发送