2022.07 補充: 後續補充與整理，將更新於 Blog

1. 撰寫動機

為什麼會寫這個主題，是因為近幾年參與開發的軟體之中，大量使用到佇列(Queue)的技術與觀念。從同步與非同步存取 Queue；利用 Queue 與 Dispatch 組合，進行備援處理的機制；大量資料的接收與轉發等等。

另一方面，訊息佇列（Message Queue）雖然己經被業界使用多年，但卻未能好好的深入了解。直到這半年，才有機會真正的去了解 Message Queue 的概念。

利用這次的機會，發揮傻子的精神，土幹一個 Message Queue 出來。其用意在於撰寫文章與實作的同時，持續深入了解，同時發現自己的不足。事實上，在規劃文章大綱與設計系統時，就遇到很多沒有深入理解的知識關卡。

隨著實作的進行，越會覺得，Message Queue 包含了各方面知識，結合許多基本功與理論，才行誕生出來的成果。從基本的演算法、資料結構、同步 \ 非同步處理、Design Pattern；資料傳輸用的協定，如 gRPC、 AMQP 、MQTT；維持系統穩定的 不死性、獨立性、擴充性、監控；分散式系統的 AICD、狀態機；分派任務的 QoS等等，實在是族繁不及備載。

雖然，隨著文章鋪陳展開，無法全部說明或實作。但上面提到的關鍵字，都是接下來三十天會遇到的難關。如果有理解不正確或更好的作法，也請各位給與指點。

實作的所有的程式與迭代過程，均會上傳到 Github 上。對程式有任何看法或建議，都在可以上面討論。

題外話，本來只是單純用來驗證與實驗的專案，就很隨性的給一個 EMQ 的名稱。說白了，就是 Ean's Message Queue，但寫著寫著，就有了感情。後來，決定給這個專案換個名字，就叫 Flora Message Queue, FloraMQ 。

就算目前這個 MQ 不管在實用性或性能上，離真正能應用於商業環境還有一大段距離。但只要我持續投入，它一定可以像植物一樣慢慢的成長。

2. 系列文章的寫法

我相信，沒有一個軟體系統，是一開始就可以達到完美設計。而是有了基本功能後，隨著環境的演進，自然的產生不同的需求。

隨著克服一個一個的需求，逐漸的進行軟體的迭代，盡可能的朝向完美前進。

接下來的文章，會從 Queue 的基本概念作為切入點。隨著需求的不同，持續的改進，從單一的模組，演進為一個函數庫。從程式內使用的函數庫，成長為分散式的架構。

3. Queue 的基本概念

就筆者自己的認知，Queue的本質，就是做為資料載體的暫存與緩衝區，同時，它具備**先進先出入(First In First Out, FIFO)**的特性。

在演算法中，有些演算法使用 Queue 做為操作記錄資料的載體，例如針對二元樹的尋訪(Traversal)，廣度優先搜尋(Breadth First Search)，都是活用 Queue FIFO 的特性。

有時，資料本身的數量有限，但有多個對象，同時需要取得資料。使用 Queue 來控制資料的處理速度，或是調配資源的的方式，作為資料配置最佳化的方式之一。

但最常用的，就是做為跨執行緒、跨行程、到跨系統之中的通訊使用。通常而言，產生資料的一方，與處理資料的一方，處理的速度不一相同。所以，你會發現，它們經常是採為非同步的方式處理資料。

而 Queue 特性，不管是暫存與緩衝、或是 FIFO，正好符合它們的情況。自然而然，就成為它們的第一選擇。