1、背景介绍
all we know，所有的网站都有这种分页列表，他们展示一些简单的数据，用来让用户初步的筛选出他想要的东西，然后再点击查看详细信息。
可能有人会想，为什么基础信息和详细信息需要分开呢？两个原因
- 列表页只展示简单的信息，一次性可以查看更多的条数
- 只展示简单的信息，前后端交互时响应时间可以大大缩短
2、来自产品经理的需求
需求来了，随之的问题就来了，产品经理总会为了用户的体验而要求在列表页加一些醒目的信息突出，而往往有些东西是需要计算得出的（如商品的折扣信息）。
解决方法如下：
列表页迭代进行计算
按每页10行数据来说，一次计算按20ms来算，一页需要多花费200ms的时间来计算，加上rpc调用的话，一个页面上需要多花费500ms左右的时间。可见这个方法不可取。数据库加上表或字段用于读取
现在的列表页一般都是用搜索引擎来优化搜索和加快响应时间，数据库层面的改动牵一发而动全身，这是一个浩大的工程。这是一个最终需要使用的方案，但很难一下子完成。列表页使用缓存
在从搜索引擎获取到数据后，再迭代从缓存中获取。这是简单且能够快速实现的方案了，但是又要考虑缓存失效时候的效率，毕竟计算出来的东西需要更新。
3、不能接受缓存失效时的效率，考虑异步更新缓存
异步缓存是什么，即缓存的更新另开线程去做，在缓存更新之前，还是返回旧的缓存数据。
缓存格式
缓存应该是一个永久的带有过期时间的类创建缓存更新线程池
根据服务器的性能创建一定大小的线程池，用于更新缓存什么时候更新缓存
当获取到的缓存，转换为类后，得到过期时间在当前时间之前，则进行缓存更新（过期时间也相应更新）。如何更新缓存
单机时，通过线程池执行更新缓存操作。
分布式时，使用mq进行更新缓存操作的推送，消费者通过线程池执行缓存更新操作（当然，也可以专门有个服务用来更新缓存）。
不管是单机还是分布式都应该考虑缓存更新操作时候的幂等性。
4、缓存预热数据量太大，考虑异步更新缓存
以之前说到的计算数据为例，因为刚上线，缓存中肯定没有相应的数据，这时候如果大量请求过来，服务器宕机的可能性很大（没有做限流的前提下）。
- 缓存预热
能想一下，大量的数据去进行预热是多么麻烦的一件事，尤其是程序员还是如此懒惰的生物，这种耗时耗力的事情反正我是不愿意去做的emmm - 异步更新缓存
结合上一点说到的，不仅当缓存类里面的过期时间到了返回旧值并异步更新缓存，我们也可以当缓存中未取到值时，返回空值并异步更新缓存。
