分布式事务解决方案(浅谈中台架构)

我们都知道传统的本地事务通过Spring的@Transactional就可以实现
当我们下订单的时候 更改订单状态，扣减库存都在一个方法中写的，通过@Transactional就可以做到本地事务的回滚或者提交

但是随着我们业务的发展，我们的会吧库表分开, 吧一个完整的数据库现在拆分成多个库，一个订单支付的操作设计到2个操作 一个是 支付订单  update 状态 ,一个是减库存,现在在一个方法中操作了2个库   这种场景 使用@Tr 搞定么

碰到这种场景我们该怎么办呢，这种只是跨库的分布式事务
单系统跨库 事务也算是分布式事务， 因为此时用@Transactional 是不能帮我们解决跨库事务的，此时用两阶段提交协议

两阶段提交这个协议有一个角色的划分 会抽象出来一个事务协调者和参与者,
我们这种跨库问题在哪里，订单支付我们想要达到效果 就是订单状态改为已支付，减少库存，我们希望这2个操作要么同时成功 要么同时失败，这是一个整体的事务

如果不用事务的时候就可能出现订单更改状态成功，但是库存扣减失败
库存扣减失败的原因有很多 比如说库存不够减，库存库挂了，这样就会会造成2边事务不一致,一般来说出现事务不一致就是第一步状态修改为支付成功了 第二部 减库存失败了

我们引入两阶段提交这种协议帮我们解决这种跨库的事务是怎么去做的 ,我们首先会引入事务管理器（中间协调者），然后第一步就是我执行完sql 但是我不提交  我只是吧结果告诉给了中间协调器，中间协调者收到以后，如果这些都成功了，事务管理者正常通知所有库提交事务
第一阶段有个专业的名词叫做预提交，你sql执行完毕不提交就叫预提交，他并没有真正的落地到数据库，只是吧执行的结果告诉给了资源协调器，吧资源锁住
如果第一个阶段2个阶段都成功  事务管理器通知所有数据库 去提交事务
第一个阶段有一个报错 第二个阶段就做rollback操作  这就是两阶段提交的底层思想 

事务管理器通知第二个阶段每个事务 commit/rollback,会不会可能出现这种情况
我通知订单库的时候成功了
我通知库存库的时候失败了
感觉也不能100%的解决分布式事务的问题
分布式事务不可能100%解决。第二阶段通知过程中可能因为网络原因导致部分节点通知失败。只可能尽量提高成功概率 这种情况会触发重试机制，或者短信通知
对应的运维人员进行补偿
如果不用两阶段提交.最可能出现的情况就是你执行订单更改状态正确
操作第二个的时候减库存失败了,我们的两阶段提交是不是就可以解决这种
情况
我们两阶段提交协议大大的提高了事务提交的概率  
我希望我跨库的事务 要么同时成功 要么同时失败
我开启一个全局事务 ,我只是执行不提交操作
如果说有报错了 会同时回滚
第一步 我让对应的每一个数据库的资源管理器做一个预提交， 对应的sql事务做一个预提交
第二步 我判断我预提交的结果是不是都是成功的 如果有失败的我就做回滚操作

微服务架构下的分布式事务问题,也是用的两阶段提交的思想,第一个阶段就是欲先锁定资源（比方说就是我的库存订单） 我们要操作一些数据,我们先给他锁定住.校验下数据库 缓存  是否都是正常的
第一阶段先吧可能出错的场景做一个校验

微服务情况下,可能会导致分布式事务问题是怎么发生的,服务调用出现问题
比如说我下单流程 第一步需要校验用户，第二部需要添加订单 第三步需要扣减库存
以前是跨库事务, 现在是跨系统事务.一个操作下跨很多个服务. 跨系统事务  减少库存要到另外的系统去做了.叫做库存系统 ,交易 订单改状态 库存 改数据现在是夸库 夸系统去执行
此时需要 跨系统调用http接口，跨库存系统调用减少库存系统
如果不做任何控制. 跨系统调用接口如果不做任何控制
远程调用接口的失败性还是很大的 此时就会出现事务不一致
比如说校验用户成功，添加订单成功，扣减库存失败  这种情况下怎么做回滚

刚刚这个操作 他也会划分为2个阶段  第一个阶段就是预留阶段
把我们可能出现问题的资源以及数据库 欲先校验一下 看是不是ok的  如果第一个阶段校验成功了
第二个阶段成功概率会大大提高

如果第一个阶段校验失败了 第二个阶段直接就回滚了

第一个阶段改为更新中,调用库存服务的api 只是说吧库存给冻结住,调用积分服务的第一个阶段是:锁住对应积分,都是一些中间状态,一旦中间操作所有都成功了 吧库存锁了 吧订单操作的呢一行记录也锁了，以及积分这条数据锁定了
第二个阶段就是comfirm 
具体的Tcc可以看看这里
https://blog.csdn.net/vincent_wen0766/article/details/114089317

写点关于中台的一些方案

