分布式事务

2019独角兽企业重金招聘Python工程师标准>>> 摘要: 原创出处 http://www.iocoder.cn/Sharding-JDBC/transaction-bed/ 「芋道源码」欢迎转载，保留摘要，谢谢！ 本文主要基于 Sharding-JDBC 1.5.0 正式版 1. 概述 2. 最大努力送达型 3. 柔性事务管理器 3.1 概念 3.2 柔性事务配置 3.3 柔性事务 3.3.1 创建柔性事务 4. 事务日志存储器 4.1 #add() 4.2 #remove() 4.3 #findEligibleTransactionLogs() 4.4 #increaseAsyncDeliveryTryTimes() 4.5 #processData() 5. 最大努力送达型事务监听器 6. 最大努力送达型异步作业 6.1 BestEffortsDeliveryJob 6.2 AsyncSoftTransactionJobConfiguration 6.3 Elastic-Job 是否必须？ 7. 适用场景 8. 开发指南 & 开发示例 666. 彩蛋 ???关注**微信公众号：【芋道源码】**有福利： RocketMQ / MyCAT / Sharding-JDBC 所有 源码分析文章列表 RocketMQ / MyCAT / Sharding-JDBC 中文注释源码

摘要: 原创出处 http://www.iocoder.cn/Sharding-JDBC/transaction-bed/ 「芋道源码」欢迎转载，保留摘要，谢谢！ 本文主要基于 Sharding-JDBC 1.5.0 正式版 1. 概述 2. 最大努力送达型 3. 柔性事务管理器 3.1 概念 3.2 柔性事务配置 3.3 柔性事务 3.3.1 创建柔性事务 4. 事务日志存储器 4.1 #add() 4.2 #remove() 4.3 #findEligibleTransactionLogs() 4.4 #increaseAsyncDeliveryTryTimes() 4.5 #processData() 5. 最大努力送达型事务监听器 6. 最大努力送达型异步作业 6.1 BestEffortsDeliveryJob 6.2 AsyncSoftTransactionJobConfiguration 6.3 Elastic-Job 是否必须？ 7. 适用场景 8. 开发指南 & 开发示例 666. 彩蛋 ������关注 微信公众号：【芋道源码】 有福利： 1. RocketMQ / MyCAT / Sharding-JDBC 所有 源码分析文章列表 2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址 3.

一、什么是消息未读 消息未读包括 会话未读 和 总未读 。前者指的是当前用户和某一聊天方的未读消息数，后者指的是当前用户的所有未读消息数，也就是所有会话未读的和。比如用户A收到用户B的2条消息，还收到用户C的3条消息，则用户A与B的会话未读数是2，用户A与C的会话未读数是3，用户A的总未读是5。 二、消息未读的维护 会话未读和总未读数一般都是单独维护的。这是因为： 1）总未读的使用场景较多，会被高频使用。如APP角标未读展示； 2）如果不单独维护，则总未读数需要通过计算所有的会话未读数，一旦会话数较多，就需要多次读取存储，多次获取累加的操作容易出现性能瓶颈。而且一旦发生超时等意外，就会无法获取到会话未读数，导致总未读数不准确。 三、消息未读的一致性 单独维护总未读和会话未读数会带来新问题，也就是消息总未读数与（多个）会话未读数不一致的问题。比如APP角标显示5，表示有5条未读消息，但用户点进去却发现没有新消息或只有3条消息，就会给用户造成不好的体验。 消息未读不一致的原因 用户B的初始状态：会话未读数和总未读数都是0。 用户A给用户B发消息，消息到达IM服务后，执行加未读操作：先把用户B与用户A的会话未读数加1，再把用户B的总未读数加1，然后消息推送给用户B。 case1 ：假设加会话未读数的操作成功、加总未读数的操作失败了，则用户B的最新状态是：会话未读数是1，总未读数是0。

