RocketMQ事务音讯处置的是本地事务的执行和发音讯这两个举措满足事务的约束。Kafka事务音讯则是用在一次事务中需求发送多个音讯的状况，保证多个音讯之间的事务约束，即多条音讯要么都发送成功，要么都发送失败。
最大努力通知机制最大努力通知机制本质是经过引入活期校验机制来对最终分歧性做兜底，对业务侵入性较低、对MQ系统要求较低，完成比较复杂，适宜于对最终分歧性敏感度比较低、业务链路较短的场景，比如跨平台、跨企业的系统间的业务交互。
适用场景小明经过联通网上营业厅为手机充话费。整个操作的流程如下：
小明选择充值金额“50元”，支付方式“支付宝”。
联通网上营业厅创立一个充值订单，形状为“支付中”，并跳转到支付宝的支付页面。
支付宝验明白认小明的支付后，从小明的账户中扣除50元，并向联通的账户中添加50元。执行终了后向MQ系统发送一条音讯，音讯的内容标识支付能否成功，音讯发送允许失败。
假设音讯发送成功，那么支付宝的通知效劳会订阅到该音讯，并调用联通的接口通知本次支付的结果。假设此时联通的效劳挂掉了，招致通知失败了，则会按照5min、10min、30min、1h、...、24h等递增的时间距离，距离性重复调用联通的接口，直到调用成功或许到达预定的时间窗口下限后，则不再通知。这就是最大努力通知的含义。
假设联通效劳恢复正常，收到了支付宝的通知，给账户充值（联通的充值接口需求保证幂等性）
假设联通效劳缺点时间很久，恢复正常后，已超出支付宝通知效劳的时间窗口，则联通扫描“支付中”的订单，自意向支付宝发起央求，核验订单的支付结果。
技术选型 2PC&3PC2PC&3PC强依赖数据库，可以很好的提供强分歧性和强事务性，但相对来说延迟比较高，比较适宜传统的单体运用，在同一个办法中存在跨库操作的状况，不适宜大型散布式、高并发和高功用要求的场景。
TCCTCC适用于执行时间确定且较短，实时性要求高，对数据分歧性要求高，比如互联网金融企业最中心的三个效劳：买卖、支付、账务。
Saga事务Saga事务适用于业务流程长、业务流程多的业务且并发操作同一资源较少的状况。在银行业金融机构运用普遍，比如互联网微贷、渠道整合场景、金融机构对接系统(需求对接外部系统)等
基于本地音讯表机制&基于事务音讯机制两者都适用于事务中参与方支持操作幂等，对分歧性要求不高，业务上能容忍数据不分歧，直到兜底机制完成最终分歧性。事务触及的参与方、参与环节较少，业务上有对账/校验系统兜底。
最大努力通知机制最大努力通知机制适宜于对最终分歧性敏感度比较低、业务链路较短的场景。
前置知识关于文中提到名词的补充解释。
DTP模型DTP(Distributed Transaction Process)是一个散布式事务模型。在这个模型外面，有三个角色：
AP: Application，事务的发起者，也就是业务层。哪些操作属于一个事务，就是AP定义的。
TM: Transaction Manager，事务管理器，也称协调者。接纳AP的事务央求，对全局事务停止管理，管理事务分支形状，协调RM的处置，通知RM哪些操作属于哪些全局事务以及事务分支等等。是整个事务调度模型的中心部分。
RM：Resource Manager，资源管理器，也称参与者。普通是数据库，也可以是其他的资源管理器，如音讯队列(如JMS数据源)，文件系统等。
DTP模型上定义了三个角色，但实践完成上可以由一个角色同时担当两个功用。比如：AP和TM兼并，TM没必要独自部署组件。
XA协议(XA Specification)XA是一种散布式事务处置标准。XA标准了TM与RM之间的通讯接口（如下图所示的函数），在TM与多个RM之间构成一个双向通讯桥梁，从而在多个数据库资源下保证强分歧性。目前知名的数据库，如Oracle、DB2、MySQL等，都是完成了XA接口的，都可以作为RM。
在整个事务处置进程中，数据不断处于锁住形状，即从prepare到commit、rollback的整个进程中，TM不断持有数据库的锁，假设有其他事务要修正数据库的该条数据，就必须等候锁的释放。
【编辑引荐】
企业级NoSQL数据库基础入门与基础架构
.NET微效劳架构开发实战视频课程
Redisson 散布式锁源码之一：可重入锁加锁
编译优化｜LLVM代码生成技术详解及在数据库中的运用
读效劳+写效劳别离架构，我坚决支持！
(责任编辑：admin)