RabbitMQ and EasyNetQ

Editor's Notes

• #4: SpringSource is a division of VMWareMessage Broker = MOM = Message Oriented MiddlewareMOM is software or hardware infrastructure supporting sending and receiving messages between distributed systems.Erlang – functional languagedesigned by Ericsson to support distributed, fault-tolerant, soft-real-time, non-stop applications. It supports hot swapping, so that code can be changed without stopping a system.The RabbitMQ project consists of:The RabbitMQ exchange server itselfGateways for HTTP, STOMP, and MQTT protocolsAMQP client libraries for Java, .NET Framework, and Erlang. (AMQP clients for other languages are available from other vendors)A plug-in platform for custom additions, with a pre-defined collection of supported plug-ins, including: a "Shovel" plug-in that takes care of copying (replicating) messages from one broker to anothera "Federation" plug-in that enables efficient sharing of messages between brokers (at the exchange level)a "Management" plug-in that enables monitoring and control of brokers and clusters of brokers.
• #5: AMQP is a wire-level protocol. A wire-level protocol is a description of the format of the data that is sent across the network as a stream of octets. Consequently any tool that can create and interpret messages that conform to this data format can interoperate with any other compliant tool irrespective of implementation language.Examples of wire protocols areIIOP for CORBAJRMP for RMISOAP for Web ServicesAMQP for Message Oriented Middleware
• #9: Management server at: http://localhost:15672/Exchanges route to queuesRouting is based on Exchange and Queue configurationhttp://www.rabbitmq.com/management.html
• #10: Best analogy for RabbitMQ
• #11: 4 main exchange types in RabbitMQ
• #12: A direct exchange delivers messages to queues based on the message routing key. A direct exchange is ideal for the unicast routing of messages (although they can be used for multicast routing as well). Direct exchanges are often used to distribute tasks between multiple workers (instances of the same application) in a round robin manner. When doing so, it is important to understand that, in AMQP 0-9-1, messages are load balanced between consumers and not between queues.
• #13: A fanout exchange routes messages to all of the queues that are bound to it and the routing key is ignored. If N queues are bound to a fanout exchange, when a new message is published to that exchange a copy of the message is delivered to all N queues. Fanout exchanges are ideal for the broadcast routing of messages. Because a fanout exchange delivers a copy of a message to every queue bound to it, its use cases are quite similar: Massively multi-player online (MMO) games can use it for leaderboard updates or other global eventsSport news sites can use fanout exchanges for distributing score updates to mobile clients in near real-timeDistributed systems can broadcast various state and configuration updatesGroup chats can distribute messages between participants using a fanout exchange (although AMQP does not have a built-in concept of presence, so XMPP may be a better choice)
• #14: A headers exchange is designed for routing on multiple attributes that are more easily expressed as message headers than a routing key. Headers exchanges ignore the routing key attribute. Instead, the attributes used for routing are taken from the headers attribute. A message is considered matching if the value of the header equals the value specified upon binding. It is possible to bind a queue to a headers exchange using more than one header for matching. In this case, the broker needs one more piece of information from the application developer, namely, should it consider messages with any of the headers matching, or all of them? This is what the "x-match" binding argument is for. When the "x-match" argument is set to "any", just one matching header value is sufficient. Alternatively, setting "x-match" to "all" mandates that all the values must match. Headers exchanges can be looked upon as "direct exchanges on steroids". Because they route based on header values, they can be used as direct exchanges where the routing key does not have to be a string; it could be an integer or a hash (dictionary) for example.
• #15: Topic exchanges route messages to one or many queues based on matching between a message routing key and the pattern that was used to bind a queue to an exchange. The topic exchange type is often used to implement various publish/subscribe pattern variations. Topic exchanges are commonly used for the multicast routing of messages. Topic exchanges have a very broad set of use cases. Whenever a problem involves multiple consumers/applications that selectively choose which type of messages they want to receive, the use of topic exchanges should be considered. Example uses: Distributing data relevant to specific geographic location, for example, points of saleBackground task processing done by multiple workers, each capable of handling specific set of tasksStocks price updates (and updates on other kinds of financial data)News updates that involve categorization or tagging (for example, only for a particular sport or team)Orchestration of services of different kinds in the cloudDistributed architecture/OS-specific software builds or packaging where each builder can handle only one architecture or OS
• #16: Queues in the AMQP model are very similar to queues in other message- and task-queueing systems: they store messages that are consumed by applications. Queues share some properties with exchanges, but also have some additional properties: NameDurable (the queue will survive a broker restart)Exclusive (used by only one connection and the queue will be deleted when that connection closes)Auto-delete (queue is deleted when last consumer unsubscribes)Arguments (some brokers use it to implement additional features like message TTL)Before a queue can be used it has to be declared. Declaring a queue will cause it to be created if it does not already exist. The declaration will have no effect if the queue does already exist and its attributes are the same as those in the declaration. When the existing queue attributes are not the same as those in the declaration a channel-level exception with code 406 (PRECONDITION_FAILED) will be raised.
• #17: Some applications need multiple connections to an AMQP broker. However, it is undesirable to keep many TCP connections open at the same time because doing so consumes system resources and makes it more difficult to configure firewalls. AMQP 0-9-1 connections are multiplexed with channels that can be thought of as "lightweight connections that share a single TCP connection". For applications that use multiple threads/processes for processing, it is very common to open a new channel per thread/process and not share channels between them. Communication on a particular channel is completely separate from communication on another channel, therefore every AMQP method also carries a channel number that clients use to figure out which channel the method is for (and thus, which event handler needs to be invoked, for example). ---To make it possible for a single broker to host multiple isolated "environments" (groups of users, exchanges, queues and so on), AMQP includes the concept of virtual hosts (vhosts). They are similar to virtual hosts used by many popular Web servers and provide completely isolated environments in which AMQP entities live. AMQP clients specify what vhosts they want to use during AMQP connection negotiation.
• #18: 15below is a travel industry company used by JetBlue, Quantas, AirTran, Frontier and others..NET + RabbitMQ Scales to100s of Millions of Passenger Messages at 15below
• #19: So why do I need EasyNetQ? The RabbitMQ .NET client implements the client side of the AMQP protocol (and RabbitMQ implements the server side). AMQP is intended as the HTTP of messaging. It is designed to be cross platform and language agnostic. It is also designed to flexibly support a wide range of messaging patterns based on the Exchange/Binding/Queue model. ---Typically this code would include:Implementing messaging patterns such as Publish/Subscribe or Request/Response. Although, to be fair, the .NET client does provide some support here. Implement a routing strategy. How will you design your exchange-queue bindings, and how will you route messages between producers and consumers? Implement message serialization/deserialization. How will you convert the binary representation of messages in AMQP to something your programming language understands? Implement a consumer thread for subscriptions. You will need to have a dedicated consumer loop waiting for messages you have subscribed to. How will you deal with multiple subscribers, or transient subscribers, like those waiting for responses from a request? Implement a versioning strategy for your messages. What happens when your message schema needs to change in response to business requirements? Implement subscriber reconnection. If the connection is disrupted or the RabbitMQ server bounces, how do you detect it and make sure all your subscriptions are rebuilt? Understand and implement quality of service settings. What settings do you need to make to ensure that you have a reliable client. Implement an error handling strategy. What should your client do if it receives a malformed message, or if an unexpected exception is thrown? Implement monitoring tools. How will you monitor your client applications so that you are alerted if there are any problems? ---It’s great having this flexibility, but with flexibility comes complexity. It means that you will need to write a significant amount of code in order to implement a RabbitMQ client.
• #20: Conventions -> Messages are types (classes) and are routed by their type.
• #22: Any questions