Sharding Sphere 与 Lcn事务区别
Sharding Sphere
http://shardingsphere.apache.org/index_zh.html
两阶段事务-XA
两阶段事务提交采用的是X/OPEN组织所定义的DTP模型，通过抽象出来的AP, TM, RM的概念可以保证事务的强一致性。 其中TM和RM间采用XA的协议进行双向通信。 与传统的本地事务相比，XA事务增加了prepare阶段，数据库除了被动接受提交指令外，还可以反向通知调用方事务是否可以被提交。 因此TM可以收集所有分支事务的prepare结果，最后进行原子的提交，保证事务的强一致性。
Java通定义JTA接口实现了XA的模型，JTA接口里的ResourceManager需要数据库厂商提供XA的驱动实现，而TransactionManager则需要事务管理器的厂商实现，传统的事务管理器需要同应用服务器绑定，因此使用的成本很高。 而嵌入式的事务管器可以已jar包的形式提供服务，同ShardingSphere集成后，可保证分片后跨库事务强一致性。
通常，只有使用了事务管理器厂商所提供的XA事务连接池，才能支持XA的事务。ShardingSphere整合XA事务时，分离了XA事务管理和连接池管理，这样接入XA时，可以做到对业务的零侵入。
SAGA柔性事务
Saga事务
为了更好地理解柔性事务的设计思路，需要先解释数个概念：
- 分支事务(BranchTransaction)： 分布式事务中，被路由到不同节点的实际SQL。
- 分支事务组(BranchTransactionGroup)： 分布式事务中，由同一个逻辑SQL生成的分支事务的组合。
当ShardingSphere对SQL进行解析时，事务引擎会将当前事务切换到新的分支事务组。 在开始并行执行路由后的实际SQL前，事务引擎会对这些SQL进行快照并注册对应分支事务到当前的分支事务组中。 当事务中所有的SQL均被解析并执行后，事务中可能存在数个分支事务组，每个分支事务组中也可能存在数个分支事务，如下图：
支持功能
本地事务
功能
完全支持非跨库事务，例如：仅分表，或分库但是路由的结果在单库中。
完全支持因逻辑异常导致的跨库事务。例如：同一事务中，跨两个库更新。更新完毕后，抛出空指针，则两个库的内容都能回滚。
不支持因网络、硬件异常导致的跨库事务。例如：同一事务中，跨两个库更新，更新完毕后、未提交之前，第一个库宕机，则只有第二个库数据提交。
支持情况
- Sharding-JDBC和Sharding-Proxy原生支持本地事务
两阶段事务-XA
功能
- 支持数据分片后的跨库XA事务
- 两阶段提交保证操作的原子性和数据的强一致性
- 服务宕机重启后，提交/回滚中的事务可自动恢复
- SPI机制整合主流的XA事务管理器，默认Atomikos，可以选择使用Narayana和Bitronix
- 同时支持XA和非XA的连接池
- 提供spring-boot和namespace的接入端
不支持项
- 服务宕机后，在其它机器上恢复提交/回滚中的数据
最后当用户提交事务时，Saga引擎按照分支事务组的顺序，使用其中分支事务的路由SQL进行重试或反向SQL进行回滚。
柔性事务
功能
- 完全支持跨库事务
- 支持失败SQL重试及最大努力送达
- 支持反向SQL、自动生成更新快照以及自动补偿
- 默认使用关系型数据库进行快照及事务日志的持久化，支持使用SPI的方式加载其他类型的持久化
不支持项
- 暂不支持资源隔离
- 暂不支持服务宕机后，自动恢复提交中的commit和rollback
支持情况
ShardingSphere的柔性事务已通过第三方SPI实现Saga事务，Saga引擎使用Servicecomb-Saga。
注意
- 反向SQL需要主键，请确保在表结构中定义主键。
- 对于
INSERT语句， 需要在SQL中显示插入主键值，如INSERT INTO ${table_name} (id, value, ...) VALUES (11111, '', ....) (其中id为表主键)。 - 若需要自动生成主键，可使用ShardingSphere的分布式主键（分布式主键不能为联合主键）。
实现原理
实现原理
ShardingSphere里定义了分布式事务的SPI接口ShardingTransactionManager，Sharding-JDBC和Sharding-Proxy为分布式事务的两个接入端。XAShardingTransactionManager为分布式事务的XA实现类，通过引入sharding-transaction-xa-core依赖，即可加入ShardingSphere的分布式事务生态中。XAShardingTransactionManager主要负责对actual datasource进行管理和适配，并且将接入端事务的begin/commit/rollback操作委托给具体的XA事务管理器。
处理流程
1. begin
通常收到接入端的set autoCommit=0时，XAShardingTransactionManager会调用具体的XA事务管理器开启XA的全局事务，通常以XID的形式进行标记。
2. SQL执行
ShardingSphere进行解析/优化/路由后，会生成逻辑SQL的分片SQLUnit，执行引擎为每个物理SQL创建连接的同时，物理连接所对应的XAResource也会被注册到当前XA事务中，事务管理器会在此阶段发送XAResource.start命令给数据库，数据库在收到XAResource.end命令之前的所有SQL操作，会被标记为XA事务。
例如:
XAResource1.start -- enlist阶段执行
statement.execute("sql1");
statement.execute("sql2");
XAResource1.end -- 提交阶段执行
这里sql1和sql2将会被标记为XA事务。
3. commit/rollback
XAShardingTransactionManager收到接入端的提交命令后，会委托实际的XA事务管理进行提交动作，这时事务管理器会收集当前线程里所有注册的XAResource，首先发送XAResource.end指令，用以标记此XA事务的边界。 接着会依次发送prepare指令，收集所有参与XAResource投票，如果所有XAResource的反馈结果都是OK，则会再次调用commit指令进行最终提交，如果有一个XAResource的反馈结果为No，则会调用rollback指令进行回滚。 在事务管理器发出提交指令后，任何XAResource产生的异常都会通过recovery日志进行重试，来保证提交阶段的操作原子性，和数据强一致性。
例如:
XAResource1.prepare -- ack: yes
XAResource2.prepare -- ack: yes
XAResource1.commit
XAResource2.commitXAResource1.prepare -- ack: yes
XAResource2.prepare -- ack: no
XAResource1.rollback
XAResource2.rollback
柔性事务
设计
ShardingSphere的柔性事务需要实现Sharding事务管理器的SPI接口，用于管理事务的生命周期。 同时柔性事务还需要通过ShardingSphere的内部SQL Hook，获取与SQL相关的必要信息，帮助事务管理器控制分布式事务。 事务隔离引擎还处于计划阶段，因此柔性事务暂不支持资源隔离功能。
TX-LCN分布式事务框架
官方地址：http://www.txlcn.org/zh-cn/index.html
入门
随着互联化的蔓延，各种项目都逐渐向分布式服务做转换。如今微服务已经普遍存在，本地事务已经无法满足分布式的要求，由此分布式事务问题诞生。 分布式事务被称为世界性的难题，目前分布式事务存在两大理论依据：CAP定律 BASE理论。
CAP定律
这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
一致性（C）
在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容错性（P）
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：
（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
背景
LCN框架在2017年6月份发布第一个版本，从开始的1.0，已经发展到了5.0版本。
LCN名称是由早期版本的LCN框架命名，在设计框架之初的1.0 ~ 2.0的版本时框架设计的步骤是如下,各取其首字母得来的LCN命名。
锁定事务单元（lock）
确认事务模块状态(confirm)
通知事务(notify)
5.0以后由于框架兼容了LCN、TCC、TXC三种事务模式，为了避免区分LCN模式，特此将LCN分布式事务改名为TX-LCN分布式事务框架。
框架定位
LCN并不生产事务，LCN只是本地事务的协调工
TX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。
解决方案
在一个分布式系统下存在多个模块协调来完成一次业务。那么就存在一次业务事务下可能横跨多种数据源节点的可能。TX-LCN将可以解决这样的问题。
例如存在服务模块A 、B、 C。A模块是mysql作为数据源的服务，B模块是基于redis作为数据源的服务，C模块是基于mongo作为数据源的服务。若需要解决他们的事务一致性就需要针对不同的节点采用不同的方案，并且统一协调完成分布式事务的处理。
方案：
若采用TX-LCN分布式事务框架，则可以将A模块采用LCN模式、B/C采用TCC模式就能完美解决。
事务控制原理
TX-LCN由两大模块组成, TxClient、TxManager，TxClient作为模块的依赖框架，提供TX-LCN的标准支持，TxManager作为分布式事务的控制放。事务发起方或者参与反都由TxClient端来控制。
原理图:
核心步骤
创建事务组
是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。加入事务组
添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。通知事务组
是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。
LCN事务模式
一、原理介绍:
LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。
二、模式特点:
- 该模式对代码的嵌入性为低。
- 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。
- 该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。
- 该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。
TCC事务模式
一、原理介绍:
TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。
二、模式特点:
- 该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。
- 该模式对有无本地事务控制都可以支持使用面广。
- 数据一致性控制几乎完全由开发者控制，对业务开发难度要求高。
TXC事务模式
一、原理介绍：
TXC模式命名来源于淘宝，实现原理是在执行SQL之前，先查询SQL的影响数据，然后保存执行的SQL快走信息和创建锁。当需要回滚的时候就采用这些记录数据回滚数据库，目前锁实现依赖redis分布式锁控制。
二、模式特点:
- 该模式同样对代码的嵌入性低。
- 该模式仅限于对支持SQL方式的模块支持。
- 该模式由于每次执行SQL之前需要先查询影响数据，因此相比LCN模式消耗资源与时间要多。
- 该模式不会占用数据库的连接资源。
Sharding Sphere 与 Lcn事务区别相关推荐
- 巨杉数据库TechDay回顾 | 分布式数据库@民生、Sharding Sphere@京东、ClickHouse@微博
大数据时代,数据早已成为全球战略资源级的存在,数据库也成为了所有应用成功运行的核心.同时,随着创新业务的不断增加,业务的复杂及庞大的体量必然会产生错综复杂且规模巨大的结构化数据,这些都迫使企业对数据库 ...
- 实现数据“一键脱敏”，Sharding Sphere帮你搞定
以下文章来源方志朋的博客,回复"666"获面试宝典 在真实业务场景中,数据库中经常需要存储某些客户的关键性敏感信息如:身份证号.银行卡号.姓名.手机号码等,此类信息按照合规要求,通 ...
- 基于Sharding Sphere实现数据“一键脱敏”
以下文章来源方志朋的博客,回复"666"获面试宝典 来源:https://jaskey.github.io/blog/2020/03/18/sharding-sphere-data ...
- 敏感数据，“一键脱敏”，Sharding Sphere 完美搞定
来源:https://jaskey.github.io/blog/2020/03/18/sharding-sphere-data-desensitization/Jaskey Lam 在真实业务场景中 ...
- Sharding Sphere实现数据“一键脱敏”
痛点一: 通常的解决方案是我们书写SQL的时候,把对应的加密字段手动进行加密再进行插入,在查询的时候使用之前再手动进行解密.此方法固然可行,但是使用起来非常不便捷且繁琐,使得日常的业务开发与存储合规的 ...
- Sharding Sphere ~ Sharding-jdbc分库分表、读写分离
Sharding Sphere 是什么? 1.一套开源的分布式数据库中间件解决方案 2.有三个产品:Sharding-JDBC 和 Sharding-Proxy 3.定位为关系型数据库中间件,合理在分 ...
- Sharding Sphere
Sharding Sphere 来源(尚硅谷 哔哩哔哩_bilibili)总结 1.什么是Sharding Sphere 1.一套开源的分布式数据库中间件解决方案 2.有三个产品:Sharding-J ...
- 事务声明声明式事务和编程式事务区别
事务声明声明式事务和编程式事务区别 1.编程式事务: 所谓编程式事务指的是通过编码方式实现事务,即类似于JDBC编程实现事务管理.管理使用TransactionTemplate或者直接使用底层的Pla ...
- 【Docker、Sharding Sphere】Docker安装Sharding Sphere Proxy-5.0.0
一.官方相关文档介绍 快速入门 | Docker镜像 二.安装 1.拉取官网镜像 docker pull apache/shardingsphere-proxy 2.获取/conf中的配置到本地路径, ...
最新文章
- MySQL数据库基本操作总结(不断更新中......)
- SpringBoot_定制banner
- Windows 程序员必备的知识和工具
- yii引入php文件,Yii2框架中CSS、JS文件引入要领_PHP开发框架教程
- 142. Leetcode 93. 复原 IP 地址 (回溯算法-切割问题)
- list index out of bounds_python3基础03列表（list）和元组（tuple）
- c++中int向量初始化_以不同的方式在C ++中初始化2D向量
- 国家邮政局公布一项数据 春节期间快递数量依旧很猛！
- rj45管脚定义_rj45接口定义,rj45插座引脚定义
- Django 安装使用
- Linux Irq domain
- 微信小程序微商城（十）：用户收货地址管理
- GeoServer发布shp数据
- php读取excel显示,PHP读取Excel并展示实现代码
- Python Flask接口开发
- 线程池的使用和工作原理
- 站在物联网风口 中兴着力构建GIA 的IoT新生态
- 69、Android获取每日运动步数
- 火了，新东方年会吐槽视频《释放自我》：累死累活干不过写PPT的
- iOS 苹果开发者账号协议和付费条款同意过程