在上一篇文章中，提到了目前系统遇到的性能瓶颈，即对于一个数据量大或者复杂的前端条件查询十分耗时。此次整改除了在上篇中提到的优化查询es的方法外，还增添了业务缓存的使用----在es里面增加缓存库的概念，对于每个查询的话题单独建立一个索引，只有在客户发生话题设置变动时才会对相应的数据进行刷新，我们选用的仍是es作为存储搜索介质。此外，还增加了es小集群的使用，里面仅仅存放近三天的数据，专门提供最近几天数据的查询，这样可以大大提高查询速率。以下是整体流程设计的粗略图。
显而易见，缓存库的增加，伴随着许多问题的出现，比如：小集群中近三天的数据，随着时间推移数据会逐渐增多；与业务相关的话题会频繁改动，如若改动，缓存数据怎么办，前端如果显示；对于历史数据，如果刚刚被抓取进系统，如果能够及时的分配到相应的话题缓存库中；等等。
对于这些问题，就需要一套精细的任务调度设计方案，来保证整体流程的准确无误。
首先，针对业务缓存机制提供的操作有：是否启用缓存机制（缓存开关）、最大可见时长可配置化、实时可见时长可配置化（就是近m天中的m），再有就是一些与业务紧密相关的事件监听、调度任务等。
其次，对于缓存数据更新的任务种类的划分，主要有三类：
- 定时导入新数据至相应缓存；
- 定时导入新进历史数据至相应缓存；
- 由于一些事件触发的回溯数据、更新缓存任务；
大体思路就是这样，再有就是需要注意细节，比如缓存时间的无缝对接，实时查询与缓存查询的时间分隔点的确认，如果出现异常如何补录数据，如何保证所有流程运作是否正常，等等，这些都是需要紧密结合实际业务进行严格的逻辑方案设计。以下是我在本次整改中给出的方案设计草稿，由于与实际案例结合紧密且无解说，可跳过不看。
---------------------------------------------------------------------------------------------------------------------------------
（流程梳理草稿）
1、回溯事件机制
2、定时任务
2.1 定时刷新实时数据
2.2 定时刷新新进历史数据
2.3 定时扫描回溯任务
2.4 定时恢复回溯任务（僵死 and 失败）
3、回溯任务
4、监测任务
4.1 僵死任务监测
超过40分钟无响应
4.2 超时任务监测
话题回溯总时长超过1小时
5、统计任务
5.1 每日汇总指标
5.1.1 执行失败却未被恢复
5.1.2 执行失败任务明细
5.1.3 正在执行任务明细
5.1.4 排队等待任务明细
5.1.5 每日操作总数、操作话题数、操作话题明细
6、线上任务执行明细
| 任务类型 | 任务名称 | 功能描述 | 触发类型 | 执行间隔 | 备注 |
|---|---|---|---|---|---|
| 功能任务 | PUB导入新数据至缓存 | 定时更新 所有有效客户|指定客户|指定话题 缓存，使得缓存时间向前推移 | 定时执行 |
24小时 （每日零点） |
|
| CP导入新数据至缓存 | 定时补录 所有有效客户|指定客户|指定话题 缓存数据，使得一些新进入的历史数据能够及时进入缓存 | 定时执行 | 2小时 | ||
| 定时扫描回溯任务 | 定时拾取由事件触发的回溯任务，并提交具体任务给执行器 |
定时执行 | 10秒 | ||
| 回溯任务 | 执行分配到的回溯任务 | 由 定时扫描回溯任务 一次性触发 | |||
| 定时清理僵死任务 | 对1小时前的失败回溯任务以及僵死回溯任务进行重试，最大重试次数为3 | 定时执行 | 10秒 | ||
| 监测任务 | 线上话题缓存 - 异常巡检 | 定时检测 有效客户，所有话题，cache_end 时间，小于 now - 108h 时认为话题缓存更新延迟，预警 |
定时执行 | 4小时 | |
| 线上WEB服务 - JVM内存监测 |
监测所有 WEB 服务 JVM 可用内存剩余，小于 512M 时，认为有风险 service_api \ data_api \ report_job \ warning_job \ regular_job 等 |
定时执行 | 2小时 | ||
| CP更新及时性监测 | 监测近6小时内未进行及时补录历史数据的话题，主要用于监测 CP导入新数据至缓存 任务 | 定时执行 | 4小时 | ||
| PUB更新及时性监测 | 监测近24小时内未进行及时更新缓存的话题，主要用于监测 PUB导入新数据至缓存 任务 | 定时执行 | 4小时 | ||
| 每日任务监测 |
汇总前一天回溯任务涉及总话题数、总任务数、成功任务数、失败且未被恢复任务数、【失败列表】、【恢复列表】、【运行列表】、【等待列表】 主要用于监测 定时扫描回溯任务、回溯任务 |
定时执行 |
24小时 （每日零点） |
||
| 大小集群数量对比监测 | 监测近一个小时内大小集群的数据量差异 | 定时执行 | 1小时 | ||
| 缓存集群数据监测 | 监测 所有有效客户|指定客户|指定话题 缓存数据， 与 大集群数据对比，如缺少数据，则进行补录 | 手动触发 | |||
| 僵死任务监测 | 监测近40分钟内无任何进展的僵死任务调度，主要用于监测 定时清理僵死任务 | 定时执行 | 1小时 | ||
| 超时任务监测 | 监测回溯任务执行总时长超过1小时的任务调度，主要用于监测 定时清理僵死任务 | 定时执行 | 1小时 |
（数据库设计时的初步草稿）
任务分类：
1、 定时更新
1） 实时新数据 --> 最新createTime
2） 回溯、修改数据 --> 更改createTime
可配：时间间隔
source： ES total 库
参考字段： createTime
任务管理： 按 docId 创建任务
| 按 subject 创建任务
2、实时更新 （时效要求较高） 前端 & 后台
- 删除ES doc --> 删除cache doc （可以不删）
- 更改ES doc
- 删除ES doc --> 删除cache doc （可以不删）
- 增加ES doc --> 增加数据，重新走storm流处理，进入ES --> 定时更新任务 处理
- 增加ES doc --> 增加数据，重新走storm流处理，进入ES --> 定时更新任务 处理
- 屏蔽 --> 删除cache doc （必须删）
建立 docId 与 cache key 之间的对应关系
3、话题增删改、配置修改、缓存开启等引起的缓存构建，以话题为单位进行创建任务
- 话题删除
- 话题修改
- 删除
- 创建
- 话题创建
任务管理： 按 subject 创建任务
表设计
db_task_batch
字段 |
类型 |
长度 |
约束 |
含义 |
枚举 |
|---|---|---|---|---|---|
| id | |||||
| type | 任务类型 |
0：定时任务 1：重新构建 |
|||
| subject_ids | |||||
| con_start_time | |||||
| con_end_time | |||||
| exe_start | 开始执行时间 |
|
|||
| exe_end | 结束执行时间 |
||||
| status | 线程状态 |
-2：杀死 -1：失败 0： 进行中 1： 成功 |
|||
| subject_total | 涉及的话题总数 |
|
|||
| subject_failed | 失败的话题总数 |
||||
| stage | 所处阶段 |
-1：未执行 0：开始执行 1：开始创建子任务 2：子任务创建完毕 |
|||
| switch |
任务开关 （每次更新阶段、状态时判断是否被关闭， 如果被关闭且处于合理状态，可以杀死该线程） |
0：关闭 1：开启 |
|||
| create_time | 任务创建时间 | ||||
| update_time | 任务更新时间 |
db_task_subject
字段 |
类型 |
长度 |
约束 |
含义 |
枚举 |
|---|---|---|---|---|---|
| id | |||||
| batch_task_id | 父任务id |
|
|||
| subject_id | subject_id |
|
|||
| company_id | |||||
| condition_id | 条件组合id | ||||
| con_start_time | 查询条件 起始时间 |
||||
| con_end_time | 查询条件 结束时间 | ||||
| status | 线程状态 |
-2：杀死 -1：失败 0： 进行中 1： 成功 |
|||
| time_stage | 由后至前，所处中间时间阶段 |
|
|||
| operation |
|
0：删除 1：增加 2：修改 |
|||
| stage | undo(-1, "未执行"), start(0, "开始执行"), delete(1, "开始删除缓存"), create(2, "开始创建缓存"), query_data(3, "开始查询数据"), import_data(4, "开始导入数据"); |
||||
| switch |
任务开关 （每次更新阶段、状态时判断是否被关闭， 如果被关闭且处于合理状态，可以杀死该线程） |
0：关闭 1：开启 |
|||
| message | 相关信息 | ||||
| subject_name | 话题名称 | ||||
| retry_num | 重试次数 | ||||
| recover_task | 所恢复的任务id | ||||
| create_time | 任务创建时间 | ||||
| update_time | 任务更新时间 |
db_task_doc
字段 |
类型 |
长度 |
约束 |
含义 |
枚举 |
|---|---|---|---|---|---|
| id | |||||
| doc_id | |||||
| operation | 执行操作 |
0：删除 1：增加 |
|||
| exe_start | 开始执行时间 |
|
|||
| exe_end | 结束执行时间 |
||||
| status | 状态 |
-2：杀死 -1：失败 0： 进行中 1： 成功 |
|||
| stage | 所处阶段 |
对于doc: -1：未执行 0：开始执行 1：查询倒排索引表 2：删除倒排表、删除缓存doc 3：计算 4：更新倒排表 5：增加数据 |
|||
| switch |
任务开关 （每次更新阶段、状态时判断是否被关闭， 如果被关闭且处于合理状态，可以杀死该线程） |
0：关闭 1：开启 |
|||
| message | |||||
| create_time | 任务创建时间 | ||||
| update_time | 任务更新时间 |
db_task_event
字段 |
类型 |
长度 |
约束 |
含义 |
枚举 |
|---|---|---|---|---|---|
| id | |||||
| type | 时间类型 |
0：doc变更 1：话题变更 2：开启/关闭缓存 3：修改最大显示时长 4：白名单变更 |
|||
| sign_id | 例如：subjectId、companyId、docId | ||||
| ori_info | 原始信息 |
|
|||
| now_info | 现有信息 |
|
|||
| handle | 是否被处理 |
0：不做处理 1：需要处理 |
|||
| task_id | 任务id | ||||
| token | 操作人 | ||||
| create_time | 任务创建时间 | ||||
| update_time | 任务更新时间 |
db_company：
cache_status 开启1/关闭0
real_time_days 实时查询区间 (天为单位)
// default_cache_time 缓存时长
max_data_view_days 最大显示时长(天为单位)
db_subject:
cache_start 本话题rebuild刷新数据的pubtime起始时间（用rebuild任务更新）
cache_end 本话题定时刷新数据的pubtime终止时间（用定时任务更新）
create_time_last 本话题定时刷新数据的createTime终止时间（用定时任务更新）
// cache_should_start
// cache_should_end
cache_refresh_time 本话题刷新完成时间（当前系统时间）
cache_recalculate_time
cache_refresh_status 0：稳定 1：refresh中
cache_recalculate_status 0：稳定 1：rebuild中
if_update 0：不更新 1：更新
update_num_left 剩余更新次数
keywords
db_subject_cluster
字段 |
类型 |
长度 |
约束 |
含义 |
枚举 |
|---|---|---|---|---|---|
| id | |||||
| subject_id | |||||
| cluster_id |
db_cluster
字段 |
类型 |
长度 |
约束 |
含义 |
枚举 |
|---|---|---|---|---|---|
| id | |||||
| ip | |||||
| tcp_port | |||||
| http_port | |||||
| cluster_name | |||||
| shard_num | |||||
| type |
0：小集群 1：大集群 |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------