原文鏈接：https://www.ikaze.cn/article/43
寫這篇博文的起因是，我在論壇宣傳我開源的新項目YTask（go語言異步任務隊列）時，有小夥伴在下面回了一句“爲什麼不用nsq？”。這使我想起，我在和同事介紹celery時同事說了一句“這不就是kafka嗎？”。
那麼YTask和nsq，celery和kafka？他們之間到底有什麼不同呢？下面我結合自己的理解。簡單的分析一下，如有不足請指出。
首先，nsq和kafka它們屬於消息隊列；YTask和celery它們屬於任務隊列。
消息隊列和任務隊列，最大的不同之處就在於理念的不同 -- 消息隊列傳遞的是“消息”，任務隊列傳遞的是“任務”。
這句話何解呢？
我們可以放到具體的應用場景上:
- 消息隊列用來快速消費隊列中的消息。比如日誌處理場景，我們需要把不同服務器上的日誌合併到一起，這時就需要用到消息隊列。
- 任務隊列是用來執行一個耗時任務。比如用戶在購買的一件物品後，通常需要計算用戶的積分以及等級，並把它們保存到數據庫。這時就需要用到任務隊列。
從上面的例子可看出:
- 消息隊列更側重於消息的吞吐、處理，具有有處理海量信息的能力。另外利用消息隊列的生長者和消費者的概念，也可以實現任務隊列的功能，但是還需要進行額外的開發。
- 任務隊列則提供了執行任務所需的功能，比如任務的重試，結果的返回，任務狀態記錄等。雖然也有併發的處理能力，但一般不適用於高吞吐量快速消費的場景。
任務隊列其實和遠程函數調用差不多，但和thrift、grpc什麼不同，它不需要定義描述文件，調用的方式也不是網絡請求方式，而是利用消息隊列傳遞任務信息。
因此可以簡單認爲任務隊列就是消息隊列在異步任務場景下的深度化定製開發。