最大努力通知型分布式事务

最新推荐文章于 2024-08-02 11:00:00 发布
最新推荐文章于 2024-08-02 11:00:00 发布
阅读量1k 收藏 22
点赞数 21
分类专栏： 分布式事务 文章标签： 分布式 分布式事务 最大努力通知型事务 架构
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liubopro666/article/details/135091956
版权

系列文章目录

提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加
最大努力通知型分布式事务

提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

前言

提示：这里可以添加本文要记录的大概内容：

在当今的分布式系统中，确保数据的一致性和可靠性是至关重要的。而传统的事务处理方式在分布式环境下往往面临着挑战，如网络延迟、节点故障等。为了解决这些问题，最大努力通知型分布式事务应运而生。
最大努力通知型分布式事务是一种柔性事务处理机制，它允许在某些情况下事务可能无法完全成功，但会尽最大努力确保最终的一致性。与传统的原子性事务不同，最大努力通知型分布式事务强调可用性和最终一致性，而不是严格的原子性。
在本博客中，我们将深入探讨最大努力通知型分布式事务的原理、实现以及其在实际应用中的优势。我们将介绍一些常见的最大努力通知型分布式事务解决方案，如基于消息队列的实现、基于定时任务的实现等。同时，我们也会探讨最大努力通知型分布式事务在高并发、高可用场景下的应用。

提示：以下是本篇文章正文内容，下面案例可供参考

一、什么是最大努力通知型分布式事务？

最大努力通知型分布式事务（Best-Effort Notification Distributed Transaction）是一种在分布式系统中处理事务的柔性事务模型。与传统的原子性事务不同，最大努力通知型分布式事务不保证事务的原子性，而是专注于尽最大努力确保事务的最终一致性。
在最大努力通知型分布式事务中，事务的参与者（通常是服务或数据库）会尽力完成事务的操作，但并不保证一定能够成功。如果事务执行过程中发生了故障或异常，参与者会尝试采取一些补偿措施来恢复到一致的状态。
最大努力通知型分布式事务的核心思想是通过多次尝试来达成最终一致性。参与者在执行事务操作后，会发送通知给其他相关方，告知事务的执行结果。如果通知发送失败，参与者会进行重试，直到通知成功或达到一定的重试次数。

最大努力通知型分布式事务一定要包含两个方面

  1. 有一定的消息重复通知机制：接收通知方有可能无法接收到通知，一定要具有重复通知的机制。
  2. 消息校对机制：在重复通知仍然没有通知到对方，可由接收通知方主动查询信息。

二、最大努力通知型分布式事务和可靠消息最终一致性分布式消息的区别

最大努力通知型分布式事务是一种事务处理模型，它的主要目标是尽最大努力确保事务的最终一致性。在最大努力通知型分布式事务中，事务的参与者（通常是服务或数据库）会尽力完成事务的操作，但并不保证一定能够成功。如果事务执行过程中发生了故障或异常，参与者会尝试采取一些补偿措施来恢复到一致的状态。最大努力通知型分布式事务就像是你让朋友帮你办事，但不能保证一定能办成。你的朋友会尽最大的努力去做，但如果出现问题，他可能会告诉你事情没办成，或者尝试其他方法来解决。
可靠消息最终一致性分布式消息是一种消息传递模型，它的主要目标是确保消息的可靠传递和最终一致性。在可靠消息最终一致性分布式消息中，消息发送方将消息发送到一个可靠的消息中间件，消息中间件负责将消息可靠地传递给接收方。如果消息传递过程中发生了故障或异常，消息中间件会尝试重新发送消息，直到消息被成功接收。可靠消息最终一致性分布式消息就像是你给朋友寄了一封信，你可以确定他最终会收到这封信，但不能保证他什么时候会收到。信件可能会在路上丢失或延误，但最终它会到达朋友手中。
最大努力通知型分布式事务和可靠消息最终一致性分布式消息的主要区别在于：

  1. 事务处理和消息传递：最大努力通知型分布式事务关注的是事务的处理和最终一致性，而可靠消息最终一致性分布式消息关注的是消息的可靠传递和最终一致性。
  2. 可靠性保证：最大努力通知型分布式事务并不保证事务的原子性，可能会存在数据不一致的情况；而可靠消息最终一致性分布式消息保证消息的可靠传递，通常会实现至少一次传递。
  3. 补偿措施：最大努力通知型分布式事务在事务执行失败时会尝试采取补偿措施来恢复到一致的状态；而可靠消息最终一致性分布式消息通常不需要补偿措施，因为消息中间件会负责确保消息的可靠传递
  4. 应用场景：最大努力通知型分布式事务适用于对事务的一致性要求不高，但需要尽可能保证最终一致性的场景。例如，电商系统中的订单状态更新，虽然不能保证每次更新都能成功，但可以通过多次重试来尽可能确保最终一致性。可靠消息最终一致性分布式消息适用于需要保证消息可靠传递和最终一致性的场景。例如，金融系统中的交易确认消息，必须确保消息被可靠地传递和处理，以保证交易的正确性和一致性。

