主要根據LTS支持的幾種任務（實時任務、定時任務、Cron任務，Repeat任務）和其他一些 開源框架在應用場景上做比較。
實時任務，實時執行
這種場景下，當任務量比較小的時候，單機都可以完成的時候．自己采用線程池或者去 輪訓數據庫取任務的方式（或者其他方式）就可以解決 · 但如果是任務執行時間比較長 或者任務量比較大，單機不足以滿足需求的時候，就需要自己去做分布式的功能，還有 很重要的是，怎么做容錯，怎么保證同一個任務只被一個節點執行，怎么解決執行失敗 異常的情形等等，你就需要自己去做很多事情，頭可能就大了。這時候 LTS 就派上用場 了．因為這些問題 LTS 都幫你解決了，你只需關注你的業務邏輯，而不用為上面的這些 事情而煩惱。當然這時候有人可能會想到如果用 MQ 去解決，利用 MQ 的異步去解耦， 也同時可以實現分布還有容錯等。當然有時候是可以的，為什么說是可以的呢，因為 LTS 的架構也和 MQ 的類似， JobClient 相當於 MQ 的 Producer , JobTracker 相當於 MQ 的 Broker , TaskTracker 相當於 MQ 的 Consumer ，經過我這么一說，是不是覺得 貌似是很像哈。但是我又為什么說是有時候是可以的呢，而不是一定是可以的呢，因為 如果你同一個任務（消息）提交 MQ 兩次． MQ 隊列中有兩條同樣的任務消息，那么當 你這個任務不能有兩個節點同時執行的時候（同時執行一個任務可能出現各種問題） , MQ 就不能滿足了，因為他不知道你這兩條消息是同一個任務，它會把這兩條消息可能 會發給兩個不同的節點同時執行（或者同一個節點的不同線程去執行），這時候你就需 要自己去做一些事情去保證同一個任務不能同時被兩個線程（或節點）去執行問題，這 時候頭又大了，那么 LTS 又派上用場了，以為 LTS 就可以保證這一點。說到任務調度． 很多人一下就想到了 QuartZ ，對於這種實時任務的情況． QuartZ 是不太適合的，它也 不能很好的解決故障轉移（譬如執行中的節點突然停掉了， QuartZ 不能將這個執行中的 任務立馬分配給其他節點執行，最多設置了 QuartZ 的可恢復性，在停掉的節點重啟之后 重新執行該任務．但如果這個節點再也不啟動起來了呢？那就只能呵呵了）等問題，這 類場景 QuartZ 就不做比較了。有些人可能問，說了這么多，你倒是舉個例子呀。嗯，我 舉幾個例子： 1 ．發短信驗證碼，這種可以用 MQ 去實現，也可以單機去實現（如果你 量不大的話），當然 LTS 也是可以的．如果你量非常非常大的話，建議還是用性能比較 好的 MQ 代替 2 ．實時的給在線用戶算數據，觸發者是用戶自己（自己手動點），但是 算任務的只能同時由一個線程去執行，這是就可以用 LTS 了。
定時任務
某個時間點觸發這種場景下，和實時任務相比，只有一個不同，就是要指定一個時間點 去執行，可能是 1 個小時之后，可能是 1 天之后．也可能是 1 天，小時之后。有些人可 能用輪訓的業務數據庫的方式去解決，輪訓業務數據庫有什么問題呢．當然你數據量很 小我就不說了。如果你數據量還比較大的情況下，輪訓數據庫，勢必會影響業務查詢， 如果有其他業務查詢的話。還有就是對於分布式的支持不是很好，還有當表中存在多種 不同執行（延遲）時間的任務，這個輪訓頻率就比較關鍵了，太短，影響性能，太長， 影響業務，執行不及時．導致任務執行延遲太久，等等。這時候如果用MQ ，雖然有些 MQ 支持延遲隊列 (RabbitMQ , RocketMQ 等）．但他們都是指定的一些特定的 Level 級 別延遲，但是不支持任意時間精度．譬如， 1 min , 5 min . 10 min 等等，但如果是 7 分 鍾，或者 20 天之后呢。如果 MQ 支持任意時間精度，那么它的性能就只能呵呵了，這 種情況 MQ 就排除了，但是如果 MQ 的這些特定的 Level 剛好滿足你的需求，那么選 MQ 也是可以的。再說說 Quartz吧， Quartz 可以支持定時任務．支持某個時間點觸發， 也支持集群，它在架構上是分布式的，沒有負責幾種管理的節點。 Quartz 是通過數據庫 行級鎖的方式實現多線程之間任務爭用的問題。行鎖有嘟些特點呢，開銷大，加鎖慢， 會出現死鎖，並發度相比表級鎖，頁級鎖高一點。但是在任務量比較大的時候，並發度 較大的時候，行級鎖就顯得比較吃力了，而且很容易發生死鎖。那么 LTS 是怎么解決並 發性的問題的呢， LTS 采用預加載和樂觀鎖的方式，批量的將部分要執行的任務預加載 到內存中，所以在取任務的時候只需要兩步： 1 ．從內存中取到一個任務，當然內存中 保證同一個線程拿到同一個任務是很容易的也是很高效的， 2 ．將拿到的這個任務對應 的數據庫記錄鎖住，那么這里采用樂觀鎖， CAS 的方式去修改記錄（如果任務己經被別 的節點拿走了，那么重新執行 1 , 2 步，這種己經被別的節點拿走的情況，主要是在多個 JobTracker 的情形下，單個 JobTracker 不會出現這種情況，但是在多個 JobTracker 下，內存中的預加載數據采用不同步長的方式來減小兩個 JobTracker 內存中數據重復的 概率，很好的解決了這個問題，這里稍微提下 》 ，所以這個時候LTS相對於QuartZ 的優 勢一下就體現出來了。還有就是上面說的 Quartz 對故障轉移做的不是很好。還有就是當 QuartZ 對應的 MySQL 數據庫掛了，這時候問題就來了客戶端提交的任務提交不成功 了，那么有人會想將這些數據保存在內存中，等 MySOL 重啟起來了再重試提交，那么 如果你當前節點也掛了呢，你內存中的數據就會全部丟失了．所以這時候你需要自己額 外的去做一些失敗任務本地持久化的工作．不過如果你用LTS的話， LTS 支持Failstore ，任務提交失敗了，自動幫你本地持久化，然后待 JobTracker 可用的時候重試，不管你 是 JobTracker 掛了，還是 JobTracker 對應的數據庫掛了，都是 ok 的。舉個例子吧，在 一個小時之后給某些用戶發短信，或者當用戶點擊退款操作之后，從點擊退貨的這個時 間點開始， n 天后將這個退款關閉。
周期性任務(Cron,Repeat)
這種場景下，和定時任務相比，不一樣的地方，就只有．這個是會重復執行的，相當於 重復執行的定時任務。所以這種場景下的對比，可以繼續考照定時任務的對比。 LTS在 這種場景下提供的特性有，提供統一的后台監控和后台管理。當某次定時任務執行失 敗，會執行重試操作，並提供執行日志．