靶期業(yè)務(wù)及框架基本處理流程
整體來看，靶期業(yè)務(wù)業(yè)務(wù)處理流程可分為三個環(huán)節(jié)：

前處理(Job前處理)->主處理(主要業(yè)務(wù))->后處理(Job后處理)。

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

注：實際中的靶期業(yè)務(wù)處理可能只包含以上的部分環(huán)節(jié)

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


Fig.1 靶期業(yè)務(wù)執(zhí)行流程圖

描述：

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

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

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

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



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

以chunk為單位的事務(wù)處理
全部chunk作為單一事務(wù)處理
無事務(wù)處理


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

例舉抽象模型如下：

public interface Workable{

        void work();

}

public class TransanctionalWorker implements Workable{

        private Workable jobWorker = null;

        public void work(){

            beginTransanction();

            jobWorker.work();

            commit();——or rollback();

}

}



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

文件和DB操作(DI注入)
框架提供了統(tǒng)一的抽象封裝和細節(jié)實現(xiàn)，由于封裝抽象層次太多，在此就不進行一一列舉了（可參見靶期框架說明文檔）。

異常處理(ExceptionHandler) (DI注入)
框架提供統(tǒng)一的抽象接口及默認實現(xiàn)類：

JobExceptionHandler

        |——StandardJobExceptionHandler

Message處理—如何獲得message？
1).FileMessage：(DI注入)

框架提供統(tǒng)一的抽象接口及默認實現(xiàn)類：

MessageAccessor

        |—— MessageAccessorImpl

2).DBMessage：（……）

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


Fig.2 多線程執(zhí)行示意圖

描述：

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

分割（Partition）機能

Fig.3 分割Job示意圖

描述：

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

其他關(guān)鍵機能
ControlBreak機能：

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

1） ControlBreak(Chunk內(nèi)發(fā)生)

2） ChunkControlBreak(Chunk切換時發(fā)生)

3） TrunsChunkControlBreak(跨Chunk發(fā)生)



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

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

2.       Break執(zhí)行示意圖


Fig.4 Break機能執(zhí)行示意圖

描述：

圖中定義了兩個不同的Break Key，它們可以看做是對數(shù)據(jù)記錄中不同字段的一個組合，而Break Key的值即是對應(yīng)字段值的組合，當(dāng)Break Key對應(yīng)的相鄰數(shù)據(jù)記錄值不同（也就是Break Key值發(fā)生變更）時，就會調(diào)用相應(yīng)的Break處理。

Restart機能：


Fig.5 Restart機能示意圖

描述：

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

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

機能擴展
由用戶開發(fā)特定機能實現(xiàn)類，然后在配置文件里替換原有的處理該機能的組件即可。




//提示我只能提供這個，沒用過