为什么需要消息队列
系统中引入消息队列机制是对系统一个非常大的改善。例如一个web系统中，用户做了某项操作后需要发送邮件通知到用户邮箱中。你可以使用同步方式让用户等待邮件发送完成后反馈给用户，但是这样可能会因为网络的不确定性造成用户长时间的等待从而影响用户体验。
有些场景下是不可能使用同步方式等待完成的，那些需要后台花费大量时间的操作。例如极端例子，一个在线编译系统任务，后台编译完成需要30分钟。这种场景的设计不可能同步等待后在回馈，必须是先反馈用户随后异步处理完成，再等待处理完成后根据情况再此反馈用户与否。
另外适用消息队列的情况是那些系统处理能力有限的情况下，先使用队列机制把任务暂时存放起来，系统再一个个轮流处理掉排队的任务。这样在系统吞吐量不足的情况下也能稳定的处理掉高并发的任务。
消息队列可以用来做排队机制，只要系统需要用到排队机制的地方就可以使用消息队列来作。
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from multiprocessing import Pool
import time
import random
import os
import redis
import logging
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)
WORKER_QUEUE = 'worker_queue'
def do_task(queue_key, x):
x = int(x)
delay = random.randint(3, 7)
print '开始打包序号: %s 任务优先级别：%s' % (x, queue_key)
time.sleep(delay)
print '打包结束，耗时 %s 秒 结果是：%s 优先级别 %s' % (delay, x*x, queue_key)
redis_client.lpush(WORKER_QUEUE, 1)
return x*x
if __name__ == '__main__':
pros = 2
pool = Pool(processes=pros)
HIGH_QUEUE_KEY = 'high_task_queue'
NOMAL_QUEUE_KEY = 'task_queue'
LOW_QUEUE_KEY = 'low_task_queue'
"""
再创建一个队列，用来检测是否还有空余进程, 初始化队列是pros个值
取一个，子进程工作一个任务
配合这个 redis_client.blpop(WORKER_QUEUE)
一个子进程工作完就, 就lpush到这个WORKER_QUEUE队列
所有子进程都在工作，意味这个队列是空的，那么主进程不循环。等待空闲子进程
"""
redis_client.delete(WORKER_QUEUE)
for i in range(0, pros):
redis_client.lpush(WORKER_QUEUE, 1)
"""
父进程就是执行的这个python
子进程就是spawn出来由4个进程组成的进程池
下面的pool.apply_async 只是交给进程池里面的进程处理
父进程不会执行任务，他只是作为一个无限循环
"""
while 1:
redis_client.blpop(WORKER_QUEUE)
queue_key, params = redis_client.blpop([HIGH_QUEUE_KEY, NOMAL_QUEUE_KEY, LOW_QUEUE_KEY])
print queue_key, params
"""
pool.apply()执行任务是同步执行，意思是执行完一个任务，才到下一个任务，
而每次使用的进程都是RR轮询依次使用进程
所以所有任务都是 9 8 7 6 5 4 3 依次使用不用进程池里的进程执行
"""
# res = pool.apply(do_task, (params, ))
"""
pool.apply_async() 任务时异步执行， 执行完apply_async(), 无论任务执行多久
都不会阻塞，立马返回一个对象， 然后就交给这个进程处理
主进程继续往下循环
但是这样异步一个任务后， 主进程继续循环，继续塞任务到进程池，所以某个子进程
可能再未处理完上一个任务情况下，继续塞了下个任务进来。这样就只能排队执行了
"""
res = pool.apply_async(do_task, (queue_key, params))
思考
问：
进程一只阻塞再redis_client.blpop(key) 这里，如果队列一致没有任务，进程一直卡在这里，对CPU 内存的影响是怎样的？
答：
计算机硬件上使用DMA来访问磁盘等IO，也就是请求发出后，CPU就不再管了，直到DMA处理器完成任务，再通过中断告诉CPU完成了。所以，单独的一个IO时间，对CPU的占用是很少的，阻塞了就更不会占用CPU了，因为程序都不继续运行了，CPU时间交给其它线程和进程了。虽然IO不会占用大量的CPU时间，但是非常频繁的IO还是会非常浪费CPU时间的，所以面对大量IO的任务，有时候是需要算法来合并IO，或者通过cache来缓解IO压力的。
blpop本质上还是recv_from 那一套， 等待IO时交出CPU
参考
http://www.cnblogs.com/laozhbook/p/redis_queue.html
https://www.zhihu.com/question/27734728
网友评论