bytetcc

前言 本文主要讲解不同场景下分布式事务的解决方案，以及区别和相关理论。（部分图片来自网络） 一、分布式事务的相关理论 CAP理论： 一致性（Consistency） 可用性（Availability） 分区容错（Partition-tolerance） 一个分布式系统最多只能满足以上的两项，分区容错性是分布式系统必然需要面对和解决的问题，因此在一些大型互联网公司都会把精力放在如何在C（一致性）和A（可用性）之间寻求平衡。 BASE理论 基本可用（Basically Available） 指分布式系统在出现不可预知故障的时候，允许损失部分可用性。 软状态（ Soft State） 指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。 最终一致（ Eventual Consistency） 强调的是所有的数据更新操作，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。 BASE理论即在整体可用的情况下，满足最终一致性，BASE理论可以说是CAP理论的拓展。 二、分布式事务解决方案 1.跨库事务（强一致性事务） 跨库事务即在一个jvm内调用两个数据库。 XA是由X/Open组织提出的分布式事务的规范

微服务越来越火。很多互联网公司，甚至一些传统行业的系统都采用了微服务架构。体会到微服务带来好处的同时，很多公司也明显感受到微服务化带来的一系列让人头疼的问题。本文是笔者对自己多年微服务化经历的总结。 如果你正准备做微服务转型，或者在微服务化过程中遇到了困难，此文很可能会帮到你！ 写在前面 正文开始前，为了让各位读友更好的理解本文内容，先花两分钟了解一下微服务的优缺点。 微服务的好处 聊起微服务，很多朋友都了解微服务带来的好处，罗列几点： 模块化，降低耦合 将单体应用按业务模块拆分成多个服务，如果某个功能需要改动，大多数情况，我们只需要弄清楚并改动对应的服务即可。只改动一小部分就能满足要求，降低了其他业务模块受影响的可能性。从而降低了业务模块间的耦合性。 屏蔽与自身业务无关技术细节 例如，很多业务需要查询用户信息，在单体应用的情况下，所有业务场景都通过 DAO 去查询用户信息，随着业务发展，并发量增加，用户信息需要加缓存，这样所有业务场景都需要关注缓存，微服务化之后，缓存由各自服务维护，其他服务调用相关服务即可，不需要关注类似的缓存问题。 数据隔离，避免不同业务模块间的数据耦合 不同的服务对应不同数据库表，服务之间通过服务调用的方式来获取数据。 业务边界清晰，代码边界清晰 单体架构中不同的业务，代码耦合严重，随着业务量增长，业务复杂后，一个小功能点的修改就可能影响到其他业务点

一、概念 分布式事务就是将多个节点的事务看成一个整体处理 　分布式事务由事务参与者、资源服务器、事务管理器等组成　 常见的分布式事务的例子： 支付、下订单等 二、实现思路 两段式事务和三段式事务 基于XA的分布式事务 基于消息的最终一致性方案 TCC编程式补偿事务（被认为最好的方式） 1、两段式事务（很少使用） 2、基于XA的分布式事务 3、基于消息的最终一致性方案（用的比较广泛） 4、TCC编程式补偿事务 三、基于消息的最终一致性方案与TCC编程式补偿事务的区别 基于消息事务是强一致性事务，会存在资源浪费 TCC事务是柔性事务，在try阶段要对资源做预留 TCC事务在确认或取消阶段释放资源 与基于消息事务对比，TCC的时效性更好 四、分布式事务框架 全局事务服务（Global Transaction Service，简称GTS） 蚂蚁金服分布式事务（Distributed Transaction-eXtended，简称DTX） 开源TCC框架（TCC-Ttansaction） 开源TCC框架（ByteTCC） 来源： oschina 链接： https://my.oschina.net/u/4287847/blog/4275249

Spring Cloud 分布式事务管理 在微服务如火如荼的情况下，越来越多的项目开始尝试改造成微服务架构，微服务即带来了项目开发的方便性，又提高了运维难度以及网络不可靠的概率. Spring Cloud 分布式事务管理 单体式架构 微服务架构 优点: 缺点: 分布式事务的引入 分布式事务解决方案 基于XA协议的两阶段提交 消息事务+最终一致性 TCC编程模式 具体实现 LCN ByteTCC 在说微服务的优缺点时，有对比才会更加明显，首先说一下单体式结构 单体式架构 在单体式架构中，系统通常采用分层架构模式（MVC），持久化层、表示层，业务逻辑层。架构主要存在以下问题： 系统内部互相访问，耦合紧密导致难以维护； 各业务领域需要采用相同的技术栈，难以快速应用新技术（例如使用SSH很难向SSM改造）； 对系统的任何修改都必须整个系统一起重新部署/升级； 在系统负载增加时，难以进行水平扩展； 当系统中一处出现问题，会影响整个系统； 为了克服以上缺点，微服务架构应运而生。微服务，又叫微服务架构。微服务就是一些协同工作的小而自治的服务. 微服务架构 优点: 1. 技术异构性 在不同的服务中，可以使用不同的技术来各自开发，只要保证服务间能相互协作即可 2. 弹性 当微服务中的某一个服务不可用时，不会影响整个系统，只会影响相关功能不可用 3. 扩展 易于扩展，使用小的多个服务