支持宕机自动恢复触发一次性或周期性任务执行的组件包-easyTask

easyTask

  • 一个方便触发一次性或周期性任务执行的工具包,支持海量,高并发,高可用,宕机自动恢复任务
  • 开源项目地址:https://github.com/liuche51/easyTask   请多多关注

Usage scenarios

  • 需要精确到秒的某一时刻触发任务执行。比如订单交易完成24小时后如果客户未评价,则系统自动给出评价。
  • 需要周期性的执行某个任务。比如每天下午6点,提醒员工下班关机。

Features

  • 使用简单
  • 秒级精度任务执行计划
  • 支持海量任务提交执行
  • 支持高并发执行任务
  • 支持任务持久化,宕机自动恢复任务计划
  • 支持自定义线程池、任务持久化保存路径

Architecture

Getting started

  • pom添加引用
<dependency>
    <groupId>com.github.liuche51</groupId>
    <artifactId>easyTask</artifactId>
    <version>1.0.1</version>
</dependency>
  • 定义好您要执行的任务类 Define the task class you want to perform
public class CusTask1 extends Schedule implements Runnable {
    private static Logger log = LoggerFactory.getLogger(CusTask1.class);

    @Override
    public void run() {
        Map<String, String> param = getParam();
        if (param != null && param.size() > 0)
            log.info("任务1已执行!姓名:{} 生日:{} 年龄:{} 线程ID:{}", param.get("name"), param.get("birthday"), param.get("age"),param.get("threadid"));

    }
}
  • 简单应用示例代码 Simply apply the sample code
