Azure Messaging-ServiceBus Messaging消息队列技术系列7-消息事务

上篇博文中我们介绍了Azure Messaging-ServiceBus Messaging消息回执机制。

Azure Messaging-ServiceBus Messaging消息回执机制

本文中我们主要研究消息的事务。直奔主题:

  • Service Bus Queues支持事务,基于TransactionScope
  • Service Bus Queues provide support for local transactions in the context of a single queue.
  • 事务的限制:事务只能包含一个Queue或者Topic,订阅不能放在事务中,同时事务不支持其他系统,例如数据库

那消息事务的实际应用场景有哪些呢?例如:

1.启动一个事务性的会话,将发送更新订单状态消息和更新账户余额消息放到一个事务中,消息发送失败后 rollback,确认消息未被发送。
2.发送更新订单状态消息和更新账户余额消息成功后,启动一个事务性的会话,接收并处理这两条消息。

那我们先从同一个队列中发送多条消息这个场景验证:

 1   public static void SendMessageTransactional()
 2         {
 3             var sbUtils = new ServiceBusUtils();
 4
 5             //创建队列
 6             sbUtils.CreateQueue(queueName, false);
 7
 8             //多次发送消息到OrderQueue
 9             var queueSendClient = sbUtils.GetQueueClient(queueName);
10
11             using (var trans = new TransactionScope())
12             {
13                 var order1 = CreateSalesOrder(1);
14                 var order2 = CreateSalesOrder(2);
15                 var message1 = sbUtils.Create(order1);
16                 var message2 = sbUtils.Create(order2);
17                 queueSendClient.Send(message1);
18                 queueSendClient.Send(message2);
19                 Console.WriteLine("Send but uncomplete!");
20                 trans.Complete();
21
22                 Console.WriteLine("Complete!");
23             }
24         }

发送消息完成,但是未提交事务前,队列是这样的:

事务提交后Complete:

然后,我们继续研究验证同一个队列接收消息的事务性:有个前提要求:

消息接收时,如果启动事务,消息消费接收模式必须是PeekAndLock模式。

消息接收完成,如果事务不Complete,消息仍旧在消息队列中。

 1 public static void ReceiveMessageTransactional()
 2         {
 3             var sbUtils = new ServiceBusUtils();
 4             var queueReveiveClient = sbUtils.GetReceiveQueueClient(queueName, ReceiveMode.PeekLock);
 5             using (var trans = new TransactionScope())
 6             {
 7                 var message1 = queueReveiveClient.Receive();
 8                 message1.Complete();
 9                 var message2 = queueReveiveClient.Receive();
10                 message2.Complete();
11                 Console.WriteLine("Received but uncomplete!");
12                 trans.Complete();
13
14                 Console.WriteLine("Complete!");
15             }
16         }

当接收完消息,事务未提交时:

队列中的消息是:

事务提交后:

Azure Service Bus 中消息:

消息已经被消费。

以上就是Azure ServiceBus 中对消息事务的支持。

2017/3/30

时间: 2024-10-18 05:04:54

Azure Messaging-ServiceBus Messaging消息队列技术系列7-消息事务的相关文章

Azure Messaging-ServiceBus Messaging消息队列技术系列8-服务总线配额

上篇博文中我们介绍了Azure ServiceBus Messaging的消息事务机制: Azure Messaging-ServiceBus Messaging消息队列技术系列7-消息事务(2017-03-30 22:12) 本文中我们介绍一下ServiceBus Messaging的一些配额,或者说使用说明和限制.原文请参考: https://docs.microsoft.com/zh-cn/azure/service-bus-messaging/service-bus-quotas 我们着

Azure Messaging-ServiceBus Messaging消息队列技术系列3-消息顺序保证

上一篇:Window Azure ServiceBus Messaging消息队列技术系列2-编程SDK入门  http://www.cnblogs.com/tianqing/p/5944573.html 介绍了Azure Service Bus的编程SDK(主要的编程接口) 本文中我们以实际的使用场景来说明Azure Messaging是否支持以及如何编码实现:消息的收发顺序保证. 消息的收发在实际业务中往往是有顺序的:发送时1-2-3-4-5,接收时也必须是1-2-3-4-5,即FIFO特性

