文档章节

数据库分库分表(sharding)系列(四) 多数据源的事务处理

猪刚烈
 猪刚烈
发布于 2014/10/12 11:47
字数 1313
阅读 30
收藏 2
系统经sharding改造之后,原来单一的数据库会演变成多个数据库,如何确保多数据源同时操作的原子性和一致性是不得不考虑的一个问题。总体上看,目前对于一个分布式系统的事务处理有三种方式:分布式事务、基于Best Efforts 1PC模式的事务以及事务补偿机制。我们下面对这三种处理方式一一进行分析。本文原文链接: http://blog.csdn.net/bluishglc/article/details/7793172 转载请注明出处!

分布式事务

这是最为人们所熟知的多数据源事务处理机制。本文并不打算对分布式事务做过多介绍,读者可参考此文: 关于分布式事务、两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究 。在这里只想对分布式事务的利弊作一下分析。

优势:
1. 基于两阶段提交,最大限度地保证了跨数据库操作的“原子性”,是分布式系统下最严格的事务实现方式。
2. 实现简单,工作量小。由于多数应用服务器以及一些独立的分布式事务协调器做了大量的封装工作,使得项目中引入分布式事务的难度和工作量基本上可以忽略不计。
劣势:
系统“水平”伸缩的死敌。基于两阶段提交的分布式事务在提交事务时需要在多个节点之间进行协调,最大限度地推后了提交事务的时间点,客观上延长了事务的执行时间,这会导致事务在访问共享资源时发生冲突和死锁的概率增高,随着数据库节点的增多,这种趋势会越来越严重,从而成为系统在数据库层面上水平伸缩的"枷锁", 这是很多Sharding系统不采用分布式事务的主要原因。

基于Best Efforts 1PC模式的事务

与分布式事务采用的两阶段提交不同,Best Efforts 1PC模式采用的是一阶段端提交,牺牲了事务在某些特殊情况(当机、网络中断等)下的安全性,却获得了良好的性能,特别是消除了对水平伸缩的桎酷。 Distributed transactions in Spring, with and without XA一文对Best Efforts 1PC模式进行了详细的说明,该文提供的Demo代码更是直接给出了在Spring环境下实现一阶段提交的多数据源事务管理示例。不过需要注意的是,原示例是基于spring 3.0之前的版本,如果你使用spring 3.0+,会得到如下错误: java.lang.IllegalStateException: Cannot activate transaction synchronization - already active,如果使用spring 3.0+,你需要参考 spring-data-neo4j的实现。鉴于Best Efforts 1PC模式的性能优势,以及相对简单的实现方式,它被大多数的sharding框架和项目采用。

事务补偿机制

对于那些对性能要求很高,但对一致性要求并不高的系统,往往并不苛求系统的实时一致性,只要在一个允许的时间周期内达到最终一致性即可,这使得事务补偿机制成为一种可行的方案。事务补偿机制最初被提出是在“长事务”的处理中,但是对于分布式系统确保一致性也有很好的参考意义。笼统地讲,与事务在执行中发生错误后立即回滚的方式不同,事务补偿是一种事后检查并补救的措施,它只期望在一个容许时间周期内得到最终一致的结果就可以了。事务补偿的实现与系统业务紧密相关,并没有一种标准的处理方式。一些常见的实现方式有:对数据进行对帐检查;基于日志进行比对;定期同标准数据来源进行同步,等等。

小结


分布式事务,最严格的事务实现,但性能是个大问题;Best Efforts 1PC模式,性能与事务可靠性的平衡,支持系统水平伸缩,大多数情况下是最合适的选择;事务补偿机制,只能适用于对事务性要求不高,允许数据“最终一致”即可的系统,牺牲实时一致性,获得最大的性能回报。

相关阅读:

数据库分库分表(sharding)系列(五) 一种支持自由规划无须数据迁移和修改路由代码的Sharding扩容方案

