性能提升之增加业务缓存

在上一篇文章中，提到了目前系统遇到的性能瓶颈，即对于一个数据量大或者复杂的前端条件查询十分耗时。此次整改除了在上篇中提到的优化查询es的方法外，还增添了业务缓存的使用----在es里面增加缓存库的概念，对于每个查询的话题单独建立一个索引，只有在客户发生话题设置变动时才会对相应的数据进行刷新，我们选用的仍是es作为存储搜索介质。此外，还增加了es小集群的使用，里面仅仅存放近三天的数据，专门提供最近几天数据的查询，这样可以大大提高查询速率。以下是整体流程设计的粗略图。

显而易见，缓存库的增加，伴随着许多问题的出现，比如：小集群中近三天的数据，随着时间推移数据会逐渐增多；与业务相关的话题会频繁改动，如若改动，缓存数据怎么办，前端如果显示；对于历史数据，如果刚刚被抓取进系统，如果能够及时的分配到相应的话题缓存库中；等等。

对于这些问题，就需要一套精细的任务调度设计方案，来保证整体流程的准确无误。

首先，针对业务缓存机制提供的操作有：是否启用缓存机制（缓存开关）、最大可见时长可配置化、实时可见时长可配置化（就是近m天中的m），再有就是一些与业务紧密相关的事件监听、调度任务等。

其次，对于缓存数据更新的任务种类的划分，主要有三类：

1. 定时导入新数据至相应缓存；
2. 定时导入新进历史数据至相应缓存；
3. 由于一些事件触发的回溯数据、更新缓存任务；

大体思路就是这样，再有就是需要注意细节，比如缓存时间的无缝对接，实时查询与缓存查询的时间分隔点的确认，如果出现异常如何补录数据，如何保证所有流程运作是否正常，等等，这些都是需要紧密结合实际业务进行严格的逻辑方案设计。以下是我在本次整改中给出的方案设计草稿，由于与实际案例结合紧密且无解说，可跳过不看。

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

（流程梳理草稿）

 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小时