查询API优化

1.当前待优化背景

    [1] 重复高频的数据查询请求(并且由于是核心API，可能会有多个其他系统同时进行调用并且由于是核心API，可能会有多个其他系统同时进行调用)
    [2] 数据具有周期性(数据有自己的生命周期，周期结束后很少会再次访问)

2.当前需要的主要关注点

    [1] 故障快速恢复
        需要有数据持久化相关功能保证宕机数据及时恢复
        硬件配置：可以配置多组多实例多机柜，保证服务。
    [2] 查询性能
        可通过减少数据索引条件，或者预先把索引条件组成一个固定key用来存储查询（查询订单的某个商品，可存"orderId"或"orderId-productId" 为key，减少索引复杂度）
    [3] 稳定性
        输出稳定，缓存性能稳定，查询集群的线程池运行越稳定，整个系统稳定性会提高

3.业务剥离，缓存构建

    [1] 类似的数据肯定会存在多方读写的问题，那么就会造成数据不一致的情况，为了避免这种情况和循环依赖的产生可以提供统一的API将查询统一进行管理
    [2] 一级缓存
        根据系统的重复数据查询统计构建秒级过期时间缓存，提高服务响应速度、降低数据库访问频次，以此来减少数据库查询压力或流量冲击。
    [3] 二级缓存
        梳理业务对热点表数据进行缓存，并提供查询服务接口。
        优点：
            可提高护唇数据的使用效率，同时对底层数据库的垂直拆分和水平拆分，做到数据使用的业务放无感知，提高系统的扩展性。
            此缓存可监控数据库的binlog记录，有数据更新时重新加载目标数据。

4.实施方案

    [1] 缓存数据一致性
        主动式：提前将可能访问的数据加载到缓存中，然后设置过期时间，周期性刷新，适用于数据量不大并且变换不频繁的场景。
        被动式：有请求时查询结果缓存，并设定一定的过期时间，可提高缓存使用效率。
        一致性问题：可通过消息监控主动reload目标数据或者订阅数据库binlog日志监控。
    [2] 缓存穿透
        缓存秒级空结果集，降低流量攻击的同时也不会对正常业务造成影响
    [3] 缓存击穿
        缓存失效的同时又大量请求同时访问目标数据，可通过分布式锁进行处理。
    [4] 缓存雪崩
        对缓存数据过期时间增加随机数
    [5] 消息等待队列处理
        如果消息过多可单独提供一个服务对消息进行处理，并使用线程池异步执行。

5.优化

    [1] 对线上请求频率进行分析对缓存进行分时段过期时间配置策略，峰顶加长缓存时间，地缝降低缓存时间，可通过zk的文件事件监控随时进行配置调整，达到削峰填谷的作用。
    [2] 数据状态分类缓存策略
        有些数据在生命周期结束后访问频率很低，所以就没必要在进行缓存，或者仅缓存很短时间即可，二在生命周期中的则可加长缓存时间。
    [3] 数据预加载
        在数据生命周期开始或即将开始时肯定会造成高频访问，可提前对预期进行数据预热降低缓存构建压力。