分布式事务一致性实现的方式总结

  因为最近项目正在做重构,而这次重构实质上比原来更接近于SOA化和微服务的思想。对于我们金融交易来说,数据结果的准确性是重中之重。所以今天总结一下分布式事务的实现方法,下次组内周会给大家统一一下概念。

刚性事务和柔性事务

  刚性事务:严格遵循ACID原则(原子性、一致性、隔离性、持久性)的事务。基本上指的是本地数据库事务。根据CAP原则,分布式下的事务都不是刚性事务。

  柔性事务:遵循CAP理论或者其变种BASE理论的事务。分布式事务基本上都是柔性事务。

  因为刚性事务基本上等价于本地数据库事务,而柔性事务基本上等价于分布式事务。只是一个是按照事务严格性来区分,一个是按使用场景来区分。所以平时除了用来做对比,很少直接提刚性事务和柔性事务的概念。

分布式事务理论

  分布式事务:在分布式环境下,各个操作步骤并不在同一台机器上,需要保证所有动作都有一个统一的结果的一组操作。

  CAP原则(记得在之前的博客中多次写过):分布式环境下,数据一致性、服务可用性、分区容错性三者最多只能满足其中二者。

    数据一致性(consistency):这里的一致性是强一致性,又叫线性一致性。即一个写操作成功,而读出的必须是写操作后的新数据。而写操作失败读出的必须是写操作前的旧数据。

    服务可用性(availability):所有的操作在一定时间内都能得到响应。

    分区容错性(partition-tolerance):在网络分区环境下,被分割的节点仍然能对外提供服务。

选    择

说    明

AP

分隔的节点同时对外服务但不能相互通信,将导致状态不一致,即不能满足C

CP

网络分区的情况下为达成C,请求只能一直等待,即不满足A

CA

在一定时间内要达到节点状态一致,要求不能出现网络分区,则不能满足P

  BASE理论:这是基于CAP理论权衡之后的结果。核心思想是即使无法做到强一致性,但可以使用一些技术手段达到最终一致。BASE是Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)的缩写。

分布式事务一致性实现方案

  为了解决分布式一致性问题,前人在性能和数据一致性的权衡过程中总结了许多经典的协议和算法。比较著名的有:2PC、3PC、TCC、Paxos、Raft、Zab、ISR。除了这些之外,业界用的最多的其实是基于MQ实现的。

  2PC(Two Phase Commit)两阶段提交:一般说的两阶段提交是基于XA协议的。另外JTA协议的也比较常见。

  XA是一个分布式事务协议。它大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Oracle、DB2都实现了XA接口。MySQL对XA的支持不是很好。而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

   两阶段提交的优点是:原理简单、实现方便。缺点是同步阻塞、单点问题、数据不一致。

  3PC(Three Phrase Commit)三阶段提交:分为CanCommit、PreCommit、Do Commit 三个阶段。就是把两阶段提交的Phase 1分成两个,预提交的时候如果有参与者返回No或者超时则中断事务。

  三阶段提交的优点是降低参与者阻塞范围,并能够在出现单点故障后继续达成一致。缺点是因为preCommit阶段,在这个阶段如果出现网络分区,协调者无法与参与者正常通信,参与者仍然会进行实物提交,造成数据不一致。

  TCC(Try-Confirm-Cancel)

    Try:完成所有的检查,预留必须资源

    Confirm:使用Try阶段预留的资源执行业务,如果执行出现异常,要重试

    Cancel:释放Try阶段预留资源

    TCC能够对分布式事务中的各个资源进行分别锁定,分别提交与释放。适用于严格一致、执行时间短、实时性要求高的场景。

  Paxos算法:之前看过《从Paxos到Zookeeper》那本书,没怎么看明白。实现比较复杂,Zookeeper就是用这个来实现的分布式一致性。Paxos算法、Raft协议和Zab(Zookeeper Atomic Broadcast)协议都是一种通过多数投票来保证主备数据一致性的。

  ISR(In-Sync Replicas)机制:Kafka使用了这个机制来保证数据一致性。ISR认为对于2f+1个副本来说,多数投票机制要求最多只能允许f个副本发生故障,如果要支持2个副本的容错,则需要至少维持5个副本。

  基本MQ实现是一种异步确保型的实现方案。将同步阻塞的事务变成异步的,避免了对数据库事务的争用。

