LTS和其餘解決方案的比較(官方)

主要根據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在 這種場景下提供的特性有，提供統一的後臺監控和後臺管理。當某次定時任務執行失 敗，會執行重試操做，並提供執行日誌．