分布式系统架构系列讲解十二（分布式事物 2）：3PC

最新推荐文章于 2021-12-02 11:10:16 发布
最新推荐文章于 2021-12-02 11:10:16 发布
阅读量162 收藏
点赞数 1
分类专栏： 分布式系统架构系列讲解 文章标签： 分布式事物3PC 3PC 三阶段提交
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u013277209/article/details/115233741
版权

分布式系统架构系列讲解 - 总目录

一、简介

在二阶段协议中，事务参与者在投票阶段，如果同意提交事务，则会锁定资源，此时任何其他访问该资源的请求将处于阻塞状态。

正因为这个原因，三阶段协议（Three-phase commit protocol, 3PC）对二阶段协议进行了改进：

  • 一方面引入超时机制，解决资源阻塞问题；

  • 另一方面新增一个询问阶段（CanCommit），提前确认下各个参与者的状态是否正常。

在这里插入图片描述

二、协议详解

我们先来看下三阶段提交协议的成功场景：

了解本专栏 订阅专栏 解锁全文 超级会员免费看
吃透Java
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
订阅专栏
分布式系统架构
03-01
终于到了时下讨论最热门的分布式系统架构了，现在各大公司无论是大公司还是小公司都会提及使用分布式系统架构来构建xxx系统，还有PasS平台这些概念的出现，可以说分布式系统架构是现在最热门的技术话题了。...
分布式事物（2PC，3PC，CAP，柔性与刚性事物，LCN）
dayformyjob
09-03 1509
转载自  https://blog.csdn.net/lizhen1114/article/details/80110317 分布式事物解决方案 分布式事物产生原因:主要产生与在微服务系统中，数据库的垂直拆分或者是RPC远程调用， 不在同一个数据源中，而是多个数据源中，每个数据源的事物都是本地事物，互不影响。 所以当A服务的数据源的事物发生回滚，不会影响到B服务的数据源回滚，从而产生分布式...
Windows内核之系统架构
活下去,学下去
12-02 3642
一.架构概述 下图显示了Windows的基本结构。Windows采用双模式来保护操作系统本身，以避免被应用程序的错误所波及。操作系统核心运行在内核模式下，应用程序的代码运行在用户模式下。每当应用程序需要用到系统内核或内核的扩展模块（内核驱动程序）所提供的服务时，应用程序通过硬件指令从用户模式切换到内核模式中；当系统内核完成了所请求的服务以后，控制权又回到了用户模式代码。 在Windows中，用户代码和内核代码有各自的运行环境，而且它们可以访问的内存空间也不相同。在32位系统中，内核代码可以访问当前进
PC架构系列：CPU/RAM/IO总线的发展历史！
白日放歌须纵酒，青春作伴好还乡。
11-16 1万+
 1. 从 IBM PC XT 架构开始...一开始PC的设计中，CPU/RAM/IO都是被一条总线（BUS）连接起来，所有的部件都必须在同步的模式下面工作，由CPU来决定的其他设备工作在什么频率（Frequency）上。这样就带来一个"互锁" （locked to each other ）效应，即大家都被限定在一个被所有设备所能承受的通用时钟频率（Clock Frequency）上面，系统的整体
