回滚

一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 减库存的业务实现 减库存可以采用 同步调用 （Feign的方式），也可以采用 异步调用 （RabbitMQ传递消息），我们这里采用同步调用，接下来我们分析为什么 如果我们采用异步调用的方式，减库存的这条消息发送到MQ就不管了，那么到底库存减成功了没有呢？这我们并不知道，如果库存不足，那么我们减库存失败，但是service的业务不会回滚，这个问题就是分布式事务问题，即跨服务的事务。减库存这个业务从订单微服务跨越到了商品微服务，而事务是由Spring来管理的，两套tomcat两套Spring，本身没有任何关联，但是却是一个事务，如果采用异步，这边的微服务执行失败另一边的微服务并不知道，破坏了事务的一致性，我们解决的方案是什么呢？ 变异步调用为同步调用，如果一个微服务执行失败就会抛出异常，事务自然回滚（减库存的操作只能放在创建订单业务的最后，因为减库存执行失败事务自然回滚订单也不会创建成功，但是如果上来就先减库存，那玩意订单创建失败库存无法回滚），但是这种方案也不是最优的，因为我们没做优惠券功能，当我们做了优惠券功能，那计算优惠和减库存哪个放在最后呢？哪个放在最后都不可行，这时候就必须解决分布式事务问题了 解决分布式事务问题： 2PC（两阶段提交） ： 第一阶段

上一篇文章讲述的是抛弃A，保证CP的刚性分布式事务解决方案，这一篇介绍柔性分布式事务解决方案。 柔性事务遵循BASE理论，抛弃C，保证AP，以最终一致性来代替强一致性，柔性分布式事务解决方案中MQ承担非常重要的角色。 1.本地化消息表 A B两个分布式应用，各自有一个本地化消息表。 A中的业务和消息处于同一个本地事务中，也就意味着A的事务提交之后，消息表中也存放了这条消息。存完之后A系统会把这条消息发送到MQ.B接收到消息之后会写到本地消息表，同时执行业务逻辑.B应用也一样，业务和表处于同一个事务中。这里会有一个幂等操作，如果这条消息之前已经处理过，B就会回滚事务。B业务逻辑执行成功之后会更新消息的状态，同时更新A表的消息状态。 如果B系统处理失败了，那么就不会更新消息表状态，那么此时A系统会定时扫描自己的消息表，如果有没处理的消息，会再次发送到MQ中去，让B再次处理 这个方案保证了最终一致性，哪怕B事务失败了，但是A会不断重发消息，直到B那边成功为止 2.基于支持事务的MQ 上述方法有个比较不好地方，就是需要各个应用在本地建一个表，和业务耦合度比较高。有没有不需要本地建表的方法呢? 市面上有一些MQ支持事务的，比如RocketMQ。 在介绍这种方法之前先解释一下RocketMQ的几个名词 prepare消息 又名Half Message，半消息，标识该消息处于"暂时不能投递"状态

近期公司项目基于微服务架构需要涉及到实现一套分布式事务。经过几天在网上查阅资料发现大部分文章只是讲解了具体的其中一个模型。因此在这里做一个总结+自己的一些感悟和看法。 1.CAP理论 CAP理论本身并不是一套和事务相关的理论，而是用来解释分布式系统的理论。但是用来分析分布式事物的边界非常适合。关于CAP理论，可以查看阮一峰大神的这篇文章： CAP定理的含义 CAP理论一个核心论证就是P(分区容错性)作为一个分布式系统是肯定包含的。因此实际实现只是在CP和AP之间做抉择。 CP：为了保证一致性和分区容错性，那么肯定会丧失一部分可用性。 AP：为了保证可用性和分区容错性，那么肯定会丧失一部分一致性。 2.ACID原则 ACID原则是用来描述一个事务应该包含的特性。原子性、一致性、隔离性、持久性。这个原则实际上和CAP理论是相悖的。 3.刚性事务、CP模式、XA协议 我们来假设一个简单的支付场景， 生成订单--->扣用户积分--->核销优惠劵--->修改订单状态 。这里涉及三个系统，订单系统、用户积分系统、优惠劵系统。那么如果我们要保证事务的一致性，我们在其中的每一步都会将资源锁定，然后只有在最终事务全部完成后，我们才能释放锁。那么在整个事务周期内我们的功能必定是处于不可用状态。这也正符合 CP定义 。这么做的事务确实可以保证事务的ACID原则，但是因为锁定时间长、锁粒度大(锁定资源多)

