huey
配置簡單，支持自動重試失敗的任務
輕量級；重在 輕量，代碼也比較簡單，沒有 celery 功能強大，目前只支持redis
Huey——負責協調可執行任務和隊列後端
Huey.task()——裝飾器來指示可執行任務
Huey.periodic_task() ——裝飾器以指示以週期性間隔執行的任務
TaskResultWrapper.get() ——從任務獲取返回值
crontab() ——用於定義執行週期性任務的間隔時間
huey 組成 生產，消費，隊列，Python main.py 是生產者，
./cons.sh 是消費者 ，隊列只能使用 redis 目前只支持隊列，從 lpush 打入隊列中，brpop 讀取
方式，1 先配置隊列，消費者需要指定一個實例 config.py
huey 封裝了隊列 ，用於存取， 主要定義 redis 的儲存
task.py api 定義最終被消費者執行的任務，用task 裝飾一下，你想讓消費者運行的任務,
這樣就定義了一個基本的基本任務
主程序是main 導入了配置和任務，確保所有任務都會加載到內存
運行步驟
1 確保本地運行redis
2 安裝 huey
3 啓動消費者：huey_consumer.py 在./cons.sh 有封裝直接運行./cons.sh
huey_consumer可以包含很多參數，主要分爲三個group(Logging日誌記錄, Workers任務worker相關, Scheduler計劃任務相關)
4 運行主程序 python main.py，定義需要執行任務的方法
作用：簡單的消費
1延遲執行任務
2
2 重試失敗任務
異常重試：當任務出現異常時進行retry，並且可以指定重試延時時
Huey支持有限次重試失敗任務。如果在執行任務期間引發了異常，但是你已經指定了retries參數，則任務將重新入隊並再次嘗試，直到指定的重試次數。
如下顯示的一個任務，將重試3次，每次都會拋出異常
定期任務 個人覺得還是用linux 自帶的crontab 比較好用
huey支持的另一個使用模式是定期執行任務。依照crontab行爲，同時遵循類似的語法。定期執行的任務，不應返回有意義的結果，也不應接受任何參數。
讓我們添加一個每分鐘打印一次字符竄的新任務——我們將使用它來測試消費者是否正在按計劃執行任務
取消或暫停任務，
要撤消給定任務的所有實例，請對任務本身使用revoke()和restore()方法：
huey可以停止任務執行。這適用於正常任務，延遲任務和定期任務。
爲了“revoke（撤銷）”任務，你需要在實例化Huey對象時指定一個result_store參數。
如果消費者沒有開始執行任務，你可以取消正常的任務：
取消或暫停定期任務
當我們開始處理定期任務時，撤銷選項會更有意思。
我們將使用打印時間代碼作爲示例：
celery
celery (芹菜）有倆種方法，
1種是裝飾器，一種是遠程調用，
缺點：1 celery 做定時任務時，有一定的時間的延時，
2 做定時任務會讓任務重複，當worker 節點停止了，而beat 在之後纔會停止，下一次啓動worker 的時候，還會執行上一次未完成的任務，可能會有重複，，所以在看日誌的時候，可能會看到上一個的任務
redis 添加操作，把數據存儲到Redis裏 zadd ()
1，定義任務隊列
開啓worker 之後
celery
將請求要處理的任務丟到任務隊列中去，由空閒的worker 去處理，處理的結果會暫存到後臺數據庫中去，可以在一臺，或多臺機器，同時起多個worker 進行操作，來實現分佈式任務處理
celery 名詞：
任務：task 就是一個python 函數
隊列： queue 將執行的任務加入到隊列中去
工人：worker 在一個新進程中，負責執行隊列的任務
代理人： borker 負責調度，在佈置環境中使用redis
啓動worker 在普通腳本里，celery -A tasks worker --loglevel=info 運行命令需在，tasks 的目錄下
tasks 屬於任務文件夾的文件名
celery -A tasks worker --loglevel=info
開始調用程序
from Cleery import celery
import time
=========重點是 任務的遠程調用send_task（）方法
celery 作爲分佈式系統，支持遠程worker . 可以利用send_task函數，以函數命名的方式調用task,
celery multi start 10 -A rawhttp.image_spider -l warn -c 100 -P gevent -Q rawhttp.image_spider -b redis://127.0.0.1:6379/6
遠程調用
Celery的架構由三部分組成，消息中間件（message broker），任務執行單元（worker）和任務執行結果存儲（task result store）組成。
celery 適合實時處理的分佈式耗時任務
定時任務不咋用，目前 celery 現在常用的是rabbitmq，可以執行多個worker
用戶使用 Celery 產生任務，借用中間人來傳遞任務，任務執行單元從中間人那裏消費任務。任務執行單元可以單機部署，也可以分佈式部署，因此 Celery 是一個高可用的生產者消費者模型的異步任務隊列,
區別：
1celery 支持不同的存儲方式 redis MongoDB，rabbitmq,等
huey 只支持redis
2Celery task 中不允許調用別的 task 後阻塞式的 get 等待結果
3Celery 非常適合用於那種你把任務拋出去就不用管了的場景
4 因爲當數據量很大的時候出現了 socket pipeline 錯誤