小朱® 的技術隨手寫

我想多數的程式開發者，可能鮮少或沒有寫過與佇列 (queue) 有關的應用程式，很多的工作都由資料庫做掉了，或是前端將資料寫入資料庫，然後用一個排程的程式來處理它，自己做佇列的應用程式的案例與情境變得少了一些。不過如果能善用 queue 的話，可以解決一些必須要以 FIFO (First-In, First Out) 才能解決或是符合商業規則的需求，最好的一個案例就是訂票系統。不論是哪一種類型的訂票服務，都不脫下列三個過程：

 

 

其中第二個程序就是佇列的功能，基於先到者優先的概念，先搶到該座位的人優先得到訂位權，而如果沒搶到該座位的只能選其他的座位，或是用站的 (鐵路和公路多是如此)。另外一種情況就是限量品的搶購，只有先讓訂單進入的人才可以買到，這種系統的處理也大多會使用到 queue，而且一旦資料進入 queue 後，前端使用者就不必再繼續 keep 在那裡，只要處理佇列資料的處理程式在將 queue 中的資料輸入到資料庫後，發出一份通知訊息給使用者即可。在大型的應用程式中，佇列的應用非常廣泛，像是 ERP/SCM 等庫存批次處理的系統，面對來自於交易系統如雪片般的訂單，也都是要利用 queue 來確認先到者先安排庫存的規則，才能夠順暢的安排作業以及處理訂單工作，若沒有 queue 的話，很多工作都會擠成一團（包括前端使用者介面也會 hold 住），無法有效率的處理。

 

因此，作業系統中大多都會有內建針對佇列的一般化支援，企業級的應用程式平台也會對 queue 有較多的應用與支援，像是 IBM 的 MQseries，或是微軟的 MSMQ 等，就是一般化的訊息佇列處理伺服程式，當然，Windows Azure 也應該有一個處理佇列的功能，畢竟它可是希望能夠吸引大多數企業使用這個載具的作業系統，當然不能缺少這類型的處理功能。它就是 Azure Storage Service 的其中之一：Queue Service。

 

Queue Service 和 Table 以及 BLOB 一樣，都會有一個佇列容器 (container)，就如同排隊的路徑一樣，每一個 container 都可以容納自己的 queue message，由前端或是服務應用程式將訊息發送給 queue container，並將它插入佇列的最後端，而佇列處理程式 (queue handler) 則由最前端一個一個的取出，並且處理以後將訊息由佇列刪除，以確保相同的訊息不會被處理到。

 

 

在 Development Storage 中，有兩個資料表是用來處理 queue 的，一個是 QueueContainer，用來登錄 Queue Container 之用，另一個是 QueueMessage，用來儲存在 Queue Container 中的所有佇列訊息。其中比較有意思的是，Queue 會將插入 queue 的時間 (Insertion Time)，訊息到期時間 (Expiry Time) 以及取出次數 (Dequeue Count) 等做設定，如此可以更進一步的對 queue 中的訊息做判斷與處理。

 

 

值得一提的是，Queue Message 中裝載的是 byte[] 資料，這也就是指只要能夠序列化成位元組資料的物件都可以使用在 queue message，大大的增加了它的適用範圍，例如開發人員可以傳遞一個 entity 進行二進位序列化 (binary serialization) 給 queue message，只要 queue handler 認得這個 entity，那麼 queue handler 就可以直接將它反序列化 (deserialize) 成一個 entity 物件，並且直接操作它的成員。不必再額外寫一堆資料格式來給 queue message 使用。不過它有 8KB 容量的限制，因此不是什麼物件都能夠序列化，只要大小一大於 8KB 時就無法放到 queue message 中，只能改用 Table 或 BLOB 來儲存。

 

另外，Queue Service 還有下列限制：

 

1. 容器必須全部小寫字母組成，且只能用英文半型字，數字字元以及分隔符號 (“-“) 。
2. 容器名稱的第一個字和最後一個字元必須是英文字，分隔符號 (“-“) 不可以出現在第一個或最後一個字元。
3. 長度必須要是 3-63 個字元。

 

參考資料：

Queue Service API: http://msdn.microsoft.com/en-us/library/dd179363.aspx