数据库分库分表(sharding)系列(四) 多数据源的事务处理

数据库分库分表(sharding)系列(三) 关于使用框架还是自主开发以及sharding实现层面的考量

数据库分库分表(sharding)系列(二) 全局主键生成策略

数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示

关于垂直切分Vertical Sharding的粒度

数据库Sharding的基本思想和切分策略



本文转载自:http://blog.csdn.net/bluishglc/article/details/7793172

共有 人打赏支持
猪刚烈
粉丝 22
博文 708
码字总数 110
作品 1
海淀
程序员
数据库分库分表(sharding)系列(四) 多数据源的事务处理

系统经sharding改造之后,原来单一的数据库会演变成多个数据库,如何确保多数据源同时操作的原子性和一致性是不得不考虑的一个问题。总体上看,目前对于一个分布式系统的事务处理有三种方式:...

bluishglc
2012/07/27
0
0
关于垂直切分Vertical Sharding的粒度

垂直切分的粒度指的是在做垂直切分时允许几级的关联表放在一个shard里.这个问题对应用程序和sharding实现有着很大的影响. 关联打断地越多,则受影响的join操作越多,应用程序为此做出的妥协...

bluishglc
2011/03/24
0
0
数据库Sharding的基本思想和切分策略

本文着重介绍sharding的基本思想和理论上的切分策略,关于更加细致的实施策略和参考事例请参考我的另一篇博文:数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示 一、基本思想 Shar...

bluishglc
2011/01/24
0
0
数据库分库分表(sharding)系列(二) 全局主键生成策略

本文将主要介绍一些常见的全局主键生成策略,然后重点介绍flickr使用的一种非常优秀的全局主键生成方案。关于分库分表(sharding)的拆分策略和实施细则,请参考该系列的前一篇文章:数据库分库...

bluishglc
2012/07/03
0
0
数据库分库分表(sharding)系列(三) 关于使用框架还是自主开发以及sharding实现层面的考量

当团队对系统业务和数据库进行了细致的梳理,确定了切分方案后,接下来的问题就是如何去实现切分方案了,目前在sharding方面有不少的开源框架和产品可供参考,同时很多团队也会选择自主开发实...

bluishglc
2012/07/20
0
0

没有更多内容

加载失败,请刷新页面

加载更多

macOs-挂载能读写的NTFS硬盘

转自:https://nicklinyi.gitee.io/blog/2018/04/macOS-ntfs.html Mac本身是支持NTFS写入的,只是NTFS是微软开发,由于版权和技术细节原因,苹果不愿公开说自己支持NTFS写入,也是有自己以后...

北风刮的不认真了
32分钟前
2
0
Namespace 命名空间

命名空间可以定义为一种封装方式。 为了解决开发中库和程序中可重用类和方法问题: 1.解决 PHP内部方法类/方法/常量 或者第三方 类/方法/常量之间的命名冲突 2.能够简化为了防止命名冲突而给...

忙碌的小蜜蜂
34分钟前
1
0
CDH的坑之Deploy Client Configuration Failed

Deploy Client Configuration Failed 1.问题描述 当使用CDH增添spark服务的时候,出现了以下错误: Faile to deploy client configuration to the cluster. 具体如下图: 2.思路 网上查了...

星汉
35分钟前
2
0
java guava 集合的操作:交集、差集、并集

Guava:google的工程师利用传说中的“20%时间”开发的集合库,它是对jdk提供的扩展,提供了很多实用的类来简化代码。 开源地址:https://github.com/google/guava jar包下载:http://maven....

帅的不像男的
36分钟前
3
0
从八个层面比较分析 Java 8, RxJava, Reactor

响应式编程在单机环境下是否鸡肋? 结论是:没有结论,我觉得只能抱着怀疑的眼光审视这个问题了。另外还聊到了 RSocket 这个最近在 SpringOne 大会上比较火爆的响应式”新“网络协议,githu...

小刀爱编程
39分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部