In this video, learn about Azure Service Queues, including workflow, considerations, and message retrieval options. The lesson concludes with demonstration of implementing and configuring a service queue.
- [Presenter] Let's spend some time exploring Azure Service Bus Queues, which are a part of that Service Bus messaging service that we covered in the previous lesson. Queues are a messaging as a service function in Azure. You may see the acronym for messaging as a service as MaaS. Queues provide asynchronous communications. Meaning messages only go in one direction. And we use them to connect a front end, or the sender, to a back end, the receiver.
As we can see in our example here we have our message sender and this could be a web app, mobile app, or a service. And messages will be delivered to that queue, that is sitting in our service box namespace. And then the message receiver, which could be a service or application, will then pull that message. And these messages are processed in a first in, first out sequence, or FIFO. That means that the first message that is delivered into that queue will be the first message that is retrieved, by the receiver.
When we use queues, the messages stay in the queue until it is retrieved by that service or application. And the sender/receiver do not have to be online at the same time for this to work. Heck, they may not even know that each of those other services exist. This allows for true decoupling of that application. Let's go ahead and take a look at the workflow. Our sender will send the message to the queue. The queue will acknowledge the message back to the sender. Then that queue will store the message.
So it sits there until the receiver connects and retrieves that message. When designing your applications for queues, there are a few considerations you need to be aware of. First, your maximum message size can only be 256 kilobytes in the standard tier, and 1 megabyte if you use the premium tier. No matter what tier you're working with, the maximum header size is only 64 kilobytes. And there is no limit to the number of messages that can stored in that queue.
But the total size of all the messages in the queue maxes out at 5 gigabytes. We have two options when we configure receivers for using queues. Our first option's called receive and delete. When we enable this option the message is removed and deleted after retrieval from that queue. That means, after it's processed, it's gone. The message is done. It's not coming back. Our other option for a receiver is to set peek and lock to true.
When we use peek and lock the message is removed but not deleted, and it is locked therefore it cannot be delivered. When we use peek and lock we set up a lock duration period and the message will be delivered after that duration period is over. Typically we'll enable peek and lock when the application cannot tolerate missing messages. Sometimes you'll hear this referred to as at-least-once delivery. And we do have a subqueue called the dead-letter queue.
And this dead-letter queue will contain messages that cannot be delivered. Or messages that cannot be processed. This provides you the opportunity to review those messages and determine how they should be handled. Cleaning up that dead-letter queue is not an automatic process, it is a manual process. And you must explicitly retrieve those messages in order to clean up that dead-letter queue or the DLQ. Let's go ahead and create a queue in Azure.
We're looking at our LiL messaging resource group and we have the Service Bus, Lil namespace that we created in the last lesson. Let's go ahead and open up the Lil namespace Service Bus queue. You'll notice that we do not have any queues or topics within this namespace. We can go ahead and quickly add a queue by moving up to the top and clicking on plus queue. I'm going to go ahead and provide a name.
We're going to provide the name Lil Queue. Remember the maximum size of the queue, that we discussed a few moments ago. This is where we set it. We'll set it to the maximum of 5 gigabytes. Our default for a message time to live is 14 days. But you can adjust that as required. Next, we can go ahead and set the lock duration. We can do it by seconds or minutes. I'll leave it as is. We can move expired messages to the dead-letter subqueue.
We can enable duplicate detection, if we need to do so. We can enable sessions. Which will allow us to route specific messages to certain receivers. And we can enable partitioning. Which will distribute the queue items to the various receivers. You can go ahead and click create. This will take a moment. Our queue is now created. We can go ahead, open the blade for it. And in our overview you'll notice that we do not have anything here.
As we do not have any senders set up, or this queue configured to receive messages. To quickly recap, queues allow us to decouple the front end and back ends of our applications. Messages are processed in the first in, first out sequence. And messages will sit in that queue until the receiver retrieves them.
- Creating compute-intensive applications
- Creating long-running applications
- Implementing messaging systems
- Azure Service Bus relays
- Using Azure Storage queues
- Creating an Azure Event Hub
- Creating Azure WebJobs
- Managing cloud environments with Azure Active Directory Domain Services