Oracle Cloud Infrastructure (OCI) Queue is a serverless asynchronous messaging service designed to handle large volumes of data with multiple concurrent producers and consumers of messages. When multiple producers and consumers are processing messages within the same queue, challenges can arise, such as the following examples:
◉ An aggressive producer or a sudden volume burst from one producer can impact the performance of the application and cause a significant processing delay for messages coming from other producers.
◉ Certain request-response messaging patterns need ephemeral destinations, which are short-lived queues and meant for processing messages temporarily. While processing these messages in bulk, creating and deleting these short-lived queues can significantly increase the administrative overhead.
◉ When a queue has multiple consumers, individual consumers might be interested in consuming only certain types of messages or those coming from a specific producer, requiring developers to design a complex solution with multiple queues dedicated to each consumer type.
New: Channels in OCI Queue
To overcome these challenges, we’re announcing a new capability in OCI Queue: Queue channels. Channels enable ephemeral destinations within a queue and can improve message processing fairness, enable message selection, and request-response messaging patterns.
Messages published to a channel are available for consumption from both the queue and channel level. Channels don’t require explicit creation or deletion. While publishing a message, you can choose to specify a channel ID. All messages created with the same channel ID are published to the same channel. Channels are ephemeral, and if no messages are in a particular channel, the channel is deleted automatically. Channels share the same permissions, encryption method, and limits as their parent queue, but the queues can configure channel capacity, limiting the maximum amount of the queue’s overall capacity that a single channel can use at any time.
Enabling message processing fairness
When multiple producers are producing to the same queue, a sudden spike in message volume from one producer can cause a significant delay in processing messages from other producers. Sometimes, the application acts as a middleware for the end users, using a queue-per-end-user pattern, which requires the application to protect message consumption from skewing in favor of customers with higher traffic—the noisy neighbor problem.
In the following diagram, when the message producer (P1) starts producing messages in bulk, the messages from other producers (P2 or P3) can see a significant delay in processing.
To consume messages from all the producers evenly and ensure message processing fairness, you must maintain separate queues for each producer type and implement a load balancing mechanism to consume messages evenly.
With the introduction of channels, producers can now publish messages to a specific channel. When a consumer consumes messages from a queue without specifying a channel ID, the messages are returned from a random channel that has available messages. This separation not only helps increase fairness and protect against sudden volume spikes, but it allows you to use long polling for more effective data consumption.
Enabling message selection
You can include an optional parameter in requests to select messages that were published with the matching the channel ID. OCI Queue returns available messages only from one of the channels that match the ID.
If multiple channels’ IDs match the selection in a request, messages are returned from a random channel that has available messages. If messages are published to a specific channel, but a consumption request doesn’t include a channel, messages are returned from a random channel with available messages.
Enabling Ephemeral Queues for Request-Response Pattern
The request-response ephemeral pattern is a well-established integration pattern that enables the sender application to send a request and provides a way for the receiver to correctly send a response back to the sender application. This pattern typically needs a short-lived queue or topic for the application to send responses to. Channels provide a simple solution that lets you create and delete multiple channels, which can be short-lived, without making any explicit CreateQueue or DeleteQueue API calls.
Multiple applications can send their requests to a single request queue, with a specific channel ID parameter set to uniquely identify the sender application. The receiver application can process the requests and send replies with the channel ID parameter to uniquely identify the sender that had published the message. The application that sent the request can then receive messages on the specific channel ID and correctly process the replies. When the message processes successfully and the consumer deletes it, the channel is automatically deleted if it has no more messages to process.
Getting started with OCI Queue channels
Queue creation and channel capacity allocation
When creating or updating a queue, you can specify the percentage allocation for a channel to limit the maximum amount of the queue’s overall capacity that the channel can use at any time. By default, the limit is set as 100%, which means the channel can take up the entire queue’s bandwidth. If you set it up to 50%, the channel can take up only 50% of the queue’s bandwidth.
Sending messages to a specific channel
You can send messages to a specific channel. If the channel doesn’t already exist, you can create another channel by specifying a channel ID while sending the message. If the channel ID isn’t specified, the message is sent to the parent queue.
Listing channels
View the list of channels from the Channels page.
Poll for messages from channels
From the Channels List page, poll message from a random or from a specific channel.
Purge channel messages
You can purge messages from a specific channel using the Action menu of the specific channel.
Source: oracle.com
Posts
0 comments:
Post a Comment