跑题时间:

  咖啡就像是有毒的爱情,入口香滑,然后就是心力交瘁、辗转难眠,远离咖啡~

  坚强是最容易的事情,当自己想哭的时候,却发现没有一个肩膀可以靠着哭,就只能将眼泪强忍回去,笑着走进来~

  我最爱的人是我的“生死劫”。一生的最爱也是一生的最坏。当我心怀执念淌过绝情池水,伤痕累累的来到断念的彼岸。我仍然感激上苍安排的一切。如果有来世,我依然会相信爱,只是再也不要爱上你~

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师之旅

高可用可伸缩架构实用经验谈

 移动互联网、云计算和大数据的成熟和发展,让更多的好想法得以在很短的时间内实现为产品。此时,如果用户需求抓得准,用户数量将很可能获得爆发式增长,而不需要像以往一...

1807
来自专栏沃趣科技

基于Oracle的私有云架构探析(连载三)@【DTCC干货分享】

• 启用Instance Caging Instance Caging 通过设置2个数据库的初始化参数来达到管控CPU的目的: • cpu_count ...

3495
来自专栏Java架构沉思录

从一笔金币充值去思考分布式事务

考虑支付重构的时候,自然想到原本属于一个本地事务中的处理,现在要跨应用了要怎么处理。拿充值订单举个栗子吧,假设:原本订单模块和账户模块是放在一起的,现在需要做服...

523
来自专栏架构师之路

集群信息管理,架构设计中最容易遗漏的一环

准备系统性介绍“技术体系规划”了,这是第一篇。 监控平台,服务治理,调用链跟踪,数据收集中心,自动化运维,自动化测试… 很多要讲,却没想好从哪里入手。 讲Z平台...

3786
来自专栏吴伟祥

认识消息队列(一) 转

业务无关,一个具有普适性质的消息队列组件不需要考虑上层的业务模型,只做好消息的分发就可以了,上层业务的不同模块反而需要依赖消息队列所定义的规范进行通信。

361
来自专栏大魏分享(微信公众号:david-share)

容器的存储和网络开源方案该咋选?

容器存储的选择 时至今日,企业客户运行容器的,编排工具大多数选择K8S。 因此,我们先到社区里看看,目前K8S支持的持久存储,其实也就是PV支持的存储类型。 ...

3584
来自专栏腾讯云TStack专栏

PGXZ 的架构揭秘

本文将重点介绍 PGXZ,作为 TStack 平台重要的数据库产品能力,用户可在云端轻松设置、操作,且无需负责基础运维工作,以及为灾难恢复而进行的数据备份。

1K2
来自专栏CSDN技术头条

腾讯大规模Hadoop集群实践

TDW(Tencent distributed Data Warehouse,腾讯分布式数据仓库)基于开源软件Hadoop和Hive进行构建,打破了传统数据仓库...

3797
来自专栏架构师之路

“配置”也有架构演进?看完深有痛感

一、缘起 随着互联网业务的越来越复杂,用户量与流量越来越大,“服务化分层”是架构演进的必由之路。 ? 如上图:站点应用会调用服务,上游服务调用底层服务,依赖关系...

3695
来自专栏Java架构沉思录

微服务架构下静态数据通用缓存机制

在分布式系统中,特别是最近很火的微服务架构下,有没有或者能不能总结出一个业务静态数据的通用缓存处理机制或方案,这篇文章将结合一些实际的研发经验,尝试理清其中存在...

632

扫码关注云+社区