RabbitMQ消息隊列（三）：任務分發機製

在上篇文章中，我們解決了從發送端（Producer）向接收端（Consumer）發送“Hello World”的問題。在實際的應用場景中，這是遠遠不夠的。從本篇文章開始，我們將結合更加實際的應用場景來講解更多的高級用法。

當有Consumer需要大量的運算時，RabbitMQ Server需要一定的分發機製來balance每個Consumer的load。試想一下，對於web application來說，在一個很多的HTTP request裏是沒有時間來處理複雜的運算的，隻能通過後台的一些工作線程來完成。接下來我們分布講解。

應用場景就是RabbitMQ Server會將queue的Message分發給不同的Consumer以處理計算密集型的任務：

1. 準備

在上一篇文章中，我們簡單在Message中包含了一個字符串"Hello World"。現在為了是Consumer做的是計算密集型的工作，那就不能簡單的字符串了。在現實應用中，Consumer有可能做的是一個圖片的resize，或者是pdf文件的渲染或者內容提取。但是作為Demo，還是用字符串模擬吧：通過字符串中的.的數量來決定計算的複雜度，每個.都會消耗1s，即sleep(1)。

還是複用上篇文章中的code，根據“計算密集型”做一下簡單的修改，為了辨別，我們把send.py 的名字換成new_task.py

import sys

message = ' '.join(sys.argv[1:]) or "Hello World!"
channel.basic_publish(exchange='',
                      routing_key='hello',
                      body=message)
print " [x] Sent %r" % (message,)

同樣的道理，把receive.py的名字換成worker.py，並且根據Message中的.的數量進行計算密集型模擬：

import time

def callback(ch, method, properties, body):
    print " [x] Received %r" % (body,)
    time.sleep( body.count('.') )
    print " [x] Done"

2. Round-robin dispatching 循環分發

RabbitMQ的分發機製非常適合擴展，而且它是專門為並發程序設計的。如果現在load加重，那麼隻需要創建更多的Consumer來進行任務處理即可。當然了，對於負載還要加大怎麼辦？我沒有遇到過這種情況，那就可以創建多個virtual Host，細化不同的通信類別了。

首先開啟兩個Consumer，即運行兩個worker.py。

Console1：

shell1$ python worker.py
 [*] Waiting for messages. To exit press CTRL+C

Consule2：

shell2$ python worker.py
 [*] Waiting for messages. To exit press CTRL+C

Producer new_task.py要Publish Message了：

shell3$ python new_task.py First message.
shell3$ python new_task.py Second message..
shell3$ python new_task.py Third message...
shell3$ python new_task.py Fourth message....
shell3$ python new_task.py Fifth message.....

注意一下：.代表的sleep(1)。接著開一下Consumer worker.py收到了什麼:

Console1：

shell1$ python worker.py
 [*] Waiting for messages. To exit press CTRL+C
 [x] Received 'First message.'
 [x] Received 'Third message...'
 [x] Received 'Fifth message.....'

Console2：

shell2$ python worker.py
 [*] Waiting for messages. To exit press CTRL+C
 [x] Received 'Second message..'
 [x] Received 'Fourth message....'

默認情況下，RabbitMQ 會順序的分發每個Message。當每個收到ack後，會將該Message刪除，然後將下一個Message分發到下一個Consumer。這種分發方式叫做round-robin。這種分發還有問題，接著向下讀吧。

3. Message acknowledgment 消息確認

每個Consumer可能需要一段時間才能處理完收到的數據。如果在這個過程中，Consumer出錯了，異常退出了，而數據還沒有處理完成，那麼非常不幸，這段數據就丟失了。因為我們采用no-ack的方式進行確認，也就是說，每次Consumer接到數據後，而不管是否處理完成，RabbitMQ Server會立即把這個Message標記為完成，然後從queue中刪除了。

如果一個Consumer異常退出了，它處理的數據能夠被另外的Consumer處理，這樣數據在這種情況下就不會丟失了（注意是這種情況下）。

為了保證數據不被丟失，RabbitMQ支持消息確認機製，即acknowledgments。為了保證數據能被正確處理而不僅僅是被Consumer收到，那麼我們不能采用no-ack。而應該是在處理完數據後發送ack。

在處理數據後發送的ack，就是告訴RabbitMQ數據已經被接收，處理完成，RabbitMQ可以去安全的刪除它了。

如果Consumer退出了但是沒有發送ack，那麼RabbitMQ就會把這個Message發送到下一個Consumer。這樣就保證了在Consumer異常退出的情況下數據也不會丟失。

這裏並沒有用到超時機製。RabbitMQ僅僅通過Consumer的連接中斷來確認該Message並沒有被正確處理。也就是說，RabbitMQ給了Consumer足夠長的時間來做數據處理。

默認情況下，消息確認是打開的（enabled）。在上篇文章中我們通過no_ack = True 關閉了ack。重新修改一下callback，以在消息處理完成後發送ack：

def callback(ch, method, properties, body):
    print " [x] Received %r" % (body,)
    time.sleep( body.count('.') )
    print " [x] Done"
    ch.basic_ack(delivery_tag = method.delivery_tag)

channel.basic_consume(callback,
                      queue='hello')

這樣即使你通過Ctr-C中斷了worker.py，那麼Message也不會丟失了，它會被分發到下一個Consumer。

如果忘記了ack，那麼後果很嚴重。當Consumer退出時，Message會重新分發。然後RabbitMQ會占用越來越多的內存，由於RabbitMQ會長時間運行，因此這個“內存泄漏”是致命的。去調試這種錯誤，可以通過一下命令打印un-acked Messages：

