Java生鲜电商平台SpringCloud微服务架构中分布式事务解决方案.docxVIP

Java生鲜电商平台-SpringCloud微服务架构中分布式事务处理方案 说明：Java 生鲜电商平台中由于接受了微服务架构进行业务的处理，买家，卖家，配送，销售，供应商等进行服务化，但是不行避开存在分布式事务的问题 业界有很多的处理方案，对此我信任大家都百度一下子就有很多，但是我巨人大哥想说的是：微服务架构中应当尽量避开分布式事务。 下面就是来争辩下，分布式事务中次要聚焦于强全都性和最终全都性的处理方案。 微服务的进展 微服务提倡将简单的单体应用拆分为若干个功能简约、松耦合的服务，这样可以降低开发难度、添加扩展性、便于灵敏开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开头了微服务的争辩和实践。 微服务落地存在的问题 虽然微服务现在如火如荼，但对其实践其实仍处于探究阶段。很多中小型互联网公司，鉴于阅历、技术实力等问题，微服务落地比较困难。 如有名架构师 Chris Richardson 所言，目前存在的次要困难有如下几方面： 单体应用拆分为分布式系统后，进程间的通讯机制和毛病处理措施变的愈加简单。 系统微服务化后，一个看似简约的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的格外突出。 微服务数量众多，其测试、部署、监控等都变的愈加困难。 随着 RPC 框架的成熟，第一个问题已经渐渐得到处理。例如 springcloud 可以格外好的支持 restful 调用，dubbo 可以支持多种通讯协议。 对于第三个问题，随着 docker、devops 技术的进展以及各公有云 paas 平台自动化运维工具的推出，微服务的测试、部署与运维会变得越来越简约。 而对于其次个问题，现在还没有通用方案很好的处理微服务产生的事务问题。分布式事务已经成为微服务落地最大的妨碍，也是最具挑战性的一个技术难题。 ACID 原子性（Atomicity）: 一个事务的全部系列操作步骤被看成是一个动作，全部的步骤要么全部完成要么一个也不会完成，假如事务过程中任何一点失败，将要被转变的数据库记录就不会被真正被转变。 全都性（Consistency）: 数据库的约束 级联和触发机制 Trigger 都必需满足事务的全都性。也就是说，通过各种途径包括外键约束等任何写入数据库的数据都是有效的，不能发生表与表之间存在外键约束，但是有数据却违反这种约束性。全部转变数据库数据的动作事务必需完成，没有事务会创建一个无效数据形态，这是不同于 CAP 理论的全都性consistency. 隔离性（Isolation）: 次要用于实现并发把握, 隔离能够确保并发执行的事务能够挨次一个接一个执行，通过隔离，一个未完成事务不会影响另外一个未完成事务。 长久性（Durability）: 一旦一个事务被提交，它应当长久保存，不会由于和其他操作冲突而取消这个事务。很多人认为这意味着事务是长久在磁盘上，但是规范没有特殊定义这点。 全都性理论 分布式事务的目的是保障分库数据全都性，而跨库事务会遇到各种不行把握的问题，如个别节点永久性宕机，像单机事务一样的 ACID 是无法奢望的。 另外，业界有名的 CAP 理论也告知我们，对分布式系统，需要将数据全都性和系统可用性、分区容忍性放在天平上一起考虑。 两阶段提交协议(简称 2PC)是实现分布式事务较为经典的方案，但 2PC 的可扩展性很差，在分布式架构下应用代价较大，eBay 架构师 Dan Pritchett 提出了 BASE 理论，用于处理大规模分布式系统下的数据全都性问题。 BASE 理论告知我们：可以通过放弃系统在每个时辰的强全都性来换取系统的可扩展性。 CAP 理论 在分布式系统中，全都性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)3 个要素最多只能同时满足两个，不行兼得。其中，分区容忍性又是不行或缺的。 image 全都性：分布式环境下，多个节点的数据能否强全都。可用性：分布式服务能一直保证可用形态。当用户发出一个恳求后，服务能在有限时间内前往结果。分区容忍性：特指对网络分区的容忍性。举例：Cassandra、Dynamo 等，默认优先选择 AP，弱化 C;HBase、MongoDB 等，默认优先选择 CP，弱化 A。 BASE 理论 核心思想： 基本可用(Basically Available)：指分布式系统在消灭毛病时，允许损失部分的可用性来保证核心可用；软形态(Soft state)：指允许分布式系统存在两头形态，该两头形态不会影响到系统的全体可用性；最终全都性(Eventual consistency)：指分布式系统中的全部副本数据经过肯定时间后，最终能够达到全都的形态；原子性（A）与长久性（D）必需根本保