近期公司在做架構梳理已經項目架構方向，不知不覺就引起了使用“work”跑資料還是用“MQ”進行跑資料的争論！
對于争論這件事在各行各業都有，其實我覺得針對“争論”這個詞的根源在于一件事情有很多解決方案，每個人的認知不同，
給出的解決方案也不同。然而如果有一個對實際情況都了解和對解決問題有充足認知的情況下，我想他是會權衡利弊的。
我們先列舉幾個已經算是比較成熟的開源架構：
WORK：TBschedule、Quartz、spring schedule、JDK的time ，線程池定時等；
MQ：RocketMQ、RabbitMQ、Kafka、ActiveMQ、MSMQ、ZeroMQ等等；
好，廢話不多說，我們就事論事，我們就單純的從以下幾個角度來評論以下到底誰（work/mq）更有優勢：
1、易用性
2、可擴充性
3、可監控性
4、性能
5、可堆積資料量
6、穩定性
以上是我列出的幾個對比選項，我們将逐一解說。（對于work和MQ的選型不是本人讨論的範圍不做深入讨論）
我們就拿上面列出的work系列的第一個與MQ系列的第一個進行比較：
Tbshcedule與RocketMQ，這兩個都是阿裡開發并開源的比較起來可能會更好一點。擂台開始
WORK：TBSchedule最新版本使用zookeeper作為注冊一緻性等功能的調和器，zookeeper本身很穩定不用怎麼管理，
開發代碼是直接繼承接口，然後自己實作業務邏輯，處理完成之後需要做狀态回傳處理（比如更新資料狀态）
處理失敗，會多次重複處理可能會因為一條資料的失敗而導緻後面資料處理不了（除非自己做優先級政策）
定義資料平均分發政策。
讀取資料會平均分發到對應的處理器類，可批量，部署的時候需要調整政策，最小時間間隔是1s
RocketMQ：開源的架構模式為多個節點注冊到命名服務，生産者與消費者以及broker的分發負載通過命名服務來管理。
開發代碼同樣是繼承接口實作，然後資料分發到對應的處理器類，最後成功與否傳回對應的ack，處理失敗不影響
後續資料處理，失敗資料會延遲重複處理多次。同樣可批量，沒有定時執行的概念，有資料就處理，幾乎不會等待。
小結：處理資料同樣都依賴資料狀态标記，但是RocketMQ已經為我們實作了基本失敗處理的簡單機制，不是特别的情況，
已經足夠用了，這是優勢之一，資料處理狀态不用與第三方系統互動，這是優勢之二。其中有TBSchedule有一點就是
自己定義資料平均分發政策，目前不能評判是缺點還是優點，文章後面會說明
可擴充性從兩個方面講，一個是基礎服務，一個是消費服務。
基礎服務就是我用這兩個架構的時候肯定需要相關的基礎作為支撐，比如TBSchedule需要zookeeper，RocketMQ需要borker等
基礎服務：
WORK：TBSchedule需要zookeeper，zookeeper的可擴充性比較一般，是CP型的，不過zookeeper非常穩定可以互相抵消
RocketMQ：需要架設broker和namespace兩種服務，兩種服務都是可以平行橫向擴充的，
然而RocketMQ的主要資料交換服務broker是可以線上透明擴充的，不用重新開機生産和消費用戶端
小結：基礎服務說實話可比性不是很強烈，都比較穩定，沒有相差太大。
消費服務：
WORK：TBSchedule任務處理用戶端可以直接copy一份然後運作起來，注冊一下，調整一下線程配置設定，雖然有步驟但是還算簡單
RocketMQ：直接copy處理程式運作包啟動運作就OK了，線程會自動調節（開發的時候會根據伺服器配置業務量等調整一個合理的範圍）
小結：是不是感覺RocketMQ更友善那，大家了解了架構之後自然會知道兩個的差別。
WORK：TBSchedule隻有任務主機及線程存活監控監控，資料擠壓以及處理速度需要自己額外開發
RocketMQ：對資料處理執行個體（消費端）等都有資料處理速度和待處理積壓量相關顯示。
小結：不知道大家更需要哪個，哪個更好，自己斟酌選擇吧！這個不多說
其實對于性能我就不展開說了沒什麼可比性，關鍵是取決于業務處理的速度，如果非要較真的話，
TBSchedule每個線程執行有1秒的停頓，不過這個可以忽略（不要告訴我說你就處理10幾條資料，每條幾毫秒就處理完了）
雖然不較真但是從第一點易用性看還是有差别的，因為RocketMQ做資料狀态回傳的時候應該會更快，因為不依賴其他資料載體，
因為資料載體就是broker本身，優化的更好。
5、可堆積數量
兩個架構的堆積數量也不太好比較，因為TBSchedule依賴的是其他資料載體（比如資料庫），
RocketMQ使用的是索引加檔案幾乎是無限堆積（為什麼是“幾乎”，自行查資料，關鍵取決于磁盤大小）
這裡反過來對第四點做一點補充就是，堆積量上來之後對于RocketMQ性能幾乎沒什麼影響，
但是對于TBSchedule可能就取決于資料載體了
這個也不展開讨論，直接說實際使用情況
TBSchedule會有時不時的莫名其妙的假死現象
RocketMQ最多是因為硬體承載量不夠而拒絕服務，但是還是能提供服務的。
大家自己心裡評判吧！
可能有很多人說這兩個東西是沒有可比性的，因為根本就是不同的架構，一個是定時任務一個是消息傳輸，說的很對，但是你反過來想
都是為了處理業務資料，都是将資料從一種狀态或結構轉換成另一種。很多情況下兩者都可以做完同樣的事情，是以就帶來了争論和選擇
如果你那RocketMQ和作業系統linux比較我想這真的是沒有可比性的。
最後還是簡單總結一下
Work和MQ都是随時代或者說是技術發展的過程逐漸演變的，work是定時任務的進階擴充，MQ是伴随着業務發展而逐漸流行起來的架構設計
兩者都在企業資訊化發展中起到關鍵的作用，然而work卻在逐漸慢慢消退，但是不太可能會被替代（這裡不是指被MQ替代），當然更不會被MQ替代
MQ架構現在發展非常迅猛，雖然在一段時間内還會非常迅猛，同樣時代在變化，技術在發展，慢慢隕落是不可避免的，隻是時間問題而已。
兩個架構都有自己更适合的使用場景（使用場景包括人和業務這裡就不具體舉例說明了），脫離業務的設計都是耍流氓。
希望本篇文章對你有幫助。