atomikos

TCC介绍 TCC概念由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出，在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。 正式以Try-Confirm-Cancel作为名称的是Atomikos公司。 认识TCC TCC区别于 XA事务 ，是一种用于分布式系统中跨服务的事务管理模型；此模型通过管理服务，而不是资源管理器实现。 TCC是一种补偿型事务，也是一种柔性事务（存在中间态），该模型要求应用服务提供 try、confirm、cancel 三个接口，分别对应资源预留、操作确认、操作取消业务逻辑。 在TCC模型中，如果事务可以提交，则完成对预留资源的确认（调用confirm），如果事务要回滚，则释放预留的资源（调用cancel）。 TCC中try、confirm、cancel接口需要考虑幂等。 TCC区别于XA模型以及JAVA中的JTA接口，主要依赖业务代码实现；不用考虑框架、资源管理器、通信协议的支持和规范。 TCC与XA对比 TCC中对资源的锁是基于业务代码实现（这里的锁意思就是try接口中的预留动作），而XA基于数据库的序列化隔离级别实现。 TCC可以解决XA中单点以及并发的问题

1、准备好mysql master/slave 环境。 2、自己打包部署： 自己打包，先下载 apache-shardingsphere-4.1.1-sharding-proxy-bin.tar.gz curl -O https://archive.apache.org/dist/shardingsphere/4.1.1/apache-shardingsphere-4.1.1-sharding-proxy-bin.tar.gz 解压后，如果连mysq8.0，需把 mysql-connector-java-8.0.15.jar 驱动包拷贝到 lib 下 [Dockfile] FROM openjdk:8-jre-slim MAINTAINER summer RUN ln -sf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone ADD apache-shardingsphere-4.1.1-sharding-proxy-bin /opt/sharding-proxy ENTRYPOINT ["/bin/sh","-c","/opt/sharding-proxy/bin/start.sh ${PORT} && tail -f /opt/sharding-proxy/logs/stdout.log"]

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

随着企业应用规模越来越大，为了满足业务增长的需求，几乎所有一线的互联网公司都会面临分布式场景，比如“618”，双11 大促，抢票，社群裂变等活动。 能否解决分布式业务问题，成为大厂面试时的重点考核内容。 然而，想把分布式掌握好并不是一蹴而就的，如果只是临时抱佛脚，草草记下一些概念就去应聘，稍一深入，就答不上来，结果可想而知。比如 现在实现分布式锁的技术方案就不少，那么面试官经常都会问到什么深度呢？ 下面列举几个问题，大家可以参考下： “ XA 规范有哪些优化措施？ 基于数据库实现分布式锁有哪些问题？ 使用Zookeeper实现分布式锁时，如何选择重试策略？” 正值暑期求职旺季， 不少朋友苦于搜集资料耗时耗力，很难 cover 住面试官的考核角度。为了能让大家在准备面试时少走弯路，这里特别推荐一个限时福利——开课吧历时三个月打造的 “分布式专题精品课” 内容对本公众号免费开放 5 天。 本次专题视频的讲师都源于国内知名互联网公司，花费了近三个月的时间，调研精选各大互联网企业真实业务场景和用人需求，经过多次迭代，最终形成了这套专题内容来帮助正在求职的朋友们。 听下来，你可以： 收获完整的分布式开发学习路径 在实际业务场景中理解分布式事务和锁的本质，并进行性能调优 吸收业界专家的经验分享，加速分布式技能进阶 加深分布式底层和核心技术的理解 轻松应对面试中分布式问题

1. 首先说下要解决的内容 1. 1 分布式：分布式session会话、分布式锁、分布式存储、分布式事务 1.2 集群：集群管理、负载均衡、熔断 2. 消息中间件：rocketMQ、rabbitMQ、KAFKA、HIVE MQ、zookeeper、ACTIVE MQ 3.提供分布式事务的：rocketMQ/SEATA SAGA/JTA(spring Atomikos)/mongodb 2PC （ Mongo4.2 ） 4.分布式锁：Redis/zookeeper 5. 分布式存储搭建：可以使用云提供的存储、无需要考虑自己扩展的问题，必须使用MongoDB的云，它既提供了分布式事务，当然也提供了我们分布式存储的功能，当然如果往大的分布式存储的方向考虑就是使用大数据的分布式存储HIVE 和 HBASE 6. 集群管理：zookeeper，SPRING EUREKA 7. RPC调用: DUBBO、NETTY 、RMI(JAVA)/SPRING FEIGN、 8、 负载: NGINX 、 RIBBON 、 ZOOKEEPER , 基本上在中间件里都具备这些负载， 所以重点应该关注负载的一些基础原理： 9. 熔断/容错机制：既然在分布式中的各个中间件都是标榜给分布式带来高可用，就无比在每个中间件学习他们的熔断或者容错机制！ 1. IP HASH 定向负载 2. 轮询 3. 随机负载 4.

