性能提升之增加业务缓存

在上一篇文章中，提到了目前系统遇到的性能瓶颈，即对于一个数据量大或者复杂的前端条件查询十分耗时。此次整改除了在上篇中提到的优化查询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：删除倒排表、删除缓存doc3：计算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/关闭0real_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_endcache_refresh_time              本话题刷新完成时间（当前系统时间）cache_recalculate_timecache_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：大集群

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------