RabbitMQ-Tutorials 学习与总结

学习资料来源

rabbitmq学习指南： https://www.rabbitmq.com/getstarted.html

学习与总结

rabbitmq 初步认识

RabbitMQ is a message broker: it accepts and forwards messages. You can think about it as a post office: when you put the mail that you want posting in a post box, you can be sure that Mr. or Ms. Mailperson will eventually deliver the mail to your recipient. In this analogy, RabbitMQ is a post box, a post office and a postman.

The major difference between RabbitMQ and the post office is that it doesn’t deal with paper, instead it accepts, stores and forwards binary blobs of data ‒ messages.

一般术语：

• 生产者 producer：A program that sends messages.
  • basic_publish 发布消息 routing_key 关键参数
  • 发不了消息，见常见问题 0
• 队列 queue：A place to store messages.
  • basic_consume
  • queue_declare 声明队列
  • queue_bind：绑定到对应的 Exchange 中，routing_key 关键参数
  • basic_qos(prefetch_count=1) 一次分配消息是数量
• 消费者 consumer：A program that mostly waits to receive messages.
• 消息确认 message ack(nowledgement) ：An ack(nowledgement) is sent back by the consumer to tell RabbitMQ that a particular message had been received, processed and that RabbitMQ is free to delete it.
  • 可防止因为 consumer 中断时，消息丢失
  • 忘记 ack 会导致消息堆积
• 消息持久化 message durable：队列持久化（durable=true）、信息持久化（delivery_mode=2）
  • 消息持久化仍会存在丢失的情况，见常见问题 2
• 交换机 Exchange： An exchange is a very simple thing. On one side it receives messages from producers and the other side it pushes them to queues.
  • Exchange-Type: 交换机的路由规则
    • fanout：广播
    • direct：指定 Routing Key
    • Topic：规则匹配的 Routing Key
      • * (star) can substitute for exactly one word.
      • # (hash) can substitute for zero or more words.
    • header：——待补充
• 远程过程调用 Remote procedure call (RPC) ：见常见问题3
• 生产核实 Publisher Confirms：生产的消息是否成功送达到 broker
  • Channel#waitForConfirmsOrDie(long) ：The method returns as soon as the message has been confirmed. If the message is not confirmed within the timeout or if it is nack-ed (meaning the broker could not take care of it for some reason), the method will throw an exception.

工作模式

Topic:

RPC will work like this:

• When the Client starts up, it creates an anonymous exclusive callback queue.
• For an RPC request, the Client sends a message with two properties: reply_to, which is set to the callback queue and correlation_id, which is set to a unique value for every request.
• The request is sent to an rpc_queue queue.
• The RPC worker (aka: server) is waiting for requests on that queue. When a request appears, it does the job and sends a message with the result back to the Client, using the queue from the reply_to field.
• The client waits for data on the callback queue. When a message appears, it checks the correlation_id property. If it matches the value from the request it returns the response to the application.

常见问题

0. Sending doesn’t work!

If this is your first time using RabbitMQ and you don’t see the “Sent” message then you may be left scratching your head wondering what could be wrong. Maybe the broker was started without enough free disk space (by default it needs at least 200 MB free) and is therefore refusing to accept messages. Check the broker logfile to confirm and reduce the limit if necessary. The configuration file documentation will show you how to set disk_free_limit.

1. Forgotten acknowledgment

It’s a common mistake to miss the basic_ack. It’s an easy error, but the consequences are serious. Messages will be redelivered when your client quits (which may look like random redelivery), but RabbitMQ will eat more and more memory as it won’t be able to release any unacked messages.

2. Note on message persistence

Marking messages as persistent doesn’t fully guarantee that a message won’t be lost. Although it tells RabbitMQ to save the message to disk, there is still a short time window when RabbitMQ has accepted a message and hasn’t saved it yet. Also, RabbitMQ doesn’t do fsync(2) for every message – it may be just saved to cache and not really written to the disk. The persistence guarantees aren’t strong, but it’s more than enough for our simple task queue. If you need a stronger guarantee then you can use publisher confirms.

3. A note on RPC

Although RPC is a pretty common pattern in computing, it’s often criticised. The problems arise when a programmer is not aware whether a function call is local or if it’s a slow RPC. Confusions like that result in an unpredictable system and adds unnecessary complexity to debugging. Instead of simplifying software, misused RPC can result in unmaintainable spaghetti code.

Bearing that in mind, consider the following advice:

Make sure it’s obvious which function call is local and which is remote.
Document your system. Make the dependencies between components clear.
Handle error cases. How should the client react when the RPC server is down for a long time?
When in doubt avoid RPC. If you can, you should use an asynchronous pipeline - instead of RPC-like blocking, results are asynchronously pushed to a next computation stage.

4. Publisher Confirms

This techniques is very straightforward but also has a major drawback: it significantly slows down publishing, as the confirmation of a message blocks the publishing of all subsequent messages. This approach is not going to deliver throughput of more than a few hundreds of published messages per second. Nevertheless, this can be good enough for some applications.