public class Main {
    private static Logger log = LoggerFactory.getLogger(Main.class);
    private static AnnularQueue annularQueue=AnnularQueue.getInstance();
    private static Object obj=new Object();
    public static void main(String[] args){
        allcustomSimpleSetTest();
    }
    static void allcustomSimpleSetTest(){
        try {
            annularQueue.start();
            CusTask1 task1 = new CusTask1();
            task1.setEndTimestamp(ZonedDateTime.now().plusSeconds(10).toInstant().toEpochMilli());
            Map<String,String> param=new HashMap<String,String>(){
                {
                    put("name","刘彻");
                    put("birthday","1988-1-1");
                    put("age","25");
                    put("threadid",String.valueOf(Thread.currentThread().getId()));
                }
            };
            task1.setParam(param);
            CusTask1 task2 = new CusTask1();
            task2.setPeriod(30);
            task2.setImmediateExecute(true);
            task2.setTaskType(TaskType.PERIOD);
            task2.setUnit(TimeUnit.SECONDS);
            Map<String,String> param2=new HashMap<String,String>(){
                {
                    put("name","Jack");
                    put("birthday","1986-1-1");
                    put("age","32");
                    put("threadid",String.valueOf(Thread.currentThread().getId()));
                }
            };
            task2.setParam(param2);
            annularQueue.submit(task1);
            annularQueue.submit(task2);
            obj.wait();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

Notice

  • 此构件已在Windows和centos下做了适当测试,目前未在生产环境中使用过
  • 为了更好的保证系统故障自动恢复任务,请自定义程序任务持久化文件保存的路径(不同应用文件路径定义不同为好,以免被其他应用覆盖),并确保读写权限。如果以 jar包运行,文件默认在同级目录;如果以war包在tomcat下运行,文件默认在tomcat的bin目录下。
  • 如果您在使用过程中遇到问题,可以在这里提交

原文地址:https://www.cnblogs.com/liuche/p/10981291.html

时间: 2024-10-07 13:32:08

支持宕机自动恢复触发一次性或周期性任务执行的组件包-easyTask的相关文章

Mysql主从架构-主库宕机如何恢复业务

在我们日常工作场景,首先要做到架构无单点隐患,其次在优化[安全.性能.高可用.高并发等],Mysql这款关系型数据库稳定.高效,所以使用广泛,如果企业架构是1主多从,那如果Mysql主库宕机,如何解决? ----MySQL 主从同步原理图 一.Mysql主库宕机情况分类: 1)硬件问题,(服务器.ecs.虚拟主机等等)宕机 2)service问题,Mysql宕机,服务异常,端口异常等 二.硬件问题处理思路 硬件问题我们可以查看IDC巡检记录,或通过远程控制卡查看硬件运行状态,根据事实情况就行硬件

Redis(六)——高可用之哨兵sentinel配置与启动及主从服务宕机与恢复

.主从复制高可用 #主从复制存在的问题: 1 主从复制,主节点发生故障,需要做故障转移,可以手动转移:让其中一个slave变成master 2 主从复制,只能主写数据,所以写能力和存储能力有限 哨兵是对Redis的系统的运行情况的监控,它是一个独立进程,它会独立运行,功能有二个: 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器. 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机.

Windows RabbitMQ 镜像队列 (高可用性、一台宕机自动切换另一台) 使用 RabbitMQ 自带的Web 管理工具

镜像队列是基于普通的集群模式的,所以得先配置普通集群(参照前一篇Windows RabbitMQ 集群搭建),然后才能设置镜像队列. 在集群服务器上新建一个 队列 : 镜像队列是通过RabbitMQ 的配置策略(policy)来实现的: 镜像队列提供了三种模式: ?  all:全部的节点队列都做镜像: ?  exactly:指定镜像队列的节点最高镜像数量: ?  nodes:只为指定具体节点配置镜像队列: 创建镜像队列如下图: 点击 "Add policy " 即  完成 创建 . h

一次修改数据库物理文件造成Mysql宕机的恢复记录

事件起始 某夜,我正在床上冥想准备入睡,忽然同事向我求救:消息内容如下: Oh My Gold 改了些配置,啥都没了!都没了!没了!了! 我仔细询问,原来是她因为某些原因将某库的物理文件夹改名后,发现数据库找不到了.于是又将名称改回来.结果仍然找不到.这让她觉得数据可能被损坏了,于是赶忙来找我修复. 修复过程 我们数据库用的版本是 MySQL5.7 ,放置在Linux服务器上,在my.cnf 配置了数据库物理文件的存放地址.存放于 data 文件夹下. 表的存储引擎全部使用 InnoDB,dat

mysql主从复制配置操作以及主从宕机切换演练

主从复制目的: 主从服务器设置的稳健性得以提升,如果主服务器发生故障,可以把本来作为备份的从服务器提升为新的主服务器.在主从服务器上分开处理用户的请求,读的话,可以直接读取备机数据,可获得更短的响应时间. 主服务器:IP地址192.168.80.129,mysql已经安装,无用户数据. 从服务器:IP地址192.168.80.130,mysql已经安装. 注:数据库版本必须一致. 1.主从复制配置 修改从服务器的配置文件/etc/my.cnf,在mysqld里添加一下属性 [mysqld] lo

Mysql DBA 高级运维学习笔记-一主多从宕机从库切换主继续和从库同步过程

1.主库master 宕机 登录从库show processlist\G 看两个线程的更新状态 mysql> show processlist\G *************************** 1. row *************************** Id: 1 User: system user Host: db: NULL Command: Connect Time: 22997 State: Waiting for master to send event Info:

clickhouse高可用及节点宕机数据一致性方案

1. 集群节点及服务分配 说明: 1.1. 在每个节点上启动两个clickhouse服务(后面会详细介绍如何操作这一步),一个数据分片,一个数据备份,为了确保宕机数据一致性,数据分片和数据备份不能同一节点,比如gawh201上的shard不能备份在gawh201的replica,如果这样做,当gawh201宕机了,该节点shard的数据是找不到的. 1.2. 基于a所以shard和replica必须错开,但不是随意错开就可以了.按照上图给的规律错开(后面会详细介绍超大节点的集群的shard和re

从谷歌宕机事件认识互联网工作原理

原文转自:http://kb.cnblogs.com/page/166210/ 英文原文:Why Google Went Offline Today and a Bit about How the Internet Works 译者注:本文中提到 CloudFlare 是一家总部位于美国旧金山的内容分发网络(CDN)服务公司,由 Project Honey Pot 项目的三位前开发人员成立于 2009 年.2011 年 10 月被华尔街日报评为最具创新精神的网络科技公司. 今天,谷歌的服务经历了

项目笔记-数据库进程宕机

简述情景: 1. 最开始出现邮件报警,db进程内存超过5G. 2. 1小时后,db宕机 3. 检查日志,发现mysql语句执行很慢.从18:30开始出现日志警告. 写了个程序测数据库执行速度.连本机数据库执行1000条语句,时间500ms左右.连其他机器数据库执行1000条语句,时间8s左右.服务器的数据库执行线程500ms执行一次,也就是说一旦一次的执行时间超过500ms,而且sql语句持续增加,服务器的执行就开始阻塞,导致内存开始累计.最终服务器由于内存过高,发生宕机. 临时解决方案: 由跨