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