定时任务管理器 TimingTaskManager -- ESBasic 可复用的.NET类库(08)

1.缘起:

    假设我们的报表系统需要在每天的00:05:00统计前一天的报表数据,需要在每周一的00:30:00统计上周的报表数据,又需要在每月1日的00:30:00统计上月的报表数据。

这些报表统计任务是很常见的系统需求,对于类似这样的在指定时刻执行的定时任务,我使用ESBasic.Threading.Timers.TimingTaskManager(定时任务管理器)来处理它。

TimingTaskManager与前面讲的回调定时器CallbackTimer的区别在于,CallbackTimer是参考当前时间再延迟一段时间后执行,而TimingTaskManager管理的任务是要求在指定的具体时间点执行。

    定时任务管理器的形象示意图如下: 

     

2.适用场合:

    如果你的任务满足以下条件,则可以使用TimingTaskManager来解决任务的定时执行:

(1)任务需要在每小时、每天、每周、或每月的某个固定的时间点执行。

(2)可以允许任务执行的时间点与期望的时刻存在一定的误差。

 

3.设计思想与实现

    在介绍TimingTaskManager之前,我们要先介绍TimingTask这个类,它表示一个定时任务,正是它封装了任务的执行频率、执行的具体时间和要执行的目标方法。TimingTask的类图如下:
          
      我们看到,ExcuteTime属性是一个ShortTime类型,指定要执行任务的具体时刻。而TimingTaskType属性决定了TimingTask执行的频率,TimingTaskType定义如下:

    [EnumDescription("定时任务的类型")]
    public enum TimingTaskType
    {
        [EnumDescription("每小时一次")]
        PerHour,
        [EnumDescription("每天一次")]
        PerDay,
        [EnumDescription("每周一次")]
        PerWeek,
        [EnumDescription("每月一次")]
        PerMonth
    }

要注意的是,如果TimingTaskType属性的值为PerHour,则将忽略ExcuteTime的Hour属性。

同样的,DayOfWeek属性只有在TimingTaskType属性的值为PerWeek时才有效,表示在周几执行。Day属性只有在TimingTaskType属性的值为PerMonth时才有效,表示在每月的几号执行。

在TimingTask的实现中,IsOnTime方法的实现特别要引起注意。因为我们的定时任务管理器是基于定时器Timer工作的,而定时器的扫描时间是有间隔的,所以,在某个ExcuteTime所代表的真正的执行时间点的左右的两个扫描时刻,可能都会被认为是符合执行条件的(比如,两个扫描时刻距离真正执行时刻的距离都在1秒之内),如果是这样,目标任务将会被执行两次――这是我们不希望发生的。为了避免这种情况的出现,我们在TimingTask中使用lastRightTime成员来记录上次执行的时间,如果lastRightTime与当前时间的差值2倍的扫描间隔以内,则将认为当前时间不符合条件。正如下面代码所示:

            #region 防止在临界点时,执行两次
            TimeSpan span = now - this.lastRightTime;
            if (span.TotalMilliseconds < checkSpanSeconds * 1000 * 2)
            {
                return false;
            } 
            #endregion

      接下来,我们将注意力转移到TimingTaskManager上来。有了TimingTask的封装,TimingTaskManager所要做的事情就非常简单,其要点归结如下:

(1)TimingTaskManager使用Timer来进行定时扫描,以判断每个任务是否到了要执行的时间点。TimerSpanInSecs属性指定了扫描的时间间隔。

(2)当某个任务的执行时刻到来,TimingTaskManager会异步执行该任务,这样不会阻塞当前的foreach遍历。

(3)TimingTaskManager提供了RegisterTask和UnRegisterTask方法,用于在运行的过程中可以动态的增加或移除任务。

(4)TimingTaskManager必须对任务列表taskList进行加锁,以确保集合的线程安全。因为定时器本身就是在另外一个线程上执行Worker方法的,如果在执行Worker方法的同时,有其它线程调用RegisterTask和UnRegisterTask方法,就会导致Worker方法中的foreach遍历动作抛出异常。

 

4. 使用时的注意事项

(1)由于TimingTaskManager采用Timer进行定时扫描,所以,任务执行的时间点与期望的时间点的最大误差就是TimerSpanInSecs的值。由于TimerSpanInSecs能取的最小值为1秒,所以TimingTaskManager能够达到的最小误差为1秒。如果你的任务期望被更精确的执行,那么TimingTaskManager就不适合你。

(2)TimingTaskType指定的频率只能是:每小时一次、每天一次、每周一次、每月一次。但是对于一个类似你希望在每周二、四中午12:00:00执行的任务,我们可以采用变通的做法,那就是将其视为两个任务:一个在每周二的中午12:00:00执行,另一个在每周四的中午12:00:00执行。如此,我们可以使用TimingTaskManager提供的最基础的定时频率经过组合来处理更高级、更复杂的定时任务。

(3)由于ITimingTaskExcuter的ExcuteOnTime方法是在后台线程池中的某个线程上执行的,所以其抛出的任何异常都会被忽略。最好的办法是,在实现ExcuteOnTime方法是确保在其内部catch住了所有的异常。

 

5.扩展

       定时任务管理器TimingTaskManager暂时没有任何扩展。

注: ESBasic已经开源,点击这里下载源码。
    ESBasic开源前言

时间: 2024-10-27 13:54:03

定时任务管理器 TimingTaskManager -- ESBasic 可复用的.NET类库(08)的相关文章

定时刷新缓存管理器 IRefreshableCacheManager --ESBasic 可复用的.NET类库(16)