## 分布式事务选型 ### 选型依据: - 多语言支持 - 微服务框架兼容程度 - 关系型数据库-MQ事务的支持 - 性能与稳定性以及是否支持高可用 - 业务代码侵入性 - 可拓展性 - 社区活跃度及影响力 ------ ### GTS概览 #### 针对不同的应用场景,GTS主要提供标准模式(AT)和自定义模式(MT)两种事务模式. - **AT模式**: GTS 最主要的事务模式,通过 GTS 基于 DRDS/RDS 数据源,对 sql 语句提供分布式事务的支持.他帮助应用以最小的改动代价来实现数据库的事务功能.AT 模式适用于 DRDS 分库分表/多数据库数据源/跨进程的多数据库数据源等几乎任何 DRDS 应用场景下的分布式事务. - **MT模式**: 提供给用户的一种可介入两阶段提交过程的一种模式.在这种模式下,用户可以根据自身的业务场景的需求自定义在 GTS 两阶段提交的过程中每阶段的具体行为.MT 模式提供了更多的可能性和灵活性,以达到特殊场景下的自定义特殊功能实现.**MT 模式不依赖于数据库,几乎满足任何事务场景.** #### 在 AT 和 MT 两种模式下,GTS 又提供了三种具体的使用方式: - **AT模式下,使用注解接入分布式事务** 这种方式只需要代码中依赖 GTS 的 SDK 即可.在希望引入分布式事务的方法上,仅需一行注解即可.适用场景包括

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

项目常见面试问题 阅读目录 项目常见面试问题 回到目录 项目常见面试问题 一、你的项目中缓存粒度是如何选择的? 缓存粒度一共分为4种. 1.缓存某个数值:一个键只保存一个值,性价比较低,使用率低,如果存储的话我们使用redis的String 2.缓存数据对象:数据库记录对应的具体数据,优点是可以多次复用,String,hash 3.缓存数据集合:数据库查询对应的结果集,可以和数据对象配合使用,方便数据对象的重用,hash,list,set,zset,String(zset,String) 4.缓存试图响应:试图返回的相应数据,复用性比较差,String 所以我们项目中主要对数据集合+数据对象进行缓存,他们的优点是复用性强,节省内存空间. 二、使用过redis的那些格式做过缓存,其他应用场景和优缺点是什么? 包括list,zset,set,hash和json字符串 其中我们使用过json字符串和zset set用来存放无序去重的数据, 如果有判断是否存在的需求 zset有排序的需要list,如果说是按时间查询, 查询的结果固定, 不需要分页的情况下,我们使用list因为查询的比较快 但如果有额外排序要求, 而且需要分页, 我们使用zset(查询时间跟查询的长度和数据量有关,跟查询区别无关, 查询速度比较均衡), 增加数据效率和存储的数据量负相关,数据量越大,添加时间越长

1.　引言 　 　事务大家都知道，就是相当于一个原子操作，要么全部执行，要么发生异常全部回滚。但事务只限于本地事务，即各个数据库操作必须在同一数据库下执行。拿我最近的接手的项目来说，各个模块全部部署于不同的服务器，都有自己独立的数据库。前端想要删除一个用户，先调用用户平台的删除用户接口，再调用权限平台的删除权限接口。起初觉得这样操作没什么问题，后来有几次数据异常后，发现有的用户信息没有，但权限信息还存在，导致数据不一致。此时，就想到了用分布式事物来解决。所谓分布式事物，我个人理解是为了解决数据一致性的问题。 2.　kafka+本地事物表解决分布式事务 　　 消息队列的产生是为了解决各系统间通信问题，因为Kafka用的比较多，此处就想到用Kafka+本地事物表去解决分布式事务问题。关于Kafka+zookeeper的搭建此处不做详解。 　　上图是自己基于Kafka+本地事物表实现的基本流程（图自己画的，可能不太清楚）代码后文贴出，（上图箭头只代表流程，和下文的1.2.3无关）此处讲一下自己的思路。先申明，kafka只能保证最终一致性，并不是强一致性。我们最终目的是保证上图2个蓝色方块的任务执行。方便说明，假定2个系统A，B 分别对应的2个数据库A库和B库。其中A库中的事务表叫做A事务表，B库中的事务表叫做B事务表。要执行的蓝色方块叫A业务和B业务。 　　 1. 　在A系统中

