Azure supports two types of queue mechanisms: Storage queues and Service Bus queues.
Azure Storage queues are part of the Azure storage infrastructure, have a REST-based interface, provide persistent and reliable messaging. Storage queue is bare minimum FIFO cloud data structure and was introduced before the Service Bus. Azure Service Bus consists of messaging entities like Queues and Topics. They are used for integration between various applications that solve a business problem.
Service Bus Queues follow FIFO mechanism to which messages can be sent and can be received from them. The messages can be either received in peek lock mode without deleting the message from the queue or it can be removed by receiving it in receive and delete mode. Service Bus Topics are similar to queues . Each topic may have many subscriptions within it . So the message sent to the topic is received by all the topic subscriptions. We can restrict the subscription to receive only particular messages by creating appropriate subscription rules
Technology selection considerations (Storage queue vs. Service bus queue)
Both Storage queues and Service Bus queues are implementations of the message queuing service currently offered by Microsoft Azure. Each has a slightly different feature set, which means you can choose one or the other, or use both, depending on the needs of your particular solution or business/technical problem you are solving.
You should consider using Storage queues when:
Your application must store over 80 GB of messages in a queue.
Your application wants to track progress for processing a message inside of the queue. This is useful if the worker processing a message crashes. A subsequent worker can then use that information to continue from where the prior worker left off.
You require server side logs of all of the transactions executed against your queues.
You should consider using Service Bus queues when:
Your queue size will not grow larger than 80 GB.
Your solution must be able to receive messages without having to poll the queue. With Service Bus, this can be achieved through the use of the long-polling receive operation using the TCP-based protocols that Service Bus supports.
Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
Your solution must be able to support automatic duplicate detection.
You want your application to process messages as parallel long-running streams (messages are associated with a stream using the SessionId property on the message). In this model, each node in the consuming application competes for streams, as opposed to messages. When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions. Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
Your application handles messages that can exceed 64 KB but will not likely approach the 256 KB limit.
You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers.
You want to use the AMQP 1.0 standards-based messaging protocol.
You can envision an eventual migration from queue-based point-to-point communication to a message exchange pattern that enables seamless integration of additional receivers (subscribers), each of which receives independent copies of either some or all messages sent to the queue.
Your messaging solution must be able to support the "At-Most-Once" delivery guarantee without the need for you to build the additional infrastructure components.
You would like to be able to publish and consume batches of messages.
References:
Comentários