TaskRunner:

2013-01-20 15:42:26,323 [main] INFO? [org.mh.rpc.task.TaskRunner] – client get jobdetail:JobDetail ‘JobGroup_1.MyJob_1′:? jobClass: ‘org.mh.rpc.quartz.GetSumTask isStateful: false isVolatile: false isDurable: false requestsRecovers: false
2013-01-20 15:42:26,329 [main] INFO? [org.mh.rpc.task.TaskRunner] – client get trigger:Trigger ‘Trigger_Group_1.Trigger_1′:? triggerClass: ‘org.quartz.SimpleTrigger isVolatile: false calendar: ‘null’ misfireInstruction: 0 nextFireTime: null
2013-01-20 15:42:26,382 [main] INFO? [org.quartz.simpl.SimpleThreadPool] – Job execution threads will use class loader of thread: main
2013-01-20 15:42:26,411 [main] INFO? [org.quartz.core.SchedulerSignalerImpl] – Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
2013-01-20 15:42:26,411 [main] INFO? [org.quartz.core.QuartzScheduler] – Quartz Scheduler v.1.6.5 created.
2013-01-20 15:42:26,413 [main] INFO? [org.quartz.simpl.RAMJobStore] – RAMJobStore initialized.
2013-01-20 15:42:26,413 [main] INFO? [org.quartz.impl.StdSchedulerFactory] – Quartz scheduler ‘DefaultQuartzScheduler’ initialized from default resource file in Quartz package: ‘quartz.properties’
2013-01-20 15:42:26,413 [main] INFO? [org.quartz.impl.StdSchedulerFactory] – Quartz scheduler version: 1.6.5
2013-01-20 15:42:26,415 [main] INFO? [org.quartz.core.QuartzScheduler] – Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
org.mh.rpc.quartz.DemoTask@1b66b06: executing task @Sun Jan 20 15:42:26 CST 2013

上面是一個簡單的demo，演示了如何通過RPC將任務調度給節點去執行，對于Quartz來說，任務的形式可以千變萬化，關鍵就看怎么去使用了，分發到多個節點上執行的話，就還需要對任務的信息做更多的封裝了。

(本文已被閱讀2次)

在hadoop中，主從節點之間保持著心跳通信，用于傳輸節點狀態信息、任務調度信息以及節點動作信息等等。 hdfs的namenode與datanode，mapreduce的jobtracker與tasktracker，hbase的hmaster與 regionserver之間的通信，都是基于hadoop RPC。Hadoop RPC是hadoop里非常基礎的通信框架。hadoop 2.0以前hadoop RPC的數據序列化是通過實現自己定義的Writable接口實現，而從hadoop 2.0開始，數據的序列化工作交給了ProtocolBuffer去做。關于Hadoop RPC的實現原理已經有很多文章進行了詳細的介紹（源碼級強力分析hadoop的RPC機制，Hadoop基于Protocol Buffer的RPC實現代碼分析-Server端，帶有HA功能的Hadoop Client端RPC實現原理與代碼分析），這里就不在贅述了。下面就直接引入問題和方案吧。 問題 工作中經常需要在定時任務系統上寫一些定時任務，隨著業務規模的增長和擴大，需要定時處理的任務越來越多，任務之間的執行間隔越來越小，某一時間段內（比如0點、整點或半點）執行的任務會越來越密集，只在一臺機器上執行這些任務的話，會出現較大的風險： 任務并發度較高時，單機的系統資源將成為瓶頸 如果一個任務的運行占用了整個機器的大部分資源，比如sql查詢耗費巨大內存和CPU資源，將直接影響其他任務的運行 任務失敗后，如果仍然在同一臺節點自動重新執行，失敗率較高 機器宕機后，必須第一時間重啟機器或重新部署定時任務系統，所有任務都不能按時執行 等等 方案 可想而知的是，可以通過將定時任務系統進行分布式改造，使用多個節點執行任務，將任務分發到不同節點上進行處理，并且完善失敗重試機制，從而提高系統穩定性，實現任務系統的高可靠。 既然是在多個節點之間分發任務，肯定得有個任務的管理者(主節點)，在我們現有的系統中，也就是一套可以部署定時任務的web系統，任務代碼更新后，部署好這套web系統，即可通過web頁面設置定時任務并且進行調度(在單個節點上執行)。執行任務的節點(子節點)有多個以后，如何分發任務到子節點呢，我們可以把任務的信息封裝成一個bean，通過RPC發布給子節點，子節點通過這個任務bean獲得任務信息，并在指定的時刻執行任務。同時，子節點可以通過與主節點的心跳通信將節點狀態和執行任務的情況告訴主節點。這樣其實就與hadoop mapreduce分發任務有點相似了，呵呵，這里主節點與子節點之間的通信，我們就可以通過Hadoop RPC框架來實現了，不同的是，我們分發的任務是定時任務，發布任務時需要將任務的定時信息一并發給子節點。 實現 單點的定時任務系統是基于Quartz的，在分布式環境下，可以繼續基于Quartz進行改造，任務的定時信息可以通過Quartz中的JobDetail和Trigger對象來描述并封裝，加上任務執行的入口類信息，再通過RPC由主節點發給子節點。子節點收到封裝好的任務信息對象后，再構造JobDetail和Trigger，設置好啟動時間后，通過入口類啟動任務。下面是一個簡單的demo。 以下是一個簡單的定時任務信息描述對象CronJobInfo，包括JobDetailInfo和TriggerInfo兩個屬性： 任務信息JobDetailInfo，由主節點構造，子節點解析構造JobDetail對象： 任務觸發器信息TriggerInfo ，由主節點構造，子節點解析構造Trigger對象： 主從節點通信的協議： 在這個demo中，主節點啟動后，啟動RPC server線程，等待客戶端（子節點）的連接，當客戶端調用heartbeat方法時，主節點將會生成一個任務信息返回給客戶端： demo任務類，打印信息： 子節點demo，啟動后連接主節點，遠程調用generateCronJob方法，獲得一個任務描述信息，并啟動定時任務 先啟動TaskScheduler，再啟動TaskRunner，結果如下： TaskScheduler: 2013-01-20 15:42:21,661 [Socket Reader #1 for port 8888] INFO? [org.apache.hadoop.ipc.Server] – Starting Socket Reader #1 for port 8888 2013-01-20 [...]

原文地址：將Hadoop RPC框架應用于多節點任務調度, 感謝原作者分享。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com