1.缘起:     为了提升系统的性能或减轻数据库的压力等原因,我们经常在系统中使用缓存来把那些经常使用的数据保留在内存中.如果因为某些原因,缓存中这些经常使用的数据不能及时与数据源进行同步更新,那么采用定时刷新缓存中的数据有可能就是一种合适的选择.     如果你的缓存是定时刷新,那么你就需要自己为其维护一个定时器或循环引擎.如果你的系统中像这样定时刷新的缓存有多个,而且每个缓存定时刷新的时间间隔又要求不一样,那么,使这些缓存按照你预想的情况进行运转,你就需要花费一些气力.     我设计了定

Round缓存管理器RoundCacheManager--ESBasic 可复用的.NET类库(26)

1.缘起:     在增量自动获取器章节的缘起部分,我们曾提到增量缓存,本节我们将深入探讨它以及用于管理增量缓存的管理器.我们还是以增量自动获取器章节提到的例子作为基础,并做更进一步的讨论.       OK,现在让我们开始这有趣的旅程. 首先,基于前面例子给出的上下文,我们知道IIncreaseAutoRetriever获取的增量是用于累积当天的已成交订单报表的."当天已成交报表"就是一个典型的增量缓存,每当有新的增量到来,都会累加到上面. 我们假设今天是2009.07.08,那么我

ESBasic 可复用的.NET类库(00) -- 开源前言(附下载)

自从03年正式使用.NET开发以来,已经走过了6个年头,这期间我积累了几套类库和框架,ESBasic便是其中最基础的一个类库.ESBasic是Enterprise Service Basic的缩写,虽然也简写为ESB,但是它和Enterprise Service Bus(企业服务总线)没有任何关系.ESBasic是我能够快速和高效开发应用程序的利器之一,开这个专门的blog是想将它介绍给大家,希望能对大家有所启发. ESBasic覆盖的内容包括:对象管理.插件.网络(Socket).多线程.Em

回调定时器ICallbackTimer --ESBasic 可复用的.NET类库(07)

 1.缘起:     举个例子也许就能够说清楚回调定时器的用途.假设我的订单系统接收各种不同类型的订单,当订单A进来时,系统根据订单的类型和其它特征进行综合判断后,决定A订单要在2秒之后被方法M1处理:接下来收到的B订单经过同样的判断后,决定要在10秒后被方法M2处理,--.这时候就可以用回调定时器来管理这些将要被延迟一定时间再执行的任务.     当然,我们可以使用定时器或前面介绍的循环引擎来实现这样的功能,只不过我们自己需要手动管理注册的定时回调任务,并且定时检查每一个未处理订单是否已经到了

优先级管理器 IPriorityManager -- ESBasic 可复用的.NET类库(14)

1.缘起:     假设我们的订单处理系统所要处理的订单是有优先级的,也就是说,不同的订单类型所要求被处理的紧迫程度不同,对那些优先级高的注单要先处理,对于优先级低的注单可稍后处理.对于处于同一优先级的订单了,就按照其到达的先后顺序进行处理.     这是一个典型的管理具有优先级的对象的需求,注单就是具有优先级(With Priority)的对象.我设计了ESBasic.ObjectManagement.Managers.IPriorityManager优先级管理器(确切地说,应该称之为"具有优

心跳监测器 IHeartBeatChecker -- ESBasic 可复用的.NET类库(09)

1.缘起:     假设我们的C/S系统中服务端与客户端之间采用UDP进行通信,那么服务端如何知道每个客户端当前是否仍然在线了?有可能某个客户端一直没有退出,但是在很长一段时间内都没有与服务端作任何通信,那么服务端就应该认为这个客户端已经离线了吗?为了能让服务端掌握每个客户端是否在线的状态,我们可以这样做,只要客户端一启动起来,就每隔一段时间间隔(如10秒)就向服务端发一个"我还在线"的消息,以表明自己的状态.而服务端如果在一个更大的时间间隔内(如20秒)都没有收到某个客户端的任何消息

热缓存 IHotCache --ESBasic 可复用的.NET类库(19)

1.缘起:     假设我们有一个订单系统,现在这个系统要增加一个功能――允许客人查核他认为有问题的订单的详细信息.当客人觉得自己的某个订单不对劲时,他首先会从订单系统查询这个订单的详细信息,然后打电话告诉我们的客服有问题的订单的编号,客服再去查核,如果属实,客服还要进一步上报,如果该订单非常重要,则可能需要更进一步上报复查等.     从这个需求我们看到,同一个订单可能会在比较短的时间内查询数次甚至数十次,所以我们可以称这个订单为"热点"订单.而其它的成千上万的订单可能在一个月内都不

循环引擎 ICycleEngine --ESBasic 可复用的.NET类库(04)

 1.缘起: 有些系统需要每隔一段时间就执行一下某个动作,比如,一个监控系统每隔10秒钟就要检测一下被监控对象的状态是否正常,那这时我们就可以用到循环引擎了.     有人说可以使用.NET框架自带定时器如System.Threading.Timer,嗯,没错.但是若这个类使用不当可能会引发后台池线程耗尽的后果.因为Timer的定时事件触发实在后台线程池中的某个线程中处理的.也就是说Timer的每次定时事件触发都会用到一个线程,如果定时的时间间隔小于事件处理的时间,则后台线程池中将会有越来越多的

循环任务切换器 CircleTaskSwitcher -- ESBasic 可复用的.NET类库(06)

 1.缘起:     假设我的订单处理系统有这样的需求:将一天24小时分为4个时段,凌晨2:15到8:30采用A类型的处理器处理接收到的订单,8:30到14:00采用B类型的处理器,14:00到20:00采用C类型的处理器,20:00到第二天凌晨2:15采用D类型的处理器.     即我们的订单处理器需要在任一天的2:15.8:30.14:00.20:00这四个时刻发生切换,这就是一个循环切换器所要做的工作.     我设计了ESBasic.Threading.Application. ICir