三、最大努力通知型分布式事务的步骤

  1. 发起通知方将通知发给MQ。 使用普通消息机制将通知发给MQ。
  2. 接收通知方监听 MQ。
  3. 接收通知方接收消息，业务处理完成回应ack。
  4. 接收通知方若没有回应ack则MQ会重复通知。 MQ会按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔（如果MQ采用 rocketMq，在broker中可进行配置），直到达到通知要求的时间窗口上限。
  5. 接收通知方可通过消息校对接口来校对消息的一致性。

四、最大努力通知型分布式事务的项目实战

数据库设计

1.创建tx-notifymsg-account库

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- Table structure for account_info
-- ----------------------------
DROP TABLE IF EXISTS `account_info`;
CREATE TABLE `account_info` (
 `id` int(11) NOT NULL COMMENT '主键id',
 `account_no` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT '账户',
 `account_name` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '账户名',
 `account_balance` decimal(10, 2) NULL DEFAULT NULL COMMENT '账户余额',
 PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = DYNAMIC;
-- ----------------------------
-- Records of account_info
-- ----------------------------
-- ----------------------------
-- Table structure for pay_info
-- ----------------------------
DROP TABLE IF EXISTS `pay_info`;
CREATE TABLE `pay_info` (
 `tx_no` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT '充值记录流水号',
 `account_no` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '账户',
 `pay_amount` decimal(10, 2) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '充值金额',
 `pay_result` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '充值结果',
 `pay_time` datetime(0) NOT NULL COMMENT '充值时间',
 PRIMARY KEY (`tx_no`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = DYNAMIC;
-- ----------------------------
-- Records of pay_info
-- ----------------------------
SET FOREIGN_KEY_CHECKS = 1;

2.创建tx-notifymsg-payment库

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- Table structure for pay_info
-- ----------------------------
DROP TABLE IF EXISTS `pay_info`;
CREATE TABLE `pay_info` (
 `tx_no` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT '充值记录流水号',
 `account_no` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '账户',
 `pay_amount` decimal(10, 2) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '充值金额',
 `pay_result` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '充值结果',
 `pay_time` datetime(0) NOT NULL COMMENT '充值时间',
 PRIMARY KEY (`tx_no`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = DYNAMIC;
-- ----------------------------
-- Records of pay_info
-- ----------------------------
SET FOREIGN_KEY_CHECKS = 1;

Rocketmq准备

1.安装NameServer，拉取镜像

docker pull rocketmqinc/rocketmq

2.创建数据存储目录

mkdir -p /docker/rocketmq/data/namesrv/logs /docker/rocketmq/data/namesrv/store

3.启动NameServer

docker run -d \
--restart=always \
--name rmqnamesrv  \
-p 9876:9876 \
-v /docker/rocketmq/data/namesrv/logs:/root/logs \
-v /docker/rocketmq/data/namesrv/store:/root/store \
-e "MAX_POSSIBLE_HEAP=100000000" \
rocketmqinc/rocketmq \
sh mqnamesrv

4.编辑border配置

vim /docker/rocketmq/conf/broker.conf

# 所属集群名称，如果节点较多可以配置多个
brokerClusterName = DefaultCluster 
#broker名称，master和slave使用相同的名称，表明他们的主从关系 
brokerName = broker-a 
#0表示Master，大于0表示不同的
slave brokerId = 0 
#表示几点做消息删除动作，默认是凌晨4点 
deleteWhen = 04 
#在磁盘上保留消息的时长，单位是小时 
fileReservedTime = 48 
#有三个值：SYNC_MASTER，ASYNC_MASTER，SLAVE；同步和异步表示Master和Slave之间同步数据的机 制；
brokerRole = ASYNC_MASTER 
#刷盘策略，取值为：ASYNC_FLUSH，SYNC_FLUSH表示同步刷盘和异步刷盘；SYNC_FLUSH消息写入磁盘后 才返回成功状态，ASYNC_FLUSH不需要；
flushDiskType = ASYNC_FLUSH 
# 设置broker节点所在服务器的ip地址 
brokerIP1 = 192.168.66.100
#剩余磁盘比例 
diskMaxUsedSpaceRatio=99

5.启动broker

docker run -d --restart=always --name rmqbroker --link rmqnamesrv:namesrv -p 10911:10911 -p 10909:10909 --privileged=true -v /docker/rocketmq/data/broker/logs:/root/logs -v /docker/rocketmq/data/broker/store:/root/store -v /docker/rocketmq/conf/broker.conf:/opt/rocketmq-4.4.0/conf/broker.conf -e "NAMESRV_ADDR=namesrv:9876" -e "MAX_POSSIBLE_HEAP=200000000" rocketmqinc/rocketmq sh mqbroker -c /opt/rocketmq-4.4.0/conf/broker.conf

6.关闭防火墙(或者开放端口)

#关闭防火墙 
systemctl stop firewalld.service 
#禁止开机启动 
systemctl disable firewalld.service

7.部署RocketMQ的管理工具

#创建并启动容器 
docker run -d --restart=always --name rmqadmin -e "JAVA_OPTS=-Drocketmq.namesrv.addr=192.168.66.100:9876 -Dcom.rocketmq.sendMessageWithVIPChannel=false" -p 8080:8080 pangliang/rocketmq-console-ng

项目准备

1.创建Maven父项目，创建子工程，大家自行创建
2.引入依赖

  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>com.baomidou</groupId>
      <artifactId>mybatis-plus-boot-starter</artifactId>
    </dependency>
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
    </dependency>
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
    </dependency>
    <dependency>
      <groupId>org.apache.rocketmq</groupId>
      <artifactId>rocketmq-spring-boot-starter</artifactId>
      <version>2.0.1</version>
    </dependency>
    <!--  引入nacos依赖 -->
    <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
  </dependencies>

3.编写主启动类

@EnableDiscoveryClient
@MapperScan("com.itbaizhan.payment.mapper")
@SpringBootApplication
@Slf4j
public class PayMain7071 {
  public static void main(String[] args) {
    SpringApplication.run(PayMain7071.class,args);
    log.info("*********** 充值服务启动成功 *********");
   }
}

4.编写配置文件

server:
  port: 7071
spring:
  cloud:
   nacos:
    discovery:
     server-addr: 192.168.66.100:8848
  application:
   name: tx-notifymsg-pay
  datasource:
   url: jdbc:mysql://192.168.66.100:3306/tx-notifymsg-payment?useUnicode=true&characterEncoding=UTF-8&useOldAliasMetadataBehavior=true&autoReconnect=true&failOverReadOnly=false&useSSL=false
   username: root
   password: 123456
   driver-class-name: com.mysql.cj.jdbc.Driver




################ RocketMQ 配置 ##########
rocketmq:
  name-server: 192.168.66.100:9876
  producer:
   group: payment-group

5.充值微服务的业务逻辑层主要完成充值的业务逻辑处理，当充值成功时，会向RocketMQ发送充值结果信息，同时提供业务逻辑层查询充值结果信息的接口。编写充值接口。

public interface IPayInfoService extends IService<PayInfo> {
  /**
   * 保存充值信息
   */
  PayInfo savePayInfo(PayInfo payInfo);
  /**
   * 查询指定的充值信息
   */
  PayInfo getPayInfoByTxNo(String txNo);
}

重点一

6.充值接口实现

@Slf4j
@Service
public class PayInfoServiceImpl extends ServiceImpl<PayInfoMapper, PayInfo> implements IPayInfoService {
  @Resource
  private PayInfoMapper payInfoMapper;
  @Resource
  private RocketMQTemplate rocketMQTemplate;
  @Override
  public PayInfo savePayInfo(PayInfo payInfo) {
    payInfo.setTxNo(UUID.randomUUID().toString().replace("-",""));
    payInfo.setPayResult("success");
    payInfo.setPayTime(LocalDateTime.now());
    int count = payInfoMapper.insert(payInfo);
    //充值信息保存成功
    if(count > 0){
      log.info("充值微服务向账户微服务发送结果消息");
      //发送消息通知账户微服务
      rocketMQTemplate.convertAndSend("topic_nofitymsg", JSON.toJSONString(payInfo));
      return payInfo;
     }
    return null;
   }
  @Override
  public PayInfo getPayInfoByTxNo(String txNo) {
    return baseMapper.selectById(txNo);
   }
}

7.编写充值接口

@RestController
@RequestMapping("/payInfo")
public class PayInfoController {


  @Autowired
  private IPayInfoService payInfoService;


  /**
   * 充值
   * @param payInfo
   * @return
   */
  @GetMapping(value = "/pay_account")
  public PayInfo pay(PayInfo payInfo){
    //生成事务编号
    return payInfoService.savePayInfo(payInfo);
   }


  /**
   * 查询充值结果
   * @param txNo
   * @return
   */
  @GetMapping(value = "/query/payresult/{txNo}")
  public PayInfo payResult(@PathVariable("txNo") String txNo){
    return payInfoService.getPayInfoByTxNo(txNo);
   }
}

8.创建子工程account，引入依赖

  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>com.baomidou</groupId>
      <artifactId>mybatis-plus-boot-starter</artifactId>
    </dependency>
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
    </dependency>
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
    </dependency>
    <dependency>
      <groupId>org.apache.rocketmq</groupId>
      <artifactId>rocketmq-spring-boot-starter</artifactId>
      <version>2.0.1</version>
    </dependency>
    <!--   引入Nacos注册中心   -->
    <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
    <!--   引入OpenFeign -->
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-openfeign</artifactId>
    </dependency>
    <!--   引入负载均衡器-->
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-loadbalancer</artifactId>
    </dependency>
  </dependencies>

9.编写配置文件

server:
  port: 7070
spring:
  cloud:
   nacos:
    discovery:
     server-addr: 192.168.66.100:8848
  application:
   name: tx-notifymsg-account
  datasource:
   url: jdbc:mysql://192.168.66.100:3306/tx-notifymsg-account?useUnicode=true&characterEncoding=UTF-8&useOldAliasMetadataBehavior=true&autoReconnect=true&failOverReadOnly=false&useSSL=false
   username: root
   password: 123456
   driver-class-name: com.mysql.jdbc.Driver
################ RocketMQ 配置 ##########
rocketmq:
  name-server: 192.168.66.100:9876

重点二

10.RocketMQ消费充值信息

@Slf4j
@Component
@RocketMQMessageListener(consumerGroup = "consumer_group_account", topic = "topic_nofitymsg")
public class NotifyMsgAccountListener implements RocketMQListener<String> {
  @Autowired
  private IAccountInfoService accountInfoService;
  @Override
  public void onMessage(String message) {
    log.info("账户微服务收到RocketMQ的消息:{}", JSONObject.toJSONString(message));
    //如果是充值成功，则修改账户余额
    PayInfo payInfo = JSON.parseObject(message, PayInfo.class);
    if("success".equals(payInfo.getPayResult())){
      accountInfoService.updateAccountBalance(payInfo);
     }
    log.info("更新账户余额完毕:{}", JSONObject.toJSONString(payInfo));
   }
}

11.编写账户操作接口

 /**
   * 更新账户余额
   */
  void updateAccountBalance(PayInfo payInfo);

12.实现账户操作接口

@Slf4j
@Service
public class AccountInfoServiceImpl extends ServiceImpl<AccountInfoMapper, AccountInfo> implements IAccountInfoService {
  @Resource
  private AccountInfoMapper accountInfoMapper;
  @Resource
  private PayInfoMapper payInfoMapper;
  /**
   *
   * @param payInfo
   */
  @Transactional(rollbackFor = Exception.class)
  @Override
  public void updateAccountBalance(PayInfo payInfo) {
    if(payInfoMapper.selectById(payInfo.getTxNo()) != null){
      log.info("账户微服务已经处理过当前事务...");
      return;
     }
    LambdaUpdateWrapper<AccountInfo> lambdaUpdateWrapper = new LambdaUpdateWrapper<>();
    lambdaUpdateWrapper.eq(AccountInfo::getAccountNo,payInfo.getAccountNo());
    //更新账户余额
    List<AccountInfo> accountInfos = baseMapper.selectList(lambdaUpdateWrapper);
    if (accountInfos != null && !accountInfos.isEmpty()){
      AccountInfo accountInfo = accountInfos.get(0);
      accountInfo.setAccountBalance(accountInfo.getAccountBalance().add(payInfo.getPayAmount()));
      accountInfoMapper.updateById(accountInfo);
     }
    //保存充值记录
    payInfoMapper.insert(payInfo);
   }
}

13.主启动类加Feign注解

@EnableDiscoveryClient
@EnableFeignClients
@MapperScan("com.itbaizhan.account.mapper")
@SpringBootApplication
@Slf4j
public class AccountMain7070 {
  public static void main(String[] args) {
    SpringApplication.run(AccountMain7070.class,args);
    log.info("*********** AccountMain7070 启动成功 *********");
   }
}

14.编写远程调用接口

@Service
@FeignClient("tx-notifymsg-pay")
public interface IPayFeignService {
  @GetMapping(value = "/payInfo/query/payresult/{txNo}")
  PayInfo payResult(@PathVariable("txNo") String txNo);
}

15.编写查询账户接口

/**
   * 查询充值结果
   */
  PayInfo queryPayResult(String txNo);

16.实现查询账户信息

  /**
   * 查询结果
   * @param txNo
   * @return
   */
  @Override
  public PayInfo queryPayResult(String txNo) {
    try{
      return iPayFeignService.payResult(txNo);
     }catch (Exception e){
      log.error("查询充值结果异常:{}", e);
     }
    return null;
   }

17.编写查询充值结果接口

  /**
   * 主动查询充值结果
   * @param txNo
   * @return
   */
@GetMapping(value = "/query/payresult/{txNo}")
  public ResponseEntity result(@PathVariable("txNo") String txNo){
    return ResponseEntity.ok(accountInfoService.queryPayResult(txNo));
   }

总结

提示：这里对文章进行总结：

最大努力通知型分布式事务适用于一些对事务原子性要求不高，但对最终一致性有要求的场景。它提供了一种在分布式环境下处理事务的灵活方式，可以提高系统的可用性和容错能力。
需要注意的是，最大努力通知型分布式事务并不保证事务的原子性，可能会存在数据不一致的情况。在设计和实现最大努力通知型分布式事务时，需要考虑到可能的失败情况，并采取适当的补偿措施来确保最终一致性。
总的来说，最大努力通知型分布式事务是一种在分布式系统中处理事务的有效方式，它通过多次尝试来确保最终的一致性，提高了系统的可靠性和容错能力。在实际应用中，需要根据具体的业务需求和场景选择合适的事务处理方式。
希望以上博客总结对你有所帮助！如果你有任何问题或需要进一步了解最大努力通知型分布式事务，请随时提问。

键盘敲烂~~~
关注
专栏目录
分布式事务解决方案之最大努力通知
weixiaohuai的博客
01-03 318
目录 一、什么是最大努力通知？ 二、最大努力通知与可靠消息一致性有什么不同？ 三、最大努力通知解决方案 四、总结 一、什么是最大努力通知？ 最大努力通知也是解决分布式事务的一种方案，我们平常对接支付宝、微信、第三方支付系统时，通常都采用的是最大努力通知方案来保证数据最终一致性的。 如上图，是一个账户充值的例子。 交互流程大体如下： 1、账户系统调用充值系统的接口进行充值； 2、充值系统跳转支付页面； 3、账户系统发起支付请求； 4、充值系统完成支付处理； 5、充值系统发送充
SpringCloud + RocketMQ实现最大努力通知型事务
weixiaohuai的博客
01-07 396
目录 一、概述 二、案例说明和数据库、表准备 三、服务注册中心搭建 四、搭建充值微服务 五、搭建账户微服务 六、测试 七、总结 一、概述 前面一篇文章介绍了最大努力通知的整体流程和两种常见的实现方案，本篇文章我们将结合具体的案例【模拟账户充值】详细说明如何利用RocketMQ实现最大努力通知型事务。 二、案例说明和数据库、表准备 本案例有账户服务和充值服务两个微服务，其中账户服务的数据库是account数据库，其中有张三账户。充值服务的数据库使用recharge 数据库，记录了账户的充
我说分布式事务之最大努力通知型事务
程序猿DD
12-26 790
来源：http://t.cn/E4ejkSN在之前的文章中，我们介绍了基于TCC模式的分布式事务解决方案我说分布式事务之TCC 。TCC适用于公司内部对一致性、实时性要求...
最大努力通知【分布式事务解决方案】
最新发布
程序猿进阶
08-02 1431
【1】账户系统调用充值系统接口；【2】充值系统完成支付处理向账户系统发起充值结果通知，若通知失败，则充值系统按策略进行重复通知；【3】账户系统接收到充值结果通知修改充值状态[实时性与数据一致性可以延迟]；【4】账户系统未接收到通知会主动调用充值系统的接口查询充值结果[当用户查询状态时，状态为失败时，回查充值系统]发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括：【1】有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
分布式事务[4] 柔性事务：最大努力通知
MayMatrix 的博客
09-04 511
5.0 柔性事务：最大努力通知 2018-02-05 02:51:055,9560 最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。最大努力通知型的实现方案，一般符合以下特点： 1、不可靠消息：业务活动主动方，...
分布式事务解决方案之四：最大努力通知
深圳克林斯曼
12-15 369
（自学笔记） -------------------- 6.1.什么是最大努力通知 最大努力通知也是一种解决分布式事务的方案，下边是一个是充值的例子： 交互流程: 1、账户系统调用充值系统接口 2、充值系统完成支付处理向账户系统发起充值结果通知 若通知失败，则充值系统按策略进行重复通知 3、账户系统接收到充值结果通知修改充值状态。 4、账户系统未接收到通知会主动调用充值系统的接口查询充值结果。 通过上边的例子我们总结最大努力通知方案的目标： 目标：..
分布式事务最大努力通知
woshiwjma956的博客
07-08 574
分布式事务 最大努力通知
分布式事务模型--最大努力通知型分布式事务
wh柒八九的博客
08-04 440
本文来说下分布式事务模型之最大努力通知型分布式事务 文章目录概述最大努力通知型分布式事务举个例子特点剖析本文小结 概述 事务是一组不可分组的操作集合，这些操作要么都成功执行，要么都取消执行。最典型的需要事务的场景是银行账户间的转账：假如 A 账户要给 B 账户转账 100 元，那么 A 账户要扣减 100 元，B 账户要增加 100 元，这两个账户的数据变更都成功才可算作转账成功。更严格来说，可以用 ACID 四个特性表述事务： Atomicity：原子性，事务中的所有操作要么都成功执行，要么都.
分布式事务之最大努力通知
vx539413949的博客
04-04 798
最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。 最大努力通知 最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。最大努力通知型的实现方案，一般符合以下特点： 不可靠消息：业务活动主动方，在完成业务
分布式柔性事务之最大努力通知事务详解
02-24
咱们今天聊聊分布式事务系列中的最后一个方案：最大努力通知事务。最大努力通知事务的主流实现仍是基于MQ来进行事务控制。最大努力通知事务和事务消息都是通知型事务，主要适用于那些需要异步更新数据，并且对数据的...
分布式事务解决方案之最大努力通知 上篇
vincent
04-02 2762
最大努力通知正向流程 材料摘自龙果学院：http://www.roncoo.com/用到的服务模式可查询操作方案特点业务活动的主动方在完成业务处理后，向业务活动的被动方发送通知消息（允许消息丢失）主动方可以设置时间梯形通知规则，在通知失败后按规则重复通知，直到通知N次后不在通知主动方必须提供校对接口给被动发校对查询，用户恢复丢失的业务消息行业案例银行通知，商户通知（各大交易平台商户通知：多次通知...
分布式事务seata，TCC，最大努力通知，最终一致性解决方案——总结三！
zhangkaixuan456的博客
08-27 1300
前面两篇博客有各个解决方案的具体细节分析： https://blog.csdn.net/zhangkaixuan456/article/details/108210071 https://blog.csdn.net/zhangkaixuan456/article/details/108226170 分布式事务对比分析: 在介绍各种分布式事务的解决方案后，我们了解到各种方案的优缺点： 2PC 最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定，此时服务会阻塞并锁定资...
最大努力通知-实现分布式事务
刘皇叔说Java的博客
12-23 1028
最大努力通知方案的目标，就发起通知方通过一定机制，最大努力将业务处理结果通知到收方。最大努力通知（Best Effort Notification，BEN）：它是一种不保证强一致性的方法，通过异步通知来达到尽量保证事务的一致性，即尽力保证事务成功，但不能完全保证。最大努力通知：这是一种通过消息中间件实现分布式事务的方案，主要应用在金融交易场景中。分布式事务最大努力通知（Best Effort Delivery）是一种分布式系统中处理事务的方法。
分布式事务解决方案之最大努力通知 下篇
weixin_30278237的博客
04-02 152
背景：订单完成支付，通知商户商户系统接口必须实现幂等性订单服务提供商户订单查询接口流程：消息生产端：完成事件 -> 调用消息服务，发送消息消息消费端：接收消息 -> 调用通知服务（判断该消息未保存过，保存通知消息）-> 构建通知task (delayqueue通知队列) -> 调用消息服务确认消息利用delayqueue 阻塞队列执行通知，...
分布式事务--最大努力通知
Orz..一入码门深似海
08-22 281
参照事务的基本特性，分析基于消息系统模型之最大努力通知模型。 1.事务的特性 A(Atomicity)：事务中的全部操作都是一个原子操作序列，要么一起成功，要么一起失败。其中任何一个操作失败，之前已经成功操作也会回滚到操作之前的状态。 C(Consistency)：事务的执行结果从一个状态切换到另一个状态，当事务完成后各操作结果的状态都是操作成功的状态或操作之前的状态时，就可以说是满足一致性...
分布式事务（五）之最大努力通知
小明的博客
11-09 570
最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。 最大努力通知 最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。最大努力通知型的实现方案，一般符合以下特点： 不可靠消息：业务活动主动方，在完成业务
分布式事务解决方案(四)【最大努力通知】
极客神殿
07-31 773
4. 最大努力通知方案(定期校对) 4.1 介绍 实现 业务活动的主动方,在完成业务活动处理后,向业务活动被动方发送消息,允许消息丢失 业务活动的被动方根据定时策略,向业务活动的主动方查询,恢复丢失的业务消息 约束:被动方的业务处理结果不影响主动方的业务处理 成本:业务查询与校对系统建设成本 适用范围 对时间敏感性较低的业务 对账 用到的服务模式:可查询操作 方案特点 业务活动...
分布式事务解决方案----最大努力通知解决方案
weixin_34343689的博客
08-09 165
2019独角兽企业重金招聘Python工程师标准>>> ...
微服务下分布式事务策略：从XTS到最大努力通知
3. 两阶段提交（2PC）和最大能力通知型：前者是经典的分布式事务协议，而最大能力通知型通常用于跨平台通知，即使在某些环节失败也能尽可能通知其他系统。 在技术选型方面，文章提到了Dubbo、Spring、Spring MVC、...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值