Dubbo分布式系统架构实战视频教程
07-04
文件是网盘链接地址，2018.7.4上传，链接一直可用 本套视频为dubbo分布式系统架构实战教学视频
分布式系统架构的基本原则和实践
02-21
因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强...
Hadoop分布式文件系统：架构和设计
02-26
Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodityhardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错...
分布式系统架构系列讲解八（分布式一致性 8）：PBFT算法
热门推荐
吃透Java
06-15 2万+
Leslie Lamport在论文中提出的口信消息解决方案就属于BFT，需要考虑恶意节点的篡改、攻击等问题。但是，口信消息解决方案在现实场景中很难落地。比如，它并不关心这个共识的结果是什么，这会出现一种情况：现在适合进攻，但将军们达成的共识却是撤退。 另外，实际场景中，我们往往需要就提议的一系列值（而不是单值）在拜占庭错误发生的时候，也能被达成共识。那应该怎么做呢？一种方案就是本文要讲解的PBFT算法。PBFT算法，是一种能在实际场景中落地的BFT算法，它在区块链中应用广泛。 一、oral message的
分布式系统架构系列讲解九（分布式一致性 9）：PoW算法
吃透Java
06-16 1775
谈起比特币，大家至少都应该有所耳闻吧？比特币是基于区块链实现的，而区块链运行在Internet上，这就存在有人试图作恶的情况。 前面几章，我提到的口信消息解决方案和PBFT算法，虽然能防止坏人作恶，但只能防止少数，也就是 (n-1)/3 个坏人 (其中 n 为节点数)。可由于很多区块链是在公网环境，可能有坏人不断增加节点数，轻松突破 (n - 1) / 3 的限制。 解决上述问题的方法就是PoW算法。PoW算法通过工作量证明（Proof of Work）增加了坏人作恶的成本，以此防止坏人作恶。本章，我就来讲
分布式系统架构系列讲解一（分布式一致性 1）：CAP理论
吃透Java
03-23 1388
集中式应用进行服务化拆分后，必然会出现一个问题：如何保证各个节点（Node）之间的数据一致性？ 比如以下场景：用户首先发起一次更新操作，映射到节点A；然后，用户又做了一次查询操作，操作映射到了节点B，此时A和B的数据如果不一致，对用户来说就会造成困扰。 分布式系统为了提高可用性，必然会引入冗余机制（副本），而冗余便带来了上面描述的一致性问题。为了解决这类问题，加州大学伯克利分校的Eric Brewer [https://en.wikipedia.org/wiki/Eric_Brewer_(scientist
分布式系统架构系列讲解三十一（可扩展 3）：全局流水号
吃透Java
04-02 1160
一、简介 在数据分片中，不管是普通hash、一致性hash还是range based，都要基于某个key进行hash运算，然后根据计算值进行分片。 Key一般采用基于记录的特征值，这个特征值在不同的框架中有不同的叫法，比如MongoDB中的sharding key (https://docs.mongodb.com/manual/core/sharding-shard-key/)，Oracle中的Partition Key(https://docs.oracle.com/cd/B28359_01/serve
分布式系统架构系列讲解 - 总目录
吃透Java
03-30 878
本专栏详细介绍分布式系统架构，分为理论篇+实践篇！ 理论篇主要包括：分布式架构一致性，分布式事物，高可用，高性能，高扩展等展开。 实践主要包括：Spring Cloud方案，Dubbo服务治理，Redis集群，分布式锁，Kafka，Zookeeper，mq等方案。 预计文章将会达到六七十篇！ 一，理论篇 分布式一致性 分布式系统架构系列讲解（分布式一致性 1）：CAP理论 分布式系统架构系列讲解（分布式一致性 2）：BASE理论 分布式事物 分布式系统架构系列讲解（分布式事物 1）：2PC 分布式系统架构系
分布式系统架构系列讲解三十三（高可用 1）：Master-Slave
吃透Java
04-12 874
一、引言 分布式系统通常由大量异构的节点和网络组成，节点随时可能crash，网络也随时可能出现延迟、丢包、分区。相比集中式应用，分布式系统放大了出故障的概率，因此分布式系统的其中一个实现目标就是高可用，高可用意味着系统必须具有较强的容错性，即在部分节点故障的情况下仍然能正常对外提供服务。 分布式系统实现高可用的方式有很多，常见的主要有以下几种： Master-Slave（包括主备、主从、主主） 集群 熔断 降级 限流 Master-Slave、集群的本质都是冗余。熔断、降级、限流则从另一个维度——系统内
分布式系统架构系列讲解三（分布式一致性 3）：共识问题
吃透Java
04-22 675
共识问题是分布式领域最复杂的一个容错模型，只有搞懂它，你才能掌握常用的各种共识算法，才能在设计分布式系统时，根据业务场景的特点选择适合的算法。 那么，什么是共识问题呢？ 简单的讲，共识问题就是分布式系统需要解决的一个核心问题：在一个可能发生机器宕机、网络异常、数据篡改的环境下，如何让分布式系统中的所有节点快速准确的对某个数据值达成一致，且不会破坏整个系统的一致性。 Leslie Lamport曾在论文《 The Byzantine Generals Problem》（https://www.microsof
分布式系统架构系列讲解七（分布式一致性 7）：Quorum NWR算法
吃透Java
06-11 601
CAP理论中的一致性一般指的是强一致性，也就是说写操作完成后，任何后续访问都能读到更新后的值。而BASE理论中的一致性指的是最终一致性，也就是说写操作完成后， 任何后续访问可能会读到旧数据，但是整个分布式系统的数据最终会达到一致。 那么，如果我们的系统现在是最终一致性模型，也就是AP模型，突然有一天因为业务需要，要临时保证节点间的数据强一致性，有没有办法临时做这样的改造呢？ 一种办法是重新开发一套系统，但显然成本太高了。另一种办法就是本章要介绍的Quorum NWR算法。通过 Quorum NWR，我们可以
分布式系统架构系列讲解十五（分布式事物实战 5）：消息队列+定时任务+本地事件表
吃透Java
04-06 580
一，项目背景 在系统模块中，非常重要得一块是支付模块，当app调用第三方支付接口支付成功后，第三方平台会回调到我们后台模块，我们后台模块如果把支付模块和订单模块分开得话，那么此时就应该考虑分布式事物！ 下面我们以 ActiveMQ+定时任务+本地事物表，来实现此场景下得分布式事物！ 注意：此场景可以应用在中小型系统中，不适用数据量特别大得系统中，大型系统场景中得实战我们后面会讲到 二，架构原理 第三方系统回调到支付模块中，更新支付系统中的流水记录表，并插入本地事件表，设置event_type状态为new
分布式系统架构系列讲解六（分布式一致性 6）：Gossip协议
吃透Java
06-10 547
Gossip 协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。 根据 Base 理论，如果你需要实现最终一致性，那么就可以通过 Gossip 协议实现这个目标。 Gossip协议的核心一共是三块内容：直接邮寄（Direct Mail）、反熵（Anti-entropy）和谣言传播（Rumor mongering）。 一、直接邮寄（Direct Mail） 所谓直接邮寄，就是直接发送更新数据，当数据发送失败时，将数据缓存下来
分布式系统架构系列讲解二十六（分布式锁 6）Redisson红锁（red lock）原理源码分析
吃透Java
04-19 521
一，redlock算法 Redis 官网对 redLock 算法的介绍大致如下： 在分布式版本的算法里我们假设我们有N个Redis master节点，这些节点都是完全独立的，我们不用任何复制或者其他隐含的分布式协调机制。之前我们已经描述了在Redis单实例下怎么安全地获取和释放锁。我们确保将在每（N)个实例上使用此方法获取和释放锁。在我们的例子里面我们把N设成5，这是一个比较合理的设置，所以我们需要在5台机器上面或者5台虚拟机上面运行这些实例，这样保证他们不会同时都宕掉。为了取到锁，客户端应该执行以下操作:
分布式系统架构系列讲解二十四（分布式锁 4）Redisson单点，哨兵，红锁实战
吃透Java
04-16 420
Redisson是java的redis客户端之一，提供了一些api方便操作redis。 Redisson为我们提供了单台Redis加锁，Redis哨兵加锁，红锁等方案。 本节我们只介绍使用，至于原理和源码我们后面会详细分析，下面我们通过示例来展示一下用Redisson加锁的几种方式： 一，单台 Redis单点模式，也就是使用一台Redis服务来实现分布式锁。 缺点也是显而易见的，无法实现高可用，万一这台设备挂了，那么将无法加锁。 pom依赖 <dependency>
java 分布式系统架构
最新发布
07-13
Java 分布式系统架构是指使用 Java 编程语言开发的一种系统架构，用于处理大规模数据和请求的分布式系统。它将系统拆分为多个独立的模块，这些模块可以在不同的计算机或服务器上运行，并通过网络相互通信。 在 Java...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

吃透Java

你的鼓励是我最大的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值