一、设计方案背景：
- 随着业务的不断丰富，为了提高系统的性能，大量的采用异步处理的形式，使得产生了较多的待处理数据。准确而又及时的监控这些庞大复杂业务场景产生的业务数据便成了重要的任务。
- 针对每个业务场景或者异步待处理表，都需要使用JOB定时去监控并及时告警通知到相关人员处理，而这种任务需要有开发工作量并且不同表之间只有少量的区别。重复而又必要的监控需求，导致系统代码量和代码重复度上升、大量JOB又增加了调度平台任务的维护成本。
二、解决的问题：
- 减少监控开发工作量，实现快速告警配置。
- 告警配置支持告警执行频率（cron表达式）、告警阈值（异常、积压）、告警频率（防止频繁告警）、模板动态配置、人员配置等灵活的告警策略配置。
- 告警可配置不同的执行bean，支持多种业务告警，同时可定制bean方法，增加告警灵活性
使用技术：spring、redis、mysql
告警配置表模型：（部分字段）
告警名称 | 备注该条告警信息等 |
分组 | |
执行bean | |
bean参数 | |
执行频率 | cron表达式 |
告警阈值 | |
告警频率 | |
告警模板 | xxx短信模板。。 |
告警级别 | 高、中、底 |
告警类型 | 手机、邮件、微信公众号、公司聊天软件等 |
告警值 | 手机号等 |
三、基础工作流：
四、Redis队列：
五、组件工作图：
名词解释
调度平台：承担定时任务集中进行管理和调度,集中解决了集群环境下任务并发执行的控制，对任务调度执行情况的监控和异常短信告警、重试机制；同时也提供跨业务系统的后继任务调度。
队列管理器：提供告警任务队列的加载，并发控制。其中队列加载包含任务分组规则、任务状态的管理。
调度规则管理器：告警任务触发的规则管理，包含执行频率、告警频率等规则。
行为动作：定义执行前后业务操作和逻辑，例如ftp的连接创建释放、数据清理、初始化等操作
执行管理器：根据beanname获取Spring容器，并从Spring容器中确定代理对象，获取代理对象的执行器。
执行器：根据告警任务配置的阈值、业务规则等，返回需要告警的任务、和拼装告警所需的信息。
消息管理器：告警信息的内容拼接、告警事件聚合、分派规则管理（个人、群组、公众号等）。
六、核心工作流程图及步骤：
1、调度开始，从任务队列获取要执行的任务组，如果任务队列为空（队列长度=0），代表是首次全量加载任务或者新一轮调度任务。
首次加载场景：
2、 先加共享锁（setnx），保证同一时间只有一个调度任务全量加载到REDIS队列中，防止并发导致REDIS队列中有重复数据。
3、加锁失败，代表有其他调度正在加载（并发），结束流程，等待下次调度。
4、加锁成功，全量加载任务到REDIS队列中，全量的任务可以存储在ehcache（ehcache全量任务数据可以从DB加载，同时配置失效时间），避免透库增加DB压力。
5、全量加载的规则：根据任务组号分组，封装任务List，push到REDIS队列中，这么做的原因是避免多次重复查询DB。
例如一种业务数据，根据监控维度可能有多种阈值、告警类型、执行频率等，但是都是查询一种数据，这种场景避免多次透库查询，可以分组，只查询一次。
6、加载成功后，需要释放共享锁，并从REDIS队列POP一组告警任务，继续处理。
非首次加载场景：
7、从REDIS队列获取告警任务组（List），根据分组号加共享锁（setnx），防止并发。
8、根据beanName获取Spring容器，并从Spring容器中确定代理对象，获取代理对象的执行器，并把执行参数等代入执行器执行。
9、执行器根据积压阀值、执行频率、告警频率等规则判断是否达到告警门槛，把满足告警门槛的告警任务返回给消息管理器。
10、消息管理器结合任务优先级、告警事件聚合、分派规则等，发送邮件、短信、微信等消息。
