Microsoft Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics.
Service Bus is used to decouple applications and services from each other, which help us to balance workload.
Message Bus Queues and Topics provide
With Queues, you can have multiple senders, but only one message-consumer receives and process each message.
Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components.
With Queues, there are two different modes available to process messages.
Received & Delete
This mode is suitable where the system can tolerate not processing messages in case of failure. In this mode, once the consumer service reads the message, it will be deleted from the Queue irrespective of the status of the message process.
This mode is suitable where the system cannot tolerate ignoring messages in case of failure. So here, messages are processed in two stages, as below.
Senders send messages to a topic in the same way that they send messages to a queue, but it varies on a slight factor where 'Topics' can have multiple, independent 'Subscriptions'. Subscriptions are durable by default but can be configured to expire and then be automatically deleted.
We can define rules on a subscription. A subscription rule has a filter to define a condition for the message to be copied into the subscription and an optional action that can modify message metadata.
The message size limit for Service Bus is 1 MB (premium tier).
This video (GERMAN) demonstrates how to expose Azure Service Bus as REST service by using of Azure API Management.
Enable higher throughput levels for Azure Service Bus premium via two new features in public preview today.
First, we are releasing scaling partitions, allowing the use of partitioning for the premium messaging tier. Service Bus partitions enable messaging entities to be partitioned across multiple message brokers. This means that the overall throughput of a partitioned entity is no longer limited by the performance of a single message broker. Additionally, a temporary outage of a message broker, for example during an upgrade, does not render a partitioned queue or topic unavailable, as messages will be retried on a different partition.
Second, we are making a change to our infrastructure, which will result in more consistent low latency. This is accomplished by switching our storage to a different implementation called local store. During public preview we will create partitioned namespaces using this new feature, but in the future all new namespaces will be created on local store.