Azure Messaging-ServiceBus Messaging消息队列技术系列6-消息回执

上篇博文中我们介绍了Azure Messaging的重复消息机制.At most once 和At least once. Azure Messaging-ServiceBus Messaging消息队列技术系列5-重复消息:at-least-once at-most-once 本文中我们主要研究并介绍Azure Messaging的消息回执机制:实际应用场景: 同步收发场景下,消息生产者和消费者双向应答模式,例如:张三写封信送到邮局中转站,然后李四从中转站获得信,然后在写一份回执信,放到中转站

Window Azure ServiceBus Messaging消息队列技术系列1-基本概念和架构

前段时间研究了Window Azure ServiceBus Messaging消息队列技术,搞了很多技术研究和代码验证,最近准备总结一下,分享给大家. 首先,Windows Azure提供了两种类型的消息队列机制:Azure Queues和ServiceBus Queues. 其中,Azure Queues,作为Azure Storage基础设施的一部分,提供了一套简单的基于Rest的Interface,面向不同的服务间提供可靠的.持久化的消息队列. ServiceBus Queues作为Az

Window Azure ServiceBus Messaging消息队列技术系列2-编程SDK入门

各位,上一篇基本概念和架构中,我们介绍了Window Azure ServiceBus的消息队列技术的概览.接下来,我们进入编程模式和详细功能介绍模式,一点一点把ServiceBus技术研究出来. 本章我们主要介绍ServiceBus的编程SDK编程入门. 首先,微软提供了两个主要的Nuget Packages: Microsoft Azure Service Bus 3.4.0 主要的NameSpace有以下几个: 1. Microsoft.ServiceBus,这个下面有两个主要的类:Tok

消息队列技术之基本概念

最近一直在总结Azure Messaging ServiceBus Messaging相关的技术:消息顺序.消息持久化.复杂对象消息的序列化.消息事务.消息回执等机制. 感觉有必要补充一篇消息队列技术的基本概念,无论RabbitMQ.ActiveMQ还是其他,都有的一些基本概念.术语.机制,分享给大家,希望大家在搞消息队列技术的时候能够快速 理解.排上用场. 1. 消息生产者.消息者.队列.主题 消息生产者Producer:发送消息到消息队列. 消息消费者Consumer:从消息队列接收消息.

消息队列技术

消息队列技术 上周,我们举办了第二届技术沙龙,我这边主要演讲了消息队列技术的议题,现分享给大家: 在我们团队内部,随着消息应用中心(任务中心)的广泛应用,有时候我们感觉不到消息队列的存在,但这不影响消息队列在高可用.分布式.高并发架构下的核心地位. 消息队列都应用到了哪些实际的应用场景中? 一.再谈消息队列的应用场景 异步处理:例如短信通知.终端状态推送.App推送.用户注册等 数据同步:业务数据推送同步 重试补偿:记账失败重试 系统解耦:通讯上下行.终端异常监控.分布式事件中心 流量消峰:秒杀

再谈消息队列技术

上周,我们举办了第二届技术沙龙,我这边主要演讲了消息队列技术的议题,现分享给大家: 在我们团队内部,随着消息应用中心(任务中心)的广泛应用,有时候我们感觉不到消息队列的存在,但这不影响消息队列在高可用.分布式.高并发架构下的核心地位. 消息队列都应用到了哪些实际的应用场景中? 一.再谈消息队列的应用场景 异步处理:例如短信通知.终端状态推送.App推送.用户注册等 数据同步:业务数据推送同步 重试补偿:记账失败重试 系统解耦:通讯上下行.终端异常监控.分布式事件中心 流量消峰:秒杀场景下的下单处

全面理解Handler第一步:理解消息队列,手写消息队列

前言 Handler机制这个话题,算是烂大街的内容.但是为什么偏偏重拿出来"炒一波冷饭"呢?因为自己发现这"冷饭"好像吃的不是很明白.最近在思考几个问题,发现以之前对Handler机制的了解是在过于浅显.什么问题? Handler机制存在的意义是什么?能否用其他方式替换? Looper.loop();是一个死循环,为什么没有阻塞主线程?用什么样的方式解决死循环的问题? 如果透彻的了解Handler,以及线程的知识.是肯定不会有这些疑问的,因为以上问题本身就存在问题.