|
靶期业务及框架基本处理流程
整体来看，靶期业务业务处理流程可分为三个环节： 前处理(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机能： 1. 类型(按break范围从小到大排列)。 1） ControlBreak(Chunk内发生) 2） ChunkControlBreak(Chunk切换时发生) 3） TrunsChunkControlBreak(跨Chunk发生) 其中，ChunkControlBreak在对应Job里只能定义一个，其它两个可定义多个，但是TrunsChunkControlBreak必须在ChunkControlBreak存在时才能被定义。 注：以上Break处理和Transanction处理只在执行范围上有所联系，两者之间并无实际意义上的相互影响。 2. 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提供各种框架和用户类的组件（也就是类的实例），用户只需开发出核心业务的实现类，然后根据业务需求对各类组件进行组装，即可实现一套处理特定业务的工作流程；而从单个实现机能来看，每个机能都有一个统一的接口，通过注入不同的实现类，就可实现不同的处理。 机能扩展 由用户开发特定机能实现类，然后在配置文件里替换原有的处理该机能的组件即可。 //提示我只能提供这个，没用过 |
|
|
来自： 昵称9376223 > 《terasoluna》
