工作佇列-workqueue
實現功能：
將耗時的任務分發給多個工作者
設計思想：
避免直接去做一件資源密集型的任務，並且還得等它完成。因此將任務安排後再去做。將任務封裝為乙個訊息，發到佇列中。乙個工作程序將在後台取出任務並最終完成。如果開啟多個工作程序，任務將在這個多工作程序間共享
訊息分發：
一、迴圈分發（message acknowledement）：
預設情況下，rabbitmq是輪流發訊息給下乙個消費者，平均每個cusumer接到的訊息數量相等。
那麼問題來了，當乙個訊息十分耗時，那麼獲得到這個訊息的cusumer，在執行時崩潰導致任務未完成，那麼這個訊息就丟失了。為了保證出現類似問題，訊息不消失。rabbitmq有乙個訊息確認機制。
二、訊息確認機制（ack）：
rabbitmq支援訊息確認，為保證訊息永不丟失，cusumer會傳送乙個確認訊息告訴rabbitmq。代表我已接收訊息，並處理完成。可以隨時刪除。
當乙個cusumer在傳送確認訊息前死亡（連線或通道關閉，tcp連線丟失等），rabbitmq會認為該訊息沒有被完全處理並將其重新加入佇列。如果此時有其他cusumer，rabbitmq很快會重新傳送該訊息到其他cusumer。通過這個方式保證沒有訊息丟失，及時某個cusumer意外死亡。
開啟訊息確認機制，rabbitmq預設開啟。**：autoack = true（關掉）/false（開啟）
注：對於rabbitmq而言，沒有訊息超時
當我們開啟訊息確認機制之後，可以保證cusumer死亡時不會丟失訊息。但當rabbitmq服務關閉或崩潰後，會丟失所有的佇列和訊息。
那如何解決因服務關閉或崩潰造成的訊息丟失呢？我們需要做三件事情：
持久化exchange（交換機）：宣告時指定durable = true
持久化queue（佇列）：宣告時指定durable = true
持久化message（訊息）：在訊息投遞時指定delivery_mode = 2（1是非持久化）或將messageproperties的值設定為persistent_text_palin
注：rabbitmq不允許重新定義已經存在的佇列的持久化，如上一章中我們設定的myqueue佇列。如果設定了該佇列不持久化，那麼我們不能再宣告它持久化。不然會報錯。我們必須重新宣告乙個新佇列並宣告持久化。
以上我們可以做乙個小結：
1、rabbitmq在服務端沒有宣告佇列和訊息持久化時，佇列和訊息存在記憶體中，服務端宕機後都丟失。
2、服務端宣告持久化，客戶端想要接收訊息，必須宣告queue同時宣告持久化，不然客戶端執行報錯。
三、公平分發（fair dispatch）：
在迴圈分發機制中，可能會發生乙個cusumer接收的訊息處理非常耗時，而另乙個cusumer接收的訊息非常快處理完。這會導致有的cusumer很忙有的很閒。
rabbitmq對此一概不知。因為它只是當訊息進入佇列就分發出去，並沒有檢視每個cusumer未返回訊息確認的數量。
為了改變這種情況，rabbitmq提供了公平分發機制。使用basicqos()方法。將其引數prefetchcount設定為1。這樣cusumer會告訴rabbitmq，不要同時發多個訊息給我。每次只發乙個，當我處理完訊息並給你確認資訊後，再發給我下乙個。這時候rabbitmq會檢視cusumer返回的確認，尋找空閒的cusumer傳送訊息。
工作佇列分析
一 用法 struct cpu workqueue struct cacheline aligned the externally visible workqueue abstraction is an array of per cpu workqueues struct workqueue str...
工作佇列模型
workqueue,中文稱其為工作佇列，是乙個用於建立核心執行緒的介面，通過它建立的核心執行緒來執行核心其他模組排列到佇列裡的工作，建立的核心執行緒被稱為工作者執行緒。要理解工作佇列的實現，重點在於理解相關的三個資料結構的含義及關係。1 表示工作佇列型別的資料結構 struct workqueue ...
工作佇列分析
一 用法 struct cpu workqueue struct cacheline aligned the externally visible workqueue abstraction is an array of per cpu workqueues struct workqueue str...