在过去几年的DevOps的浪潮中，自动化、持续集成这两个概念早已深入人心(互联网技术人)。比尔盖茨先生曾经都说过：“任何技术在一个业务中使用的第一条规则就是，将自动化应用到一个高效的操作上将会放大高效。第二条就是自动化应用到一个低效操作上，则放大了低效率。” 自动化部署也逐渐成为各中小型企业追求的方向，那么，今天民工哥就自动化部署的概述、自动化部署的工具、自动化部署的流程、自动化部署实践等4个方面，与大家一同来讨论、交流一下关于中小企业自动部署的问题。 1、自动化部署概述 1.1 什么是自动化部署 一句简单的话概括：部署的过程中所有的操作全部自动化，无需人工手工干预。 1.2 自动部署的好处 传统的部署方式如下： 运维人员手工使用Scp、Xftp等方式来传输数据 手工登录服务器执行git pull 、svn update等命令进行更新代码的操作 开发人员手工编译打包，然后通过内网传输给运维人员 运维人员通过rz上传的方式上传到目标服务器，然后，执行重命名原包、拷贝新包到目标目录，再执行服务应用重启命令完成整个部署过程 看似非常简单，也不是很麻烦，但是一旦项目多，部署频繁，这种情况下就会大大降低工作效率。民工哥之前工作中就有这类体验，公司的活动类项目高达100+，很多都是需要快速上线及下线、或者更新的，手工部署真的累。 传统的部署方式有以下的缺点： 整个过程都需要人员参与

分布式事务 分布式理论 单个数据库的性能产生瓶颈的时候，我们可能对数据库进行分区，这里所说的分区是指物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的ACID已经不能适应这种情况了，而在这种ACID的集群环境下，再想保证集群的ACID会导致我们的系统变得很差，这个时候我们需要引入CAP原则。 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效) 可用性(Availability) ： 每个操作都必须以可预期的响应结束 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成 具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。 [了解] 数据库支持2PC，又叫XA Transactions,MySQL5.5、SQL Server2005、Oracle7开始支持。 其中，XA是一个两阶段提交协议，该协议分为以下两个阶段： ·第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。 ·第二阶段：事务协调器要求每个数据库提交数据。 如果任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在次数据库中的那部分信息

一、概述 在微服务架构下，虽然我们会尽量避免分布式事务，但是只要业务复杂的情况下这是一个绕不开的问题，如何保证业务数据一致性呢？本文主要介绍同步场景下使用 Seata 的 AT模式 来解决一致性问题。 Seata 是 阿里巴巴 开源的 一站式分布式事务解决方案 中间件，以 高效 并且对业务 0 侵入 的方式，解决 微服务 场景下面临的分布式事务问题 二、Seata介绍 整体事务逻辑是基于 两阶段提交 的模型，核心概念包括以下3个角色： TM ：事务的发起者。用来告诉 TC，全局事务的开始，提交，回滚。 RM ：具体的事务资源，每一个 RM 都会作为一个分支事务注册在 TC。 TC ：事务的协调者seata-server，用于接收我们的事务的注册，提交和回滚。 目前的 Seata 有两种模式可使用分别对应不同业务场景 2.1. AT模式 该模式适合的场景： 基于支持本地 ACID 事务的关系型数据库。 Java 应用，通过 JDBC 访问数据库。 一个典型的分布式事务过程： TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID 。 XID 在微服务调用链路的上下文中传播。 RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。 TM 向 TC 发起针对 XID 的全局提交或回滚决议。 TC 调度 XID

