實現任務隊列之前，我們先了解一下使用任務隊列有哪些好處:
1.松耦合。生產者和消費者無需知道彼此的實現細節，只需要約定好任務的描述格式。這使得生產者和消費者可以由不同的團隊使用不同的編程語言編寫。
2.易於擴展。消費者可以由多個，而且可以分布在不同的服務器中，借此可以輕易地降低單台服務器的負載。
要實現隊列很自然就想到Redis的列表類型，以及LPUSH和RPOP命令。如果要實現任務隊列，只需要讓生產者將任務使用LPUSH命令加入到某個鍵中，另一邊讓消費者不斷的使用RPOP命令從該鍵中取出任務即可。Redis的偽代碼實現如下：
Redis偽代碼
# 無限循環讀取任務隊列中的內容 loop $task = RPOP queue if $task # 如果任務隊列中有任務，則執行它 execute($task) else # 如果沒有任務，則等待1秒，以免過於頻繁的請求數據 wait 1 second
至此，一個使用Redis實現的簡單任務隊列就寫好了，不過還有一點問題：當任務隊列中沒有任務時，消費者每秒都會調用一次RPOP命令查看是否有新任務。
優化：借助BRPOP命令，可以實現一旦有新任務加入隊列就通知消費者
BRPOP命令接收兩個參數，第一個是鍵名，第二個是超時時間，單位是秒。當超過了此時間仍然沒有獲得新元素的話就會返回nil。如果超時時間設為“0”，表示不限制等待的時間，如果沒有新元素加入列表就會永遠阻塞下去。
BRPOP和RPOP命令相似，唯一區別是：任務列表中沒有元素時BRPOP命令會一直阻塞住連接，直到有新元素加入。上面的偽代碼可以優化為：
Redis偽代碼
loop # 如果任務隊列中沒有新任務，BRPOP命令會一直阻塞，不會執行execute() $task = BRPOP queue, 0 # 返回值是一個數組，數組的第二個元素是我們需要的任務 execute($task[1])
隊列有的時候需要優先級。比如：系統需要發送確認郵件和通知郵件兩種任務同時存在時，應該優先執行確認郵件。具體場景如下，訂閱一個名人的博客的用戶有10萬人，當該博客發布一篇新文章后，博客就會向任務隊列中添加10萬個發送通知郵件的任務。如果每一封郵件需要10ms，那么全部完成這10萬個任務就需要：100 000*10/1000=1000秒（將近20分鍾）。加入這期間有新用戶想訂閱該博客，當提交完自己的郵箱並看到網頁提示查收確認郵件時，該用戶並不知道向自己發送的確認郵件的任務被加入到已經有10萬個任務的隊列中，需要為此等待近20分鍾。
分析具體場景，發布新文章后通知訂閱用戶的任務並不很緊急，延遲20分鍾完全可以接受。所以可以得出如下結論：當發送確認郵件和發送通知郵件兩種任務同時存在時，應該優先執行前者。為了實現這一目的，我們需要實現一個優先級隊列。
BRPOP命令可以同時接受多個鍵，其完整的命令格式為：BRPOP key[key...]timeout,如：BRPOP queue1 queue2 0.着意味着同時檢測多個鍵，如果其中有一個鍵有元素，則從該鍵中彈出元素；如果多個鍵都有元素，則按照從左到右的順序取第一個鍵中的第一個元素。
借此特性可以實現區分優先級的任務隊列。我們分別使用queue:confirmation.email和queue.notification.email兩個鍵存儲發送確認郵件和發送通知郵件兩種任務，然后將消費者的偽代碼修改為：
Redis偽代碼
loop $task = BRPOP queue:confirmationl.email, queue:notification.email, 0 execute($task[1])
這時，一旦發送確認郵件的任務被加入到queue.confirmation.email隊列中，無論queue：notification.email還有多少任務，消費者都會優先完成發送確認郵件的通知任務。