18、基于冷热数据分离方案优化后的LRU链表，是如何解决之前的问题的？
1、对于预读以及全表扫描加载进来的一大堆缓存页
现在我们已经看完了LRU链表的冷热数据分离的方案，那么我们接着看这个冷热数据分离之后的LRU链表，他是如何解决之前遇到的一大推问题的？
首先我们思考一下，在这样的一个LRU链表方案下，预读机制以及全表扫描加载进来的一大堆缓存页，他们会放在那里？
根据咱们上一章学习的内容，应该是放在LRU链表的冷数据区域的前面的
假设这个时候热数据区域已经有很多被频繁访问的缓存页了，你会发现热数据区域还是存放被频繁访问的缓存页的，只要热数据区域有缓存页被访问，他还是会被移动到热数据区域的链表头部去。
所以此时你看下图，你会发现，预读机制和全表扫描加载进来的一大堆缓存页，此时都在冷数据区域里，跟热数据区域里的频繁访问的缓存页，是没关系的。
2、预读机制和全表扫描加载进来的缓存页，能进热数据区域吗？
接着我们看第二个问题，预读机制和全表扫描机制加载进来的缓存页，扫描时候能进热数据区域呢？
如果你仅仅是一个全表扫描的查询，此时你肯定是在1s内就把一大堆缓存页加载进来，然后就访问了这些缓存页一下，通常这些操作1s内就结束了。
所以基于目前的一个机制，可以确定的是，这种情况下，那些缓存页是不会从冷数据区域转移到热数据区域的
除非你在冷数据区域里的缓存页，在1s之后还被人访问了，那么此时他们就会判定为未来可能会被频繁访问的换成你也，然后移动到热数据区域的链表头部去
3、如果此时缓存页不够了，需要淘汰一些缓存，会怎么样？
接着我们看，假设此时缓存页不够了，需要淘汰一些缓存页，此时会怎么做？
那就很简单了，直接就是可以找LRU链表中的冷数据区域的尾部的缓存页，他们肯定是之前被加载进来的，而且加载进来1s过后都没人访问过，他就是冷数据。
所以此时就直接淘汰冷数据区域的尾部的缓存页，就可以了，我们看下图：
4、之前的一大堆问题解决了吗？
在这样的一套缓存页分冷热数据的加载方案，以及冷数据转化热数据的时间限制方案，还有就是淘汰缓存页的时候有限淘汰冷数据区域的方案，基于这套方案，大家会发现，之前发现的问题，完美的被解决了。
因为那种预读机制以及全表扫描机制加载进来的数据页，大部分都会在1s之内访问一下，之后可能就再也不访问了，所以这种缓存页基本上都会留在冷数据区域里。然后频繁访问的缓存页还是会留在热数据区域里。
当你要淘汰缓存的时候，优先就是会选择冷数据区域的尾部的缓存页，这就是非常合理的了。他不会让刚加载进来的缓存页占据LRU链表的头部，频繁访问的缓存页在LRU链表的尾部，淘汰的时候淘汰尾部的频繁访问的缓存页了。
问题完美的被解决了。 这就是LRU链表冷热数据分离的一套机制
5、总结
通过这几篇文章的学习，我们已经彻底搞定了LRU链表的设计机制，刚加载数据的缓存页都是放冷数据区域的头部的，1s过后被访问了才会放热数据区域的头部，热数据区域的缓存页被访问了，就会自动放到头部去。
这样的话，实际上冷数据区域放的都是加载进来的缓存页，最多在1s内被访问过，之后就再也没访问过的冷数据缓存页
而加载进来之后在1s过后还经常被访问的缓存页，都放在了热数据区域里，他们进行了冷热数据的隔离
这样的话，在淘汰缓存的时候，一定是优先淘汰冷数据区域几乎不怎么被访问的缓存页的，也希望大家好好吸收这种冷热数据隔离的思想，尽可能让热数据和冷数据分开，避免冷数据影响热数据的访问
6、一个发散思考的问题
大家觉得对于这种缓存中同时包含冷热数据的场景，如果你是在Redis中方亮你业务系统的很多缓存数据，其中也是冷热数据都有的，此时可能会有什么问题？
那么针对这样的一个问题，你是否可以考虑在你自己的缓存设计中，运用冷热隔离的思想来优化重构呢？