$ sudo rabbitmqctl list_queues name messages_ready messages_unacknowledged
Listing queues ...
hello    0       0
...done.

4. Message durability消息持久化

在上一節中我們知道了即使Consumer異常退出，Message也不會丟失。但是如果RabbitMQ Server退出呢？軟件都有bug，即使RabbitMQ Server是完美毫無bug的（當然這是不可能的，是軟件就有bug，沒有bug的那不叫軟件），它還是有可能退出的：被其它軟件影響，或者係統重啟了，係統panic了。。。

為了保證在RabbitMQ退出或者crash了數據仍沒有丟失，需要將queue和Message都要持久化。

queue的持久化需要在聲明時指定durable=True：

channel.queue_declare(queue='hello', durable=True)

上述語句執行不會有什麼錯誤，但是確得不到我們想要的結果，原因就是RabbitMQ Server已經維護了一個叫hello的queue，那麼上述執行不會有任何的作用，也就是hello的任何屬性都不會被影響。這一點在上篇文章也討論過。

那麼workaround也很簡單，聲明一個另外的名字的queue，比如名字定位task_queue：

channel.queue_declare(queue='task_queue', durable=True)

再次強調，Producer和Consumer都應該去創建這個queue，盡管隻有一個地方的創建是真正起作用的：

接下來，需要持久化Message，即在Publish的時候指定一個properties，方式如下：

channel.basic_publish(exchange='',
                      routing_key="task_queue",
                      body=message,
                      properties=pika.BasicProperties(
                         delivery_mode = 2, # make message persistent
                      ))

關於持久化的進一步討論：

為了數據不丟失，我們采用了：

在數據處理結束後發送ack，這樣RabbitMQ Server會認為Message Deliver 成功。
持久化queue，可以防止RabbitMQ Server 重啟或者crash引起的數據丟失。
持久化Message，理由同上。

但是這樣能保證數據100%不丟失嗎？

答案是否定的。問題就在與RabbitMQ需要時間去把這些信息存到磁盤上，這個time window雖然短，但是它的確還是有。在這個時間窗口內如果數據沒有保存，數據還會丟失。還有另一個原因就是RabbitMQ並不是為每個Message都做fsync：它可能僅僅是把它保存到Cache裏，還沒來得及保存到物理磁盤上。

因此這個持久化還是有問題。但是對於大多數應用來說，這已經足夠了。當然為了保持一致性，你可以把每次的publish放到一個transaction中。這個transaction的實現需要user defined codes。

那麼商業係統會做什麼呢？一種可能的方案是在係統panic時或者異常重啟時或者斷電時，應該給各個應用留出時間去flash cache，保證每個應用都能exit gracefully。

5. Fair dispatch 公平分發

你可能也注意到了，分發機製不是那麼優雅。默認狀態下，RabbitMQ將第n個Message分發給第n個Consumer。當然n是取餘後的。它不管Consumer是否還有unacked Message，隻是按照這個默認機製進行分發。

那麼如果有個Consumer工作比較重，那麼就會導致有的Consumer基本沒事可做，有的Consumer卻是毫無休息的機會。那麼，RabbitMQ是如何處理這種問題呢？

通過 basic.qos 方法設置prefetch_count=1 。這樣RabbitMQ就會使得每個Consumer在同一個時間點最多處理一個Message。換句話說，在接收到該Consumer的ack前，他它不會將新的Message分發給它。設置方法如下：

channel.basic_qos(prefetch_count=1)

注意，這種方法可能會導致queue滿。當然，這種情況下你可能需要添加更多的Consumer，或者創建更多的virtualHost來細化你的設計。

6. 最終版本

new_task.py script:

#!/usr/bin/env python
import pika
import sys

connection = pika.BlockingConnection(pika.ConnectionParameters(
        host='localhost'))
channel = connection.channel()

channel.queue_declare(queue='task_queue', durable=True)

message = ' '.join(sys.argv[1:]) or "Hello World!"
channel.basic_publish(exchange='',
                      routing_key='task_queue',
                      body=message,
                      properties=pika.BasicProperties(
                         delivery_mode = 2, # make message persistent
                      ))
print " [x] Sent %r" % (message,)
connection.close()

worker.py script:

#!/usr/bin/env python
import pika
import time

connection = pika.BlockingConnection(pika.ConnectionParameters(
        host='localhost'))
channel = connection.channel()

channel.queue_declare(queue='task_queue', durable=True)
print ' [*] Waiting for messages. To exit press CTRL+C'

def callback(ch, method, properties, body):
    print " [x] Received %r" % (body,)
    time.sleep( body.count('.') )
    print " [x] Done"
    ch.basic_ack(delivery_tag = method.delivery_tag)

channel.basic_qos(prefetch_count=1)
channel.basic_consume(callback,
                      queue='task_queue')

channel.start_consuming()

尊重原創，轉載請注明出處：anzhsoft https://blog.csdn.net/anzhsoft/article/details/19607841

參考資料：

1. https://www.rabbitmq.com/tutorials/tutorial-two-python.html

最後更新：2017-04-03 12:55:10

RabbitMQ消息隊列（三）：任務分發機製

1. 準備

2. Round-robin dispatching 循環分發

3. Message acknowledgment 消息確認

4. Message durability消息持久化

5. Fair dispatch 公平分發

6. 最終版本

上一篇： RabbitMQ消息隊列（七）：適用於雲計算集群的遠程調用(RPC)

下一篇： static class 和 static interface

相關內容

熱門內容

最新內容