开发单体应用时，相信大家都有使用过数据库的 本地事务 ，也就是在同一个数据库中，可以允许一组操作要么全都正确执行，要么全都不执行。这里特别指出了本地事务，也就是说明数据库事务只支持同一个数据库的操作。可随着技术和业务发展，一方面随着系统业务量增大，数据库存储东西越来越多。当达到一定数据量时，为了应对高并发，就会出现分库分表需求。另一方面，随着服务化方案的推广，越来越多的公司团队将原有的大项目拆分成一个个小应用，这也使得跨应用（JVM）数据库场景出现。可是目前数据库不支持跨库事务，我们应该如何实现分布式事务呢？本文首先会为大家梳理分布式事务的基本概念和理论基础，然后介绍几种目前常用的分布式事务解决方案。 一、定义 百度百科给出的定义：“分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。”简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 二、事务的四大特性 ACID 1.原子性 原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。 2.一致性 一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。 3.隔离性

关于ACID,CAP和BASE这边就不详细说明了，想了解的可以找网上的相关文章。 分布式事务分为刚性事务和柔性事务两种类别，根据CAP理论刚性事务是会舍弃掉A，保证CP 刚性事务 严格一致性 执行时间短 实时性要求高 首先，很自然的，我们可以把一个分布式事务理解成一个包含了若干 分支事务 的 全局事务 。 全局事务 的职责是协调其下管辖的 分支事务 达成一致，要么一起成功提交，要么一起失败回滚。此外，通常 分支事务 本身就是一个满足 ACID 的 本地事务 。这是我们对分布式事务结构的基本认识，与 XA 是一致的。 1.两阶段提交方案/XA方案 两阶段提交会引入两个组件: 1.全局事务协调者（Cooradinator） 2.参与者（Participant） 一阶段： a.Cooradinator向所有参与者Participant发出询问，是否可以提交事务 b.各参与者执行本地事务操作，并且将undo和redo日志写入到本地事务日志中 c.各参与者将事务执行结果反馈给Cooradinator，成功反馈yes，失败反馈no。 二阶段： Cooradinator根据各参与者反馈的情况执行不同的策略； 情况一：如果全部参与者反馈yes，Cooradinator向所有参与者发出commit命令，所有参与者执行redo中的内容，提交本地事务，并且反馈ack给Cooradinator

目录 前言 分布式事务方案 强一致性 2PC 两阶段提交（XA事务，阻塞） 3PC三阶段提交(非阻塞，引入超时和准备阶段) TCC模式-本质也是2PC Saga模式 最终一致性（BASE理论） 本地消息表 MQ消息队列 Paxos Raft ZAB 协议 ( Zookeeper Atomic Broadcast) 原子广播协议 总结 前言 如果只有一个数据库，所有的逻辑都在一个db完成，那么本地事务很简单就可以处理。但是，在微服务架构中，功能服务化，服务拆分化，一个业务逻辑很可能需要多个service完成，每个service操作不同的数据库，分布式事务需要一套方案来实现，本文就来集中讲述一下分布式事务的常见方案。 比如我们支付宝余额转入到余额宝，支付宝余额和余额宝是不同的服务，再比如跨行转账，从你的工商银行账户A转1000到建设银行账户B，比如订单系统和库存系统，其实有些情况下不一定要利用分布式事务，能避免尽力避免，主要看业务场景的需要，究竟是强一致性，弱一致性，还是最终一致性。 电商系统常见的例子：订单支付的时候使用红包或者优惠券，必需同时成功或者失败 常见对分布式事务场景： 跨库事务 分库分表，分库分表之后，一般可以利用mycat等数据库中间件简化开发，但是数据库中间件也面临分布式事务的问题 SOA架构（跨应用） 分布式事务方案 强一致性 2PC 两阶段提交（XA事务，阻塞）