前言 多数据源的事务处理是个老生常谈的话题，跨两个数据源的事务管理也算是分布式事务的范畴，在同一个JVM里处理多数据源的事务，比较经典的处理方案是JTA(基于XA协议建模的java标准事务抽象)+XA(XA事务协议)，常见的JTA实现框架有Atomikos、Bitronix、Narayana，Spring对这些框架都有组件封装，基本可以做到开箱即用程度。本文除了分享XA事务方案外，提供了一种新的多数据源事务解决思路和视角。 问题背景 在解决mysql字段脱敏处理时，结合sharding-jdbc的脱敏组件功能，为了sql兼容和最小化应用改造，博主给出了一个多数据源融合的字段脱敏解决方案（只把包含脱敏字段表的操作走sharding-jdbc脱敏代理数据源）。这个方案解决了问题的同时，带来了一个新的问题，数据源的事务是独立的，正如我文中所述 《JPA项目多数据源模式整合sharding-jdbc实现数据脱敏》 ,在spring上下文中，每个数据源对应一个独立的事务管理器，默认的事务管理器的数据源就用业务本身的数据源，所以需要加密的业务使用时，需要指定@Transactional注解里的事务管理器名称为脱敏对应的事务管理器名称。简单的业务场景这样用也就没有问题了，但是一般的业务场景总有一个事务覆盖两个数据源的操作，这个时候单指定哪个事务管理器都不行，so，这里需要一种多数据源的事务管理器

两阶段提交协议（Two-phase Commit，2PC）经常被用来实现分布式事务。一般分为协调器C和若干事务执行者Si两种角色，这里的事务执行者就是具体的数据库，协调器可以和事务执行器在一台机器上。 我们的应用程序（client）发起一个开始请求到TC； TC先将<prepare>消息写到本地日志，之后向所有的Si发起<prepare>消息。以支付宝转账到余额宝为例，TC给A的prepare消息是通知支付宝数据库相应账目扣款1万，TC给B的prepare消息是通知余额宝数据库相应账目增加1w。为什么在执行任务前需要先写本地日志，主要是为了故障后恢复用，本地日志起到现实生活中凭证 的效果，如果没有本地日志（凭证），出问题容易死无对证； Si收到<prepare>消息后，执行具体本机事务，但不会进行commit，如果成功返回<yes>，不成功返回<no>。同理，返回前都应把要返回的消息写到日志里，当作凭证。 TC收集所有执行器返回的消息，如果所有执行器都返回yes，那么给所有执行器发生送commit消息，执行器收到commit后执行本地事务的commit操作；如果有任一个执行器返回no，那么给所有执行器发送abort消息，执行器收到abort消息后执行事务abort操作。 注：TC或Si把发送或接收到的消息先写到日志里，主要是为了故障后恢复用。如某一Si从故障中恢复后

TCC方案是可能是目前最火的一种柔性事务方案了。关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司，其注册了TCC商标。 国内最早关于TCC的报道，应该是InfoQ上对阿里程立博士的一篇采访。经过程博士的这一次传道之后，TCC在国内逐渐被大家广为了解并接受。 Atomikos公司在商业版本事务管理器ExtremeTransactions中提供了TCC方案的实现，但是由于其是收费的，因此相应的很多的开源实现方案也就涌现出来，如：tcc-transaction、ByteTCC、spring-cloud-rest-tcc。 TCC的作用主要是解决跨服务调用场景下的分布式事务问题，在本文中，笔者将先介绍一个跨服务的场景案例，并分析其中存在的分布式事务问题；然后介绍TCC的基本概念以及其是如何解决这个问题的。 场景案例 Atomikos官网上<<Composite Transactions for SOA>>一文中