RabbitMQ 6 Different application scenarios

Recent business needs to use the RABBITMQ Task Force column to implement load distribution for tasks 1.1, what is RABBITMQ.

RABBITMQ is one of the messaging middleware implementations of AMQP (Advanced Message Queuing Protocol), which is written in Erlang, and supports a variety of clients such as Python, Ruby,. NET, Java, JMS, C, PHP, ActionScript, XMPP , stomp, etc., support Ajax. Used to store forwarded messages in a distributed system. 1.2. What is AMQP?

AMQP, Advanced message Queuing Protocol, is an open standard for application-layer protocols designed for message-oriented middleware. It receives messages from producers and delivers them to consumers, and in the process, routes, caches, and persists according to rules.

There are two main components in AMQP: Exchange and Queue (which will change in AMQP 1.0), as shown in the following figure, the green X is Exchange, the red is the Queue, both on the Server side, also called the Broker, which is part R ABBITMQ is implemented, while the blue one is the client, usually there are two types of Producer and Consumer:
1.3, the basic concept of RABBITMQ

Broker: Simply speaking, Message Queuing server entities
Exchange: A message switch that specifies what rules the message is routed to which queue
Queue: Message Queuing vector, each message will be put into one or more queues
Binding: Bind, which is the role of binding exchange and queue according to routing rules
Routing key: Routing keyword, exchange message delivery based on this keyword
Vhost: Virtual host, a broker can open multiple vhost, as a separate user permissions separation
Producer: The message producer is the program that delivers the message
Consumer: The message consumer is the program that receives the message
Channel: Message channels, in each connection of the client, can establish multiple channel, each channel represents a session task

Install the configuration process, here do not repeat. RABBITMQ has six application scenarios, here to do a brief introduction Scenario 1-"Hello Word"

A p sends a message to the queue, and a C receives a message from the queue and prints it.

send.py
Producer, connect to RABBITMQ Server, declare queue, send message, close connection, exit. Application Scenario 2-work queues

By assigning time-consuming message processing to multiple consumer through a queue, we call this consumer a worker, and we refer to the queue here as a task queue, which is designed to avoid the synchronization of resource-intensive tasks, and immediately processes the task and waits for completion. Instead, the task is dispatched so that it is processed later. And the task is encapsulated into a message and sent to the task Queue,worker process runs in the background, takes out a task from the task queue and executes the job, and if more than one worker is run, the task can be allocated among multiple workers.

new_task.py
Establishes a connection, declares a queue, sends a message that can simulate time-consuming tasks, disconnects, exits.

worker.py (Same Code, multiple console, multiple server side, simultaneous execution)
Establishes a connection, declares a queue, receives a message continuously, processes the task, and confirms it. Application Scenario 3-publish/subscribe

In Scenario 2, a message (task) is passed only to a comsumer (worker). Now we try to pass a message to multiple consumer. This pattern is called publish/subscribe. Here is an example of a simple log system. The system contains a log sender and a log to receive and print the program. Messages sent by the log sender to the queue can be received by all running log recipients. Therefore, we can run a log receiver to display log directly on the screen, while another log receiver is running to write the log to the disk file.

receive_logs.py
Log message Receiver: Establishes a connection, declares exchange, binds exchange to the queue, and begins to receive log and print continuously.

emit_log.py
Log message sender: Establishes a connection, declares fanout type of exchange, sends a log message to the queue through Exchage, the message is broadcast to all recipients, closes the connection, exits. Application Scenario 4-routing

In Scenario 3, a simple log system is built to broadcast log message to more than one receiver. Now we will consider sending only the specified message type to its subscriber, for example, simply writing the error message to log file and displaying all the log messages in the console.
Application Scenario 5-topic

In the improved log system in Scenario 4, the Fanout type Exchange implementation in scenario 3 with the direct type of exchange replaces different log messages to different subscriber (that is, by different routing_ Key binds the queue to exchange so that Exchange can route different message to different queue depending on the message content. However, there are still restrictions that can not route messages based on multiple rules, such as the recipient can only receive a log message of the error type or a message of type info. If we want to log message routing not only based on log's important level such as info, warning, error, and so on, we also want to route from the source of log message, such as Auth, Cron, Kern. For this purpose, topic type of exchange is required. Topic types of Exchange can contain two special characters in Routing_key: "*" is used instead of one word, "#" for 0 or more words.

receive_logs_topic.py
Log message recipient: Establishes a connection, declares an topic type of exchange, declares a queue, constructs a routing_key based on program parameters, binds a queue to exchange according to Routing_key, loop receives and processes the message.

emit_log_topic.py
Log message sender: Establishes a connection, declares exchange of type topic, constructs Routing_key according to program parameters, and sends a message to build Routing_ Key sends a message to the topic type of exchange, closes the connection, and exits. Application Scenario 6-PRC

In Scenario 2, you describe how to use the work queue to assign time-consuming tasks to different workers. However, if our task is to run a function on a remote computer and wait for the result to be returned. The description in this scenario 2 is a completely different story. This pattern is called a remote procedure call. Now, we will build an RPC system that includes a client and an extensible RPC server to emulate the RPC service by returning the Fibonacci number.

rpc_server.py
RPC Server: Establishes a connection, declares a queue, defines a function that returns the Fibonacci number of a specified number, Defines a callback function that calls its own function that returns the Fibonacci number after receiving a call request that contains a parameter and sends the result to the queue associated with the queue that received the message, and confirms it. Begins receiving a call request and uses the callback function for request processing.

rpc_client.py
RPC Client: Remote Procedure Call Initiator: Defines a class that initializes a connection to a RABBITMQ server, declares a callback queue, begins to wait for a response on a callback queue, and defines a handler function after receiving a response on the callback queue On_ Response responds to the CORRELATION_ID property associated with the response, defines the calling function and sends a call to the queue that contains properties such as correlation_id, initializes a client instance, and initiates a remote procedure call with 30 parameters.

You can do the application according to your own needs, the specific code can go to the official website to view
Http://www.rabbitmq.com/getstarted.html official website