业务中台:比如说抽取一些用户中心 标签工厂 产品中心这块的架构,所以我们这边现在有了重中台+轻应用的这个概念
数据中台:就是将整个业务系统的数据统一收集起来，就像我们这边的数仓，集市
技术中台 就是要封装各个业务系统所采用的技术框架，封装各种pom,使上层业务开发的门槛降低，提升交付速度，比如说redis框架的整合，日志文件处理，以及怎么部署 这些都是技术中台要拿出来的一个统一方案
需要提供一套关于系统的运维，测试，这些有一个统一的方案，不能说A系统技术栈用Springcloud，B系统技术栈还在用Spring

中台并不是好的，他有他的局限性。中台战略涉及到对整个公司的资源进行大刀阔斧的调整，对组织架构进行调整

以前的是这种烟囱式团队
https://zhuanlan.zhihu.com/p/323274279

	中台的本质就是提炼各个业务的共同需求，进行业务和系统抽象，进而形成通用可复用的业务模型，打造成组件化产品，形成系统化的能力输出，供各个业务部门使用,已达到一个快速交付的能力

	而在中台建设过程当中，技术中台往往是最为重要的一环。技术中台团队，往往需要由最精锐的开发人员组成。
	这样的技术中台需要功能全面、简单易用、部署简单、易于升级等等非常多的特点。
	或许能够让你对技术中台有个大致的概念。
1>技术栈统一：采用SpringCloud技术栈，提供统一的架构支持。同步服务调用、异步消息通信，
再到数据存储等功能，提供基于SpringBoot的拔插式支持，各应
用只需要按需组合即可。在此基础上，提供统一配置、统一版本管理等集中式的
管理方案。
例如框架中各种maven依赖的版本，只提供几个统一的框架版本供业务
进行选择。框架版本内的各个组件版本采用集中配置的方式也集中到
maven仓库中进行管理。这样，框架版本内部对某些组件版本进行版本
微调时，对业务可以做到基本无感知。
或许你听说过在2020年fastjson爆出了一个高危漏洞，在行业内造成了
非常大的影响，各个应用都需要尽快升级fastjson版本。而在我们的技术
中台架构中，只需要在maven仓库中对fastjson的依赖版本进行统一升
级，各个业务应用基本上不需要做改动，只需要随着迭代进行一次常规
升级就避免了这个问题。

解决方案统一：对微服务调用、MQ异步通知、日志脱敏、传输数据加密、缓存
一致性等各种功能在框架中提供统一的解决方案。这些解决方案，大部分是以
API的形式提供，业务方只需要进行调用即可。而如果不能形成API接口的，集成
到代码静态检查规范当中，在编译发布的阶段给出统一的指导。

运维与框架统一：将外部依赖的组件与框架形成统一。例如某业务可能需要用到
MQ做异步通信，会由技术中台团队完成MQ的部署，并且将MQ相关的实现以及
配置信息一并上传到配置管理中心。业务团队在使用时甚至都不需要知道MQ部
署地址，就可以直接拿来用。
部署与运维统一：以Jenkins为基础，定制整套完整的部署运维方案。业务团队只
需要往Git仓库中提交代码，后续项目打包以及测试环境的部署全部自动完成，不
需要人工参与。

上线方案统一：对线上环境，机器配置与服务部署都形成统一的标准，业务团队
申请线上资源时，只需要申请自己需要什么，而不用管具体的细节。
所以，技术中台并不等同于框架设计，他的落地方案是多种多样的。我们可以说
用SpringCloud做微服务是最好的，但是对于中台，很难说某一个公司的落地方案
就一定是好的。不要简单的认为跟着互联网大厂学习了一下他们的技术或者架构，
我们就做好了中台了。中台没有最好的，只有最适合的

#中台的好处
阿里的无人超市、无人酒店、盒马生鲜等新业务，开展起来就非常快。因为风
控、支付、用户、商户这些环节都已经有了现成的能力，线上部分只需要开发一个简单的APP，将这些能力组合到一起，就可以开展业务。
# 比如说我们这边 用户中心 产品中心

#中台落地的问题却很多
中台的价值观念很模糊：中台并不能直接体现出来他的价值 ，而是通过上层业务才能体现出他的价值
2.中台并不能总能提炼出共性需求：中台的核心是提炼业务的共性，进行沉淀、提炼，形成中台业务能力 ，但是在实际落地中，那些是共性的，那些是非共性的这个很难形成一个标准 这个度很难把握
中台如果做的多了的话 ，可能形成业务系统偷懒的利器  什么功能都提给中台
中台做的少的话，又很难得到业务系统的认可，这也就是大公司天天开会扯皮的
可能开次会议还商量不下来 需要上报给领导再看做与不做

3、中台存在更多的变化
中台的业务能力要实时发生变化，这很容易造成具体业务掉队。例如一个中台针
对十个业务开发了一个底层业务能力，这时，其中一个大业务要对这个业务能力进行更新。中台如果接受了，就很可能会要求其他九个业务也要调整自己的业务流程以适应新的中台功能。那这对这九个业务来说，就是无意义的工作。
所以现在越来越多的人提出中台并不是银弹，并不是所有企业都需要中台。
## 开会扯皮

# 中台的技术问题可以用DDD

#目前我也需要提高我的沟通能力以及表达能力