1、靶期業務及框架基本處理流程

整體來看，靶期業務業務處理流程可分為三個環節：

前處理(Job前處理)->主處理(主要業務)->后處理(Job后處理)。

其中，前處理可能是取得靶期日付或者一些執行主處理前的準備工作，后處理主要是靶期執行結果履歷更新等。

注：實際中的靶期業務處理可能只包含以上的部分環節

框架的具體執行處理流程如下圖所示：

?

Fig.1 靶期業務執行流程圖

描述：

整個流程由JobExecutor組件啟動，然后調用JobManager組件的work方法，JobManager類是整個業務處理的核心類，靶期業務的前處理、主處理、后處理都在其work方法中完成。圖中所示為主處理的執行過程，前處理和后處理均由JobManager類綁定的StandardSupportProcessor類實例調用具體的SupportLogic實現類（由用戶開發）完成。主處理過程首先調用WorkQueueFactory的getWorkQueue方法生成一個指定長度的隊列（Queue），然后調用一個Collector從DB或文件中取得原始數據，在取得數據過程中，Collector實現類會調用一個CollectedDataHandler接口的實現類實例（具體來說就是Chunker類）將原始數據按照一定大小（ChunkSize）對原始數據進行分組（Chunk），然后把這些分組的Chunk放到之前生成的隊列里。最后，值得一提的是，這里為了表述更加方便清晰，并沒有嚴格遵照程序實際的執行流程。實際上，在JobManager類調用WorkQueueFactory的實現類（StandardWorkQueueFactory）實例生成Chunk隊列的時候，會同時提交生成指定個數（multiplicity）的隊列處理線程（QueueProcessor），這些處理線程將從隊列里逐個取出（take）作業單元（Chunk），然后調用JobWorker實例進行實際的業務邏輯處理。從實際的示意圖上反映來看，JobManager類的兩個分支（collect和process——其實是兩個不同的線程）是同時都在進行的，并沒有嚴格意義上的先后順序之分。

注：1.這里創建的隊列是Java5提供的ArrayBlockingQueue實例，是線程安全的。

2.以上描述僅為基本執行流程（不包含Partition,ControlBreak,Restart機能）。

事務處理★

事務處理主要針對DB相關的一些操作步驟(如修改、刪除數據記錄)，貫穿了靶期業務流程的每一個環節。具體來說，框架采用了Spring提供的編程式事務管理模型，首先利用Spring IoC容器提供一個JDBC DataSourceTransanctionManager實例，然后通過注入到不同事務處理類的相應屬性來提供事務處理機能。

?

1).框架提供了三種類型的事務處理模型：

以chunk為單位的事務處理

全部chunk作為單一事務處理

無事務處理

?

2).Terasoluna框架對事務處理進行了一系列靜態封裝，與Spring聲明式事務相比，這種靜態封裝就是在方法調用前后(切點)靜態插入了事務處理的代碼。

例舉抽象模型如下：

public interface Workable{

??????? void work();

}

public class TransanctionalWorker implements Workable{

??????? private Workable jobWorker = null;

??????? public void work(){

??????? ??? beginTransanction();

??????? ??? jobWorker.work();

??????? ??? commit();——or rollback();

}

}

?

3).用戶可根據實際業務來決定是否使用事務處理以及具體采用哪個事務處理的模型。

文件和DB操作(DI注入)

框架提供了統一的抽象封裝和細節實現，由于封裝抽象層次太多，在此就不進行一一列舉了（可參見靶期框架說明文檔）。

異常處理(ExceptionHandler) (DI注入)

框架提供統一的抽象接口及默認實現類：

JobExceptionHandler

??????? |——StandardJobExceptionHandler

Message處理—如何獲得message？

1).FileMessage：(DI注入)

框架提供統一的抽象接口及默認實現類：

MessageAccessor

??????? |—— MessageAccessorImpl

2).DBMessage：（……）

多線程：Why multiple threads?

多線程能夠更好的工作：多線程減少了單個線程提交的更新數據量，假設更新單個數據的成功率一定，那么這樣做無疑將會提高單個線程成功更新的概率。而且從執行過程來看，多線程要比單線程更為靈活有效。

?

Fig.2 多線程執行示意圖

描述：

如圖，多線程主要用于處理作業單元隊列，具體來說，它們從隊列中取得作業單元并調用具體業務邏輯處理類來進行實際的業務處理，是作業隊列的消費者（Consumer）。

分割（Partition）機能

?

Fig.3 分割Job示意圖

描述：

從圖中很明顯可以看到，整個Job被按照分割Key劃分成了多個子Job進行處理。值得注意的是，這里主Job（或者叫父Job）的隊列不再是存放Chunk（原始數據）了，而是存放了多個不同的PartitionRowObject（含不同的分割Key，代表了不同的子Job）。不同的子Job再從DB或者文件里以分割Key為參數取得原始數據，進一步按照ChunkSize分割成Chunk放入各自的隊列里。

其他關鍵機能

ControlBreak機能：

類型(按break范圍從小到大排列)。

1） ControlBreak(Chunk內發生)

2） ChunkControlBreak(Chunk切換時發生)

3） TrunsChunkControlBreak(跨Chunk發生)

?

其中，ChunkControlBreak在對應Job里只能定義一個，其它兩個可定義多個，但是TrunsChunkControlBreak必須在ChunkControlBreak存在時才能被定義。

注：以上Break處理和Transanction處理只在執行范圍上有所聯系，兩者之間并無實際意義上的相互影響。

Break執行示意圖

?

Fig.4 Break機能執行示意圖

描述：

圖中定義了兩個不同的Break Key，它們可以看做是對數據記錄中不同字段的一個組合，而Break Key的值即是對應字段值的組合，當Break Key對應的相鄰數據記錄值不同（也就是Break Key值發生變更）時，就會調用相應的Break處理。

Restart機能：

?

Fig.5 Restart機能示意圖

描述：

如圖所示，Restart機能啟動時，在Job完成事務處理后，如果DB數據成功更新，則會不斷更新Restart管理Table相應的restart-point（其實就是處理完了或者是已經Commit的記錄數）和作業內容（job context）。當錯誤發生以后，會重新啟動執行該Job，此時會從Restart管理Table中恢復該Job的內容，并跳過之前更新的記錄繼續往下進行處理。最后當成功執行完畢時，還要把之前保存的相關Restart信息從DB中清除。

框架概述

從框架整體來看，整個terasoluna框架是由搭積木的方式來進行封裝和開發的，底層由Spring提供各種框架和用戶類的組件（也就是類的實例），用戶只需開發出核心業務的實現類，然后根據業務需求對各類組件進行組裝，即可實現一套處理特定業務的工作流程；而從單個實現機能來看，每個機能都有一個統一的接口，通過注入不同的實現類，就可實現不同的處理。

機能擴展

由用戶開發特定機能實現類，然后在配置文件里替換原有的處理該機能的組件即可。

轉載于:https://www.cnblogs.com/feifeihu/archive/2012/08/15/2640318.html

總結

以上是生活随笔為你收集整理的Terasoluna（中文）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。