假热点数据问题-之缓存优化

1.假热点数据
先介绍一下假热点数据概念，这个概念是本人自己提出的，那么什么是假热点数据呢？
所谓假热点数据，就是业务流程必须的，至少一次访问，之后很少或者不会再访问的数据。 一个很常见的情况就是和用户行为有直接关系的业务逻辑数据， 我们不能预测用户的行为，对于特定的业务逻辑，某些用户频繁访问，某些用户一次访问。这就很容易造成出现假热点数据。
举个例子：用户查询某个列表信息，一般情况下，都是先去访问缓存，未命中，再去访问数据库并将数据缓存起来并设置失效时间。但是这样会产生两种情况，极端情况下，缓存数据大量占据内存空间，或者缓存数据命中率极低，都容易出现性能问题。
将这个业务场景具象化，我们可以看一个面试官问题：
面试官招聘一个人，第一步是先从海量的简历中筛选出一份简历；然后呢，在进行笔试面试，都通过之后呢，最后确定录用。筛选简历的过程，可以对应到从数据库读取数据并写入缓存的过程。但是筛选出的这个人并不一定符合面试官的标准，我们将那些不符合标准的数据，可以称之为假热点数据。所以说，后面的笔试面试过程，就是将热点数据和假热点数据区分开来。
2.缓存模型优化
为了解决假热点数据问题，从概念模型上，我们可以将缓存优化如图：
模型一：内存分块

最左边是一个维护着缓存中所有的key列表，右边是将缓存的内存划分成若干块。这样，针对不同的内存块，我们可以根据自身业务需求采取不同的策略。比如，临时区的缓存设置5s的失效时长，临时热点区30s，热点区60s等等。又或者，如果出现内存不足时直接将临时区清空以达到扩容目的。这样，当一个新的数据插入到缓存中的时候，先将数据放到临时区，并在key的列表中记录，当再次访问此数据时，将临时区数据移到临时热点区；多次访问后将数据移到热点区。
模型二：LRU列表
LRU列表就很简单了，在缓存中维护一个LRU列表实例，LRU列表的头部5/8叫做热点区，尾部3/8叫做临时区。（参考InnoDB数据页LRU列表的实现）策略和上述分块思想基本一致。
通过上述设计，即可解决假热点数据带来的空间消耗或者性能消耗。
后续的博文会公布对应上述缓存模型的实现。敬请关注！！！