前言 发布是持续交付的最后一公里。 传统上，软件的最终发布是个充满压力的过程，需要大量的手工配置、操作和团队配合。为了发布的可靠性，开发人员需要准备详尽的部署文档，然后再把相关信息同步给运维人员执行部署，由运维人员执行一系列个性化的发布脚本，部署完后还需要测试人员做详尽的手工验证。 每个步骤里都有很多需要人为判断和信息沟通的事情，稍有不慎就很会产生人为错误造成系统故障，发布时间和结果都不可预测，发布之后忙活到凌晨，绞尽脑汁想着怎么让刚刚部署的应用程序能够正常工作，最后常常不得不回滚，类似这样的场景都很常见。 要解决这样的痛点，除了在软件研发时采用小步迭代的方式，降低交付复杂度外，一套易用、快速、稳定、容错力强，必要时有能力快速回滚的发布系统必不可少，本文将重点建设微医在发布平台建设过程中的一些优秀实践。 核心特性 覆盖主流应用：Java、NodeJS、Python、PHP、Lua、Android、IOS等。 支持分批发布和灰度发布 支持发布暂停和恢复 支持历史版本的快速回滚 支持应用重启和停止等操作 支持多实例应用日志聚合查看 支持分布式的发布节点 发布前质量红线卡点 发布中实时监控分析 发布后质效度量 整体架构 典型应用发布流程： 系统立项后，在WCP-应用管理中申请创建应用，输入包括开发语言、jdk版本、构建工具、部署方式、产物路径、代码地址、应用负责人等应用基础信息

分布式事务简介： 对于分布式系统，必然会存在分布式事务，如果对分布式事务一无所知必然会很坑，所以起码要知道有哪些方案，一般怎么来做，每个方案的优缺点是什么，这一点要清楚。 现在，分布式系统变成了标配，而分布式系统带来的分布式事务也成了标配了。因为我们做系统肯定要用事务的，如果是分布式系统，肯定要用分布式事务了吧，先不说有有没有搞过，起码得明白有哪几种方案，每种方案可能有什么坑的存在？eg：TCC方案的网络问题 ，XA方案的一致性问题。 分布式事务的实现主要有以下5种方案： 1.XA方案（两阶段提交） 2.TCC方案 3.本地消息表 4.可靠消息最终一致性 5.最大努力通知方案 两阶段提交方案/XA方案 所有XA方案，就是 两阶段提交 ，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库回复都ok的话，那就ok，正式提交事务，在各个数据库上执行操作，如果任何其中一个数据库回答不ok，那么就回滚事务。 这种分布式方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于spring+JTA就可以搞定，自己随便找个demo看一下。 这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的操作，是不合规的。现在说下微服务

Cr块consistent read块也就是用来维护oracle的读一致性的数据块。当查询某些数据的时候，发现数据块的版本比我们要查询的新，例如session1执行了dml操作并没有提交，session2此时查找跟session1相关的dml操作的数据信息，此时查询的数据却是原来的数据信息。 查询的过程会在undo段中查找该数据块的前映像后，然后把前映像和current块合并形成了一个CR block，通过查询cr block就可以满足数据的一致性了。 CR block存在与sga的buffer cache中，在db cache里申请一个数据块，然后对应的回滚段的前映像生成cr block。 cr块的数量是由隐含参数_db_block_max_cr_dba控制的，默认是最高同时存在5个cr块，构造cr块时cr block created计数器都会增加1. 由于cr block和current block的数据块的rdba都是相同的，会放在相同的hash链上，当然某些block的cr block的版本过多，自然会引起hash链上的竞争，导致latch buffer cache chain闩竞争。 当然在利用回滚段的前映像和current block构造cr块时，很有可能回滚段的已经被覆盖，也就会出现常见的ora-01555快照过旧。 一个sql语句如何去查询数据信息了

https://blog.csdn.net/weixin_40836179/article/details/87006285 来源： https://blog.51cto.com/19941018/2435514