php的cacheput技巧_缓存系统设计精要

从高层往低层走，存储设备变得更慢、更便宜、容量更大。
最高层(L0)是少量快速的CPU寄存器，CPU可以在一个时钟周期内访问它们 (一个时钟周期常日小于1ns)；接下来是一个或多个中小型SRAM高速缓存存储器，可以在几个CPU时钟周期内访问它们；然后是一个大的基于DRAM的主存，可以在几十到几百个CPU时钟周期内访问它们；接下来是慢速但是容量很大确当地磁盘(常日是SSD)；末了有些系统乃至包括了一层附加的网络文件系统(Network File System,NFS)，比如说腾讯云供应的CFS做事就可以通过挂载到多个做事器实现分布式的数据共享。

下面我们从 CPU 的角度以详细的数据来量化比拟CPU、磁盘、网络的速率，对打算机各个组件不同的速率差异有个更直不雅观的认识。

类型

缓存内容

缓存位置

读取数据须要时长

比拟基本单位时长

CPU寄存器

4字节 & 8字节

芯片上的CPU寄存器

0.38ns

1s

L1高速缓存

64字节块

芯片上的L1高速缓存

0.5ns

1.3s

L2高速缓存

64字节块

芯片上的L2高速缓存

7ns

18.2s

L3高速缓存

64字节块

芯片上的L3高速缓存

35ns

91s

内存

4KB页

主存

100ns

4分钟

固态硬盘SSD

磁盘扇区

磁盘掌握器

150us

4.5天

网络磁盘(NFS本地挂载)

部分文件

本地磁盘

1.5ms

一个半月

CPU 和内存之间的瓶颈被称为冯诺依曼瓶颈, 它们之间至少有着几百倍的速差，可以想象整天上人间，天上一天，地下一年。
普通的磁盘读取数据就更慢了，寻址韶光10ms，比拟CPU的基本单位时长是10个月，可以生一次孩子了！
以是说IO 设备是打算机系统的瓶颈。
以此想到我们网络中的API要求，动不动便是一百多毫秒，比拟CPU的基本单位便是十几年！

相信通过以上描述，读者对打算机组件之间数据处理速率有了深入的印象。

一个编写良好的打算机程序常日具有良好的局部性(locality)。
也便是，它们方向于引用临近于其他最近引用过的数据项的数据项，或者最近引用过的数据项本身。
这种方向性，被称为局部性事理(principle of locality)，是一个持久的观点，对硬件和软件系统的设计和性能都有着极大的影响。

局部性常日有两种不同的形式: 韶光局部性(temporal locality) 和 空间局部性(spatial locality)。

Mysql数据库Innodb引擎的设计就很好的考虑了局部性事理。

Innodb引擎以页的形式组织数据，页的默认大小是16KB,存放用户数据记录的页叫“数据页”，为了实现数据更快的查找，InnoDB利用B+树的构造组织存放数据，最下层的叶子节点存放“数据页”，在“数据页”的上层抽出相应的“目录页”，终极形成的基本构造如下图所示：

数据页中记录是连续存放的，当须要访问某个页的数据时，就会把完全的页的数据全部加载到内存中，也便是说纵然我们只须要访问一个页的一条记录，那也须要先把全体页的数据加载到内存中。
这就利用了局部性事理中的“空间局部性”。
将全体页加载到内存中后就可以进行读写访问了，在进行完读写访问之后并不焦急把该页对应的内存空间开释掉，而是将其缓存到Buffer Pool中，这样将来有要求再次访问该页面时，就可以省去磁盘IO的开销了，这又利用了局部性事理中的“韶光局部性”。

局部性事理是系统缓存设计中非常主要的理论基石，下文还会多次提到。

本节我们来聊一聊Cpu 高速缓存，Cpu 高速缓存是影响程序性能的一个关键成分。

笔者直接引用维基百科中对Cpu 高速缓存的描述：

在打算机系统中，CPU高速缓存（英语：CPU Cache，在本文中简称缓存）是用于减少处理器访问内存所需均匀韶光的部件。
在金字塔式存储体系中它位于自顶向下的第二层，仅次于CPU寄存器。
其容量远小于内存，但速率却可以靠近处理器的频率。
当处理器发出内存访问要求时，会先查看缓存内是否有要求数据。
如果存在（命中），则不经访问内存直接返回该数据；如果不存在（失落效），则要先把内存中的相应数据载入缓存，再将其返回处理器。
缓存之以是有效，紧张是由于程序运行时对内存的访问呈现局部性（Locality）特色。
这种局部性既包括空间局部性（Spatial Locality），也包括韶光局部性（Temporal Locality）。
有效利用这种局部性，缓存可以达到极高的命中率。
在处理器看来，缓存是一个透明部件。
因此，程序员常日无法直接干预对缓存的操作。
但是，确实可以根据缓存的特点对程序代码履行特定优化，从而更好地利用缓存。

上文中我们提到冯诺依曼瓶颈。
随着工艺的提升，最近几十年CPU的频率不断提升，而受制于制造工艺和本钱限定，目前打算机的内存在访问速率上没有质的打破。
因此，CPU的处理速率和内存的访问速率差距越来越大，这种情形下传统的 CPU 直连内存的办法显然就会由于内存访问的等待，导致打算资源大量闲置，降落 CPU 整体吞吐量。
同时又由于内存数据访问的热点集中性，在 CPU 和内存之间用较为快速而本钱较高（相对付内存）的介质做一层缓存，就显得性价比极高了。

早期打算机系统的存储器层次构造只有三层：CPU寄存器、DRAM主存储器和磁盘存储。
由于CPU和主存之间逐渐增大的差距，系统设计者被迫在CPU寄存器文件和主存之间插入了一个小的SRAM高速缓存存储器，称为L1高速缓存(一级缓存),如下图所示。
L1高速缓存的访问速率险些和寄存器相差无几。

随着CPU和主存之间的性能差距不断增大，系统设计者在L1高速缓存和主存之间又插入了一个更大的高速缓存，称为L2高速缓存，可以在大约10个时钟周期内访问到它。
当代的操作系统还包括一个更大的高速缓存，称为L3高速缓存,在存储器的层次构造中，它位于L2高速缓存和主存之间，可以在大约50个周期内访问到它。
下图是大略的高速缓存架构：

数据的读取和存储都经由高速缓存，CPU 核心与高速缓存有一条分外的快速通道；主存与高速缓存都连在系统总线上（BUS），这条总线还用于其他组件的通信。

关于Cpu 高速缓存的运用，PHP7数组的设计是一个非常经典的案例。
在PHP中数组是最常用的一种数据类型，提升数组的性能会使程序整体性能得到提升。
我们通过比拟PHP7和PHP5 数组的设计，来学习一下PHP 设计者为了提升PHP数组的性能，都进行了哪些思考。

我们先来总结一下PHP数组的特性：

PHP中数组利用hashTable实现，我们先来理解一下什么是hashTable。

hashTable是一种通过某种hash函数将特定的key映射到特定value的一种数据构造，它掩护着键和值的逐一对应关系，并且可以快速的根据键找到值(o(1)). 一样平常HashTable的示意图如下:

1) key: 通过key可以快速找到value。
一样平常可以为数字或者字符串。
2) value: 值可以为繁芜构造3) bucket: 桶，HashTable存储数据的单元，用来存储key/value以及其他赞助信息的容器4) slot:槽，HashTable有多少个槽，一个bucket必须属于详细的某一个slot，一个slot可以有多个 bucket5) 哈希函数:一样平常都是自己实现（time33），在存储的时候，会将key通过hash函数确定所在的slot6) 哈希冲突: 当多个key经由哈希打算后，得到的slot位置是同一个，那么就会冲突，一样平常这个时候会有 2种办理办法:链地址法和开放地址法。
个中php采取的是链地址法，即将同一个slot中的bucket通过 链表连接起来复制代码

为了实现数组的插入有序和遍历有序，PHP5利用hashTable + 双链表实现数组，如下图是将key分别为：“a”,"b","c","d",值为“1”,"2","3","4" 插入到数组中后的效果：

上图中b,c,d所在的bucket被存分配到了同一个slot，为理解决hash冲突，slot中多个bucket通过双向链表关联，称为局部双向链表；为了实现有序，slot之间也通过双向链表关联，称为全局双向链表。

理解php5数组的实现事理之后，我们创造个中影响性能的两个关键点：

针对以上两点，php7对hashTable的设计进行了改造。
既然是字典，还是要利用hashTable,但php7数组的实现去掉了slot，bucket的分配利用了连续内存；bucket间不再利用真实存在的指针进行掩护，bucket只掩护一个在数组中的索引，bucket与bucket之间通过内存地址进行关联，如下图所示:

PHP7中数组是如何办理hash冲突的？

PHP7对zval进行了改造，zval中有一个u2的union联合体，占用4字节大小，存放一些赞助信息。
PHP7数组中的value也是一个个的zval指针，当发生hash冲突时，zval中u2部分存放的next指针存放指向下一个bucket数组中的索引，通过这样一种逻辑上的链表就奥妙办理hash冲突。
关于PHP7中zval的设计，推举大家阅读鸟哥的文章：深入理解PHP7内核之zval

可以看到，php7中hashTable对性能提升最主要的改动是bucket的分配利用了连续内存。
这样不仅省去了数组元素插入时频繁的内存分配开销；遍历数组也只须要一个bucket一个bucket的访问就好了，Cpu 高速缓存命中率非常高，极大的提升了数组性能；符合局部性事理。

更多关于PHP5和PHP7数组的设计细节，推举大家研究这篇文章：【PHP7源码学习】系列之数组实现

举一个多级缓存的运用案例：浏览器对我们生活的影响是不言而喻的，当代的浏览器已经不同往昔了，快速的信息加载，顺畅的用户交互，这统统都得益于网络技能的遍及、H5标准特性的推广运用，当然还有一个主要成分，那便是浏览器的缓存策略。
本节我们就来大略先容一下浏览器的多级缓存机制。

对付一个数据要求来说，可以分为发起网络要求、后端处理、浏览器相应三个步骤。
浏览器缓存可以帮助我们在第一和第三步骤中优化性能。
比如说直策应用缓存而不发起要求，或者发起了要求但后端存储的数据和前端同等，那么就没有必要再将数据回传回来，这样就减少了相应数据。

浏览器有四种缓存级别，它们各自都有优先级。

当依次查找缓存且都没有命中的时候，才会去要求网络。

Service Worker 是运行在浏览器背后的独立线程，一样平常可以用来实现缓存功能。
利用 Service Worker的话，传输协议必须为 HTTPS。
由于 Service Worker 中涉及到要求拦截，以是必须利用 HTTPS 协议来保障安全。
Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由掌握缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。

Service Worker 实现缓存功能一样平常分为三个步骤：首先须要先注册 Service Worker，然后监听到 install 事宜往后就可以缓存须要的文件，那么不才次用户访问的时候就可以通过拦截要求的办法查询是否存在缓存，存在缓存的话就可以直接读取缓存文件，否则就去要求数据。

当 Service Worker 没有命中缓存的时候，我们须要去调用 fetch 函数获取数据。
也便是说，如果我们没有在 Service Worker 命中缓存的话，会根据缓存查找优先级去查找数据。
但是不管我们是从 Memory Cache 中还是从网络要求中获取的数据，浏览器都会显示我们是从 Service Worker 中获取的内容。

Memory Cache 也便是内存中的缓存，紧张包含的是当前页面中已经抓取到的资源,例如页面上已经下载的样式、脚本、图片等。
读取内存中的数据肯定比磁盘快，内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的开释而开释。
一旦我们关闭 Tab 页面，内存中的缓存也就被开释了。

当我们访问过页面往后，再次刷新页面，可以创造很多数据都来自于内存缓存

内存缓存中有一块主要的缓存资源是preloader干系指令（例如<link rel="prefetch">）下载的资源。
众所周知preloader的干系指令已经是页面优化的常见手段之一，它可以一边解析js/css文件，一边网络要求下一个资源。

须要把稳的事情是，内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值，同时资源的匹配也并非仅仅是对URL做匹配，还可能会对Content-Type，CORS等其他特色做校验。

为什么浏览器数据不都存放在内存中？

这个问题就算我不回答，读者肯定也都想明白了，打算机中的内存一定比硬盘容量小得多，操作系统须要一个钱打二十四个结内存的利用，以是能让我们利用的内存一定不多。
谷歌浏览器是公认的性能出众的，但是它占用的内存也是很大的。

Disk Cache 也便是存储在硬盘中的缓存，读取速率慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。

在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。
它会根据 HTTP Herder 中的字段判断哪些资源须要缓存，哪些资源可以不要求直策应用，哪些资源已经由期须要重新要求。
并且纵然在跨站点的情形下，相同地址的资源一旦被硬盘缓存下来，就不会再次去要求数据。
绝大部分的缓存都来自 Disk Cache。

浏览器会把哪些文件丢进内存中？哪些丢进硬盘中？

关于这点，网上说法不一，不过有些不雅观点比较可靠：对付大文件来说，大概率是不存储在内存中的，其余如果当前系统内存利用率高的话，文件优先存储进硬盘。

Push Cache（推送缓存）是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被利用。
它只在会话（Session）中存在，一旦会话结束就被开释，并且缓存韶光也很短暂，在Chrome浏览器中只有5分钟旁边，同时它也并非严格实行HTTP头中的缓存指令。

Push Cache 在海内能够查到的资料很少，也是由于 HTTP/2 在海内不足遍及。
这里推举阅读Jake Archibald的 HTTP/2 push is tougher than I thought 这篇文章，文章中的几个结论是：

如果以上四种缓存都没有命中的话，那么只能发起要求来获取资源了。

浏览器的多级缓存机制到这里就先容完了，大家可以看到，浏览器多级缓存机制的实现思路，和我们前边说到的打算机系统多级缓存的知识是相呼应的，并且也知足局部性事理。
浏览器缓存还有更多值得我们深入学习的内容，感兴趣的读者可以研究一下这篇文章：深入理解浏览器的缓存机制

根据金字塔存储器层次模型我们知道：CPU访问速率越快的存储组件容量越小。
在业务场景中，最常用的存储组件是内存和磁盘，我们每每将常用的数据缓存到内存中加快数据的读取速率，redis作为内存缓存数据库的设计也是基于这点考虑的。
但是做事器的内存有限，不可能不断的将数据存入内存中而不淘汰。
况且内存占用过大，也会影响做事器其它的任务，以是我们要做到通过淘汰算法让内存中的缓存数据发挥最大的代价。

本节将先容业务中最常用的三种缓存淘汰算法:

笔者会结合Redis、Mysql中缓存淘汰的详细实现机制来帮助读者学习到，Mysql和Redis的开拓者是若何结合各自的业务场景，对已有的缓存算法进行改进来知足业务需求的。

LRU是Least Recently Used的缩写，这种算法认为最近利用的数据是热门数据，下一次很大概率将会再次被利用。
而最近很少被利用的数据，很大概率下一次不再用到。
该思想非常契合业务场景 ，并且可以办理很多实际开拓中的问题，以是我们常常通过LRU的思想来作缓存，一样平常也将其称为LRU缓存机制。

本节笔者以leetcode上的一道算法题为例，利用代码(Go措辞)实现LRU算法，帮助读者更深入的理解LRU算法的思想。

leetcode 146: LRU缓存机制

利用你所节制的数据构造，设计和实现一个 LRU (最近最少利用) 缓存机制。
它该当支持以下操作： 获取数据 get 和 写入数据 put 。

获取数据 get(key) - 如果密钥 (key) 存在于缓存中，则获取密钥的值（总是正数），否则返回 -1。
写入数据 put(key, value) - 如果密钥已经存在，则变更其数据值；如果密钥不存在，则插入该组「密钥/数据值」。
当缓存容量达到上限时，它该当在写入新数据之前删除最久未利用的数据值，从而为新的数据值留出空间。

示例：

LRUCache cache = new LRUCache( 2 / 缓存容量 / ); cache.put(1, 1); cache.put(2, 2); cache.get(1); // 返回 1 cache.put(3, 3); // 该操作会使得密钥 2 作废 cache.get(2); // 返回 -1 (未找到) cache.put(4, 4); // 该操作会使得密钥 1 作废 cache.get(1); // 返回 -1 (未找到) cache.get(3); // 返回 3 cache.get(4); // 返回 4 复制代码

我们采取hashmap+双向链表的办法进行实现。
可以在 O(1)韶光内完成 put 和 get 操作，同时也支持 O(1) 删除第一个添加的节点。

利用双向链表的一个好处是不须要额外信息删除一个节点，同时可以在常数韶光内从头部或尾部插入删除节点。

一个须要把稳的是，在双向链表实现中，这里利用一个伪头部和伪尾部标记界线，这样在更新的时候就不须要检讨是否是 null 节点。

代码如下：

type LinkNode struct { key, val int pre, next LinkNode}type LRUCache struct { m map[int]LinkNode cap int head, tail LinkNode}func Constructor(capacity int) LRUCache { head := &LinkNode{0, 0, nil, nil} tail := &LinkNode{0, 0, nil, nil} head.next = tail tail.pre = head return LRUCache{make(map[int]LinkNode), capacity, head, tail}}复制代码

这样就初始化了一个基本的数据构造,大概是这样：

接下来我们为Node节点添加一些必要的操作方法，用于完成接下来的Get和Put操作：

func (this LRUCache) RemoveNode(node LinkNode) { node.pre.next = node.next node.next.pre = node.pre}func (this LRUCache) AddNode(node LinkNode) { head := this.head node.next = head.next head.next.pre = node node.pre = head head.next = node}func (this LRUCache) MoveToHead(node LinkNode) { this.RemoveNode(node) this.AddNode(node)}复制代码

由于Get比较大略，我们先完成Get方法。
这里分两种情形考虑：

func (this LRUCache) Get(key int) int { cache := this.m if v, exist := cache[key]; exist { this.MoveToHead(v) return v.val } else { return -1 }}复制代码

现在我们开始完成Put。
实现Put时，有两种情形须要考虑。

处理完毕，附上Put函数完全代码。

func (this LRUCache) Put(key int, value int) { tail := this.tail cache := this.m if v, exist := cache[key]; exist { v.val = value this.MoveToHead(v) } else { v := &LinkNode{key, value, nil, nil} if len(cache) == this.cap { delete(cache, tail.pre.key) this.RemoveNode(tail.pre) } this.AddNode(v) cache[key] = v }}复制代码

至此，我们就完成了一个LRU算法，附上完全的代码：

type LinkNode struct { key, val int pre, next LinkNode}type LRUCache struct { m map[int]LinkNode cap int head, tail LinkNode}func Constructor(capacity int) LRUCache { head := &LinkNode{0, 0, nil, nil} tail := &LinkNode{0, 0, nil, nil} head.next = tail tail.pre = head return LRUCache{make(map[int]LinkNode), capacity, head, tail}}func (this LRUCache) Get(key int) int { cache := this.m if v, exist := cache[key]; exist { this.MoveToHead(v) return v.val } else { return -1 }}func (this LRUCache) RemoveNode(node LinkNode) { node.pre.next = node.next node.next.pre = node.pre}func (this LRUCache) AddNode(node LinkNode) { head := this.head node.next = head.next head.next.pre = node node.pre = head head.next = node}func (this LRUCache) MoveToHead(node LinkNode) { this.RemoveNode(node) this.AddNode(node)}func (this LRUCache) Put(key int, value int) { tail := this.tail cache := this.m if v, exist := cache[key]; exist { v.val = value this.MoveToHead(v) } else { v := &LinkNode{key, value, nil, nil} if len(cache) == this.cap { delete(cache, tail.pre.key) this.RemoveNode(tail.pre) } this.AddNode(v) cache[key] = v }}复制代码2.1.2 Mysql缓冲池LRU算法

在利用Mysql的业务场景中，如果利用上述我们描述的LRU算法来淘汰策略，会有一个问题。
例如实行下面一条查询语句：

select from table_a;复制代码

如果 table_a 中有大量数据并且读取之后不会连续利用,则LRU头部会被大量的 table_a 中的数据霸占,这样会造成热点数据被逐出缓存从而导致大量的磁盘IO。
以是Mysql缓冲池采取the least recently used（LRU）算法的变体，将缓冲池作为列表进行管理。

Mysql的缓冲池

缓冲池（Buffer Pool）是主缓存器的一个区域，用于缓存索引、行的数据、自适应哈希索引、插入缓存（Insert Buffer）、锁 还有其他的内部数据构造。
Buffer Pool的大小是可以根据我们实际的需求进行变动，那么Buffer Pool的size取多少比较得当?MySQL官网上是这么先容，在专用做事器上（也便是做事器只承载一个MySQL实例），会将80%的物理内存给到Buffer Pool。
Buffer Pool许可直接从内存中读常用数据去处理，会加快很多的速率。
为了提高大容量读取操作的效率，Buffer Pool被分成可以容纳多行的页面。
为了提高缓存管理的效率，Buffer Pool被实现为页面对应的链接的列表（a linked list of pages）。

Mysql数据库Buffer Pool构造：

当须要空间将新页面缓存到缓冲池的时候，最近最少利用的页面将被开释出去，并将新的页面加入列表的中间。
这个中间点插入的策略将列表分为两个子列表：

该算法将保留 new sublist（也便是构造图中头部）中大量被查询利用的页面。
而old sublist 里面较少被利用的页面作为被开释的候选项。

理解以下几个关键点是比较主要的：

通过对LRU算法的改进，InnoDB引擎办理了查询数据量大时，热点数据被逐出缓存从而导致大量的磁盘IO的问题。

由于真实LRU须要过多的内存（在数据量比较大时）；并且Redis以高性能著称，真实的LRU须要每次访问数据时都做干系的调度，势必会影响Redis的性能发挥；这些都是Redis开拓者所不能接管的，以是Redis利用一种随机抽样的办法，来实现一个近似LRU的效果。

在Redis中有一个参数，叫做 “maxmemory-samples”，是干嘛用的呢？

1 # LRU and minimal TTL algorithms are not precise algorithms but approximated 2 # algorithms (in order to save memory), so you can tune it for speed or 3 # accuracy. For default Redis will check five keys and pick the one that was 4 # used less recently, you can change the sample size using the following 5 # configuration directive. 6 # 7 # The default of 5 produces good enough results. 10 Approximates very closely 8 # true LRU but costs a bit more CPU. 3 is very fast but not very accurate. 9 # 10 maxmemory-samples 5复制代码

上面我们说过了，近似LRU是用随机抽样的办法来实现一个近似的LRU效果。
这个参数实在便是作者供应了一种办法，可以让我们人为干预样本数大小，将其设的越大，就越靠近真实LRU的效果，当然也就意味着越耗内存。
（初始值为5是作者默认的最佳）

左上图为空想中的LRU算法,新增加的key和最近被访问的key都不应该被逐出。
可以看到,Redis2.8当每次随机采样5个key时，新增加的key和最近访问的key都有一定概率被逐出；Redis3.0增加了pool后效果好一些(右下角的图)。
当Redis3.0增加了pool并且将采样key增加到10个后，基本等同于空想中的LRU(虽然还是有一点差距)。

Redis中对LRU代码实现也比较大略。
Redis掩护了一个24位时钟，可以大略理解为当前系统的韶光戳，每隔一定韶光会更新这个时钟。
每个key工具内部同样掩护了一个24位的时钟，当新增key工具的时候会把系统的时钟赋值到这个内部工具时钟。
比如我现在要进行LRU，那么首先拿到当前的全局时钟，然后再找到内部时钟与全局时钟间隔韶光最久的（差最大）进行淘汰，这里值得把稳的是全局时钟只有24位，按秒为单位来表示才能存储194天，以是可能会涌现key的时钟大于全局时钟的情形，如果这种情形涌现那么就两个相加而不是相减来求最久的key。

struct redisServer { pid_t pid; char configfile; //全局时钟 unsigned lruclock:LRU_BITS; ...};复制代码

typedef struct redisObject { unsigned type:4; unsigned encoding:4; / key工具内部时钟 / unsigned lru:LRU_BITS; int refcount; void ptr;} robj;复制代码

总结一下：Redis中的LRU与常规的LRU实现并不相同，常规LRU会准确的淘汰掉队头的元素，但是Redis的LRU并不掩护行列步队，只是根据配置的策略要么从所有的key中随机选择N个（N可以配置）,要么从所有的设置了过期韶光的key中选出N个键，然后再从这N个键中选出最久没有利用的一个key进行淘汰。

LFU（Least Frequently Used）算法根据数据的历史访问频率来淘汰数据，其核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。
LFU的每个数据块都有一个引用计数，所有数据块按照引用计数排序，具有相同引用计数的数据块则按照韶光排序。
LFU须要记录所有数据的访问记录，内存花费较高；须要基于引用计数排序，性能花费较高。
在算法实现繁芜度上，LFU要远大于LRU。

本节笔者以leetcode上的一道算法题为例，利用代码实现LFU算法，帮助读者更深入的理解LFU算法的思想。

leetcode 460: LFU缓存

请你为 最不常常利用（LFU）缓存算法设计并实现数据构造。
它该当支持以下操作：get 和 put。

get(key) - 如果键存在于缓存中，则获取键的值（总是正数），否则返回 -1。
put(key, value) - 如果键已存在，则变更其值；如果键不存在，请插入键值对。
当缓存达到其容量时，则该当在插入新项之前，使最不常常利用的项无效。
在此问题中，当存在平局（即两个或更多个键具有相同利用频率）时，该当去除最久未利用的键。
「项的利用次数」便是自插入该项以来对其调用 get 和 put 函数的次数之和。
利用次数会在对应项被移除后置为 0 。
示例： LFUCache cache = new LFUCache( 2 / capacity (缓存容量) / ); cache.put(1, 1); cache.put(2, 2); cache.get(1); // 返回 1 cache.put(3, 3); // 去除 key 2 cache.get(2); // 返回 -1 (未找到key 2) cache.get(3); // 返回 3 cache.put(4, 4); // 去除 key 1 cache.get(1); // 返回 -1 (未找到 key 1) cache.get(3); // 返回 3 cache.get(4); // 返回 4 复制代码

上一节我们聊到LRU算法，LRU的实现是一个哈希表加上一个双链表，比较大略。
而LFU则要繁芜多了，须要用两个哈希表再加上N个双链表才能实现 我们先看看LFU的两个哈希表里面都存了什么。

第一个哈希表是key-value的哈希表(以下简称kv哈希表)

这里的key便是输入的key，没什么特殊的。
关键是value，它的value不是一个大略的value，而是一个节点工具。
节点工具Node包含了key，value，以及频率，这个Node又会涌如今第二个哈希表的value中。
至于为什么Node中又重复包含了key，由于某些情形下我们不是通过k-v哈希表拿到Node的，而是通过其他办法得到了Node，之后须要用Node中的key去k-v哈希表中做一些操作，以是Node中包含了一些冗余信息。

第二张哈希表，频率哈希表，这个就要繁芜多了

这张哈希表中的key是频率，也便是元素被访问的频率(被访问了1次，被访问了两次等等)，它的value是一个双向链表 刚才说的Node工具，现在又涌现了，这里的Node实在是双向链表中的一个节点。
第一张图中我们先容了Node中包含了一个冗余的key，实在它还包含了一个冗余的频率值，由于某些情形下，我们须要通过Node中的频率值，去频率哈希表中做查找，以是也须要一个冗余的频率值。

下面我们将两个哈希表整合起来看看完全的构造:

k-v哈希表中key1指向一个Node，这个Node的频率为1，位于频率哈希表中key=1下面的双链表中(处于第一个节点)。

根据上边的描述就可以定义出我们要利用到的数据构造和双链表的基本操作代码(利用Go措辞)：

type LFUCache struct { cache map[int]Nodefreq map[int]DoubleListncap, size, minFreq int}//节点nodetype Node struct {key, val, freq intprev, next Node}//双链表type DoubleList struct {tail, head Node}//创建一个双链表func createDL() DoubleList {head, tail := &Node{}, &Node{}head.next, tail.prev = tail, headreturn &DoubleList{tail: tail,head: head,}}func (this DoubleList) IsEmpty() bool {return this.head.next == this.tail}//将node添加为双链表的第一个元素func (this DoubleList) AddFirst(node Node) {node.next = this.head.nextnode.prev = this.headthis.head.next.prev = nodethis.head.next = node}func (this DoubleList) RemoveNode(node Node) {node.next.prev = node.prevnode.prev.next = node.nextnode.next = nilnode.prev = nil}func (this DoubleList) RemoveLast() Node {if this.IsEmpty() {return nil}lastNode := this.tail.prevthis.RemoveNode(lastNode)return lastNode}复制代码

下边我们来看一下LFU算法的详细的实现吧，get操作相对大略一些，我们就先说get操作吧。
get操作的详细逻辑大致是这样：

第一个很大略就不用说了，我们看下第二点的实行过程：

假设某个元素的访问频率是3，现在又被访问了一次，那么就须要将这个元素移动到频率4的链表中。
如果这个元素被移除后，频率3的那个链表变成空了(只剩下头结点和尾节点)就须要删除这个链表，同时删除对应的频率(也便是删除key=3),我们看下实行过程：

LFU中Get方法代码实现：

func (this LFUCache) Get(key int) int { if node, ok := this.cache[key]; ok {this.IncrFreq(node)return node.val}return -1}func(this LFUCache) IncrFreq(node Node) {_freq := node.freqthis.freq[_freq].RemoveNode(node)if this.minFreq == _freq && this.freq[_freq].IsEmpty() {this.minFreq++delete(this.freq, _freq)}node.freq++if this.freq[node.freq] == nil {this.freq[node.freq] = createDL()}this.freq[node.freq].AddFirst(node)}复制代码

put操作就要繁芜多了，大致包括下面几种情形

我们在代码实现中还须要掩护一个minFreq的变量，用来记录LFU缓存中频率最小的元素，在缓存满的时候，可以快速定位到最小频繁的链表，以达到 O(1) 韶光繁芜度删除一个元素。
详细做法是:

我们重点看下缓存超过最大容量时是怎么处理的:

LFU中Put方法代码实现：

func (this LFUCache) Put(key int, value int) { if this.ncap == 0 {return}//节点存在 if node, ok := this.cache[key]; ok {node.val = valuethis.IncrFreq(node)} else {if this.size >= this.ncap {node := this.freq[this.minFreq].RemoveLast()delete(this.cache, node.key)this.size--}x := &Node{key: key, val: value, freq: 1}this.cache[key] = xif this.freq[1] == nil {this.freq[1] = createDL()}this.freq[1].AddFirst(x)this.minFreq = 1this.size++}}复制代码

通过对一道LFU基本算法的剖析与实现，相信读者已经领悟到了LFU算法的思想及其繁芜性。
很多算法本身便是繁芜的，不但要整合各种数据构造，还要根据运用处景进行剖析，并不断改进。
但是算法确确实实的办理很多实际的问题，我们已经知道了缓存的主要性，但一个好的缓存策略除了要充分利用各种打算机存储组件，良好的算法设计也是必不可少的。
以是我们再来总体回顾一下本节LFU算法的实现吧：

type LFUCache struct { cache map[int]Nodefreq map[int]DoubleListncap, size, minFreq int}func(this LFUCache) IncrFreq(node Node) {_freq := node.freqthis.freq[_freq].RemoveNode(node)if this.minFreq == _freq && this.freq[_freq].IsEmpty() {this.minFreq++delete(this.freq, _freq)}node.freq++if this.freq[node.freq] == nil {this.freq[node.freq] = createDL()}this.freq[node.freq].AddFirst(node)}func Constructor(capacity int) LFUCache { return LFUCache{cache: make(map[int]Node),freq: make(map[int]DoubleList),ncap: capacity,}}func (this LFUCache) Get(key int) int { if node, ok := this.cache[key]; ok {this.IncrFreq(node)return node.val}return -1}func (this LFUCache) Put(key int, value int) { if this.ncap == 0 {return}//节点存在 if node, ok := this.cache[key]; ok {node.val = valuethis.IncrFreq(node)} else {if this.size >= this.ncap {node := this.freq[this.minFreq].RemoveLast()delete(this.cache, node.key)this.size--}x := &Node{key: key, val: value, freq: 1}this.cache[key] = xif this.freq[1] == nil {this.freq[1] = createDL()}this.freq[1].AddFirst(x)this.minFreq = 1this.size++}}//节点nodetype Node struct {key, val, freq intprev, next Node}//双链表type DoubleList struct {tail, head Node}//创建一个双链表func createDL() DoubleList {head, tail := &Node{}, &Node{}head.next, tail.prev = tail, headreturn &DoubleList{tail: tail,head: head,}}func (this DoubleList) IsEmpty() bool {return this.head.next == this.tail}//将node添加为双链表的第一个元素func (this DoubleList) AddFirst(node Node) {node.next = this.head.nextnode.prev = this.headthis.head.next.prev = nodethis.head.next = node}func (this DoubleList) RemoveNode(node Node) {node.next.prev = node.prevnode.prev.next = node.nextnode.next = nilnode.prev = nil}func (this DoubleList) RemoveLast() Node {if this.IsEmpty() {return nil}lastNode := this.tail.prevthis.RemoveNode(lastNode)return lastNode}复制代码2.2.2 Redis LFU淘汰策略

一样平常情形下，LFU效率要优于LRU，且能够避免周期性或者偶发性的操作导致缓存命中率低落的问题，在如下情形下：

~~~~~A~~~~~A~~~~~A~~~~A~~~~~A~~~~~A~~|~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~|~~~~~~~~~~C~~~~~~~~~C~~~~~~~~~C~~~~~~|~~~~~D~~~~~~~~~~D~~~~~~~~~D~~~~~~~~~D|复制代码

会将数据D误认为将来最有可能被访问到的数据。

Redis作者曾想改进LRU算法，但创造Redis的LRU算法受制于随机采样数maxmemory_samples，在maxmemory_samples即是10的情形下已经很靠近于空想的LRU算法性能，也便是说，LRU算法本身已经很难再进一步了。

于是，将思路回到原点，淘汰算法的本意是保留那些将来最有可能被再次访问的数据，而LRU算法只是预测最近被访问的数据将来最有可能被访问到。
我们可以转变思路，采取LFU(Least Frequently Used)算法，也便是最频繁被访问的数据将来最有可能被访问到。
在上面的情形中，根据访问频繁情形，可以确定保留优先级：B>A>C=D。

在LFU算法中，可以为每个key掩护一个计数器。
每次key被访问的时候，计数器增大。
计数器越大，可以约即是访问越频繁。

上述大略算法存在两个问题：

我们前边说过Redis工具的构造：

typedef struct redisObject { unsigned type:4; unsigned encoding:4; unsigned lru:LRU_BITS; / LRU time (relative to global lru_clock) or LFU data (least significant 8 bits frequency and most significant 16 bits access time). / int refcount; void ptr;} robj;复制代码

在LRU算法中，24 bits的lru是用来记录LRU time的，在LFU中也可以利用这个字段，不过是分成16 bits与8 bits利用：

16 bits 8 bits +----------------+--------+ + Last decr time | LOG_C | +----------------+--------+复制代码

高16 bits用来记录最近一次计数器降落的韶光ldt，单位是分钟，低8 bits记录计数器数值counter。

Redis4.0之后为maxmemory_policy淘汰策略添加了两个LFU模式：

还有2个配置可以调度LFU算法：

lfu-log-factor 10lfu-decay-time 1复制代码lfu-log-factor可以调度计数器counter的增长速率，lfu-log-factor越大，counter增长的越慢。
lfu-decay-time是一个以分钟为单位的数值，可以调度counter的减少速率

源码实现

在lookupKey中：

robj lookupKey(redisDb db, robj key, int flags) { dictEntry de = dictFind(db->dict,key->ptr); if (de) { robj val = dictGetVal(de); / Update the access time for the ageing algorithm. Don't do it if we have a saving child, as this will trigger a copy on write madness. / if (server.rdb_child_pid == -1 && server.aof_child_pid == -1 && !(flags & LOOKUP_NOTOUCH)) { if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) { updateLFU(val); } else { val->lru = LRU_CLOCK(); } } return val; } else { return NULL; }}复制代码

当采取LFU策略时，updateLFU更新lru：

/ Update LFU when an object is accessed. Firstly, decrement the counter if the decrement time is reached. Then logarithmically increment the counter, and update the access time. /void updateLFU(robj val) { unsigned long counter = LFUDecrAndReturn(val); counter = LFULogIncr(counter); val->lru = (LFUGetTimeInMinutes()<<8) | counter;}复制代码

降落LFUDecrAndReturn

首先，LFUDecrAndReturn对counter进行减少操作：

/ If the object decrement time is reached decrement the LFU counter but do not update LFU fields of the object, we update the access time and counter in an explicit way when the object is really accessed. And we will times halve the counter according to the times of elapsed time than server.lfu_decay_time. Return the object frequency counter. This function is used in order to scan the dataset for the best object to fit: as we check for the candidate, we incrementally decrement the counter of the scanned objects if needed. /unsigned long LFUDecrAndReturn(robj o) { unsigned long ldt = o->lru >> 8; unsigned long counter = o->lru & 255; unsigned long num_periods = server.lfu_decay_time ? LFUTimeElapsed(ldt) / server.lfu_decay_time : 0; if (num_periods) counter = (num_periods > counter) ? 0 : counter - num_periods; return counter;}复制代码

函数首先取得高16 bits的最近降落韶光ldt与低8 bits的计数器counter，然后根据配置的lfu_decay_time打算该当降落多少。

LFUTimeElapsed用来打算当前韶光与ldt的差值：

/ Return the current time in minutes, just taking the least significant 16 bits. The returned time is suitable to be stored as LDT (last decrement time) for the LFU implementation. /unsigned long LFUGetTimeInMinutes(void) { return (server.unixtime/60) & 65535;}/ Given an object last access time, compute the minimum number of minutes that elapsed since the last access. Handle overflow (ldt greater than the current 16 bits minutes time) considering the time as wrapping exactly once. /unsigned long LFUTimeElapsed(unsigned long ldt) { unsigned long now = LFUGetTimeInMinutes(); if (now >= ldt) return now-ldt; return 65535-ldt+now;}复制代码

详细是当前韶光转化身分钟数后取低16 bits，然后打算与ldt的差值now-ldt。
当ldt > now时，默认为过了一个周期(16 bits，最大65535)，取值65535-ldt+now。

然后用差值与配置lfu_decay_time相除，LFUTimeElapsed(ldt) / server.lfu_decay_time，已过去n个lfu_decay_time，则将counter减少n，counter - num_periods。

增长LFULogIncr

增长函数LFULogIncr如下：

/ Logarithmically increment a counter. The greater is the current counter value the less likely is that it gets really implemented. Saturate it at 255. /uint8_t LFULogIncr(uint8_t counter) { if (counter == 255) return 255; double r = (double)rand()/RAND_MAX; double baseval = counter - LFU_INIT_VAL; if (baseval < 0) baseval = 0; double p = 1.0/(basevalserver.lfu_log_factor+1); if (r < p) counter++; return counter;}复制代码

counter并不是大略的访问一次就+1，而是采取了一个0-1之间的p因子掌握增长。
counter最大值为255。
取一个0-1之间的随机数r与p比较，当r<p时，才增加counter，这和比特币中掌握产出的策略类似。
p取决于当前counter值与lfu_log_factor因子，counter值与lfu_log_factor因子越大，p越小，r<p的概率也越小，counter增长的概率也就越小。
增长情形如下：

# +--------+------------+------------+------------+------------+------------+# | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits |# +--------+------------+------------+------------+------------+------------+# | 0 | 104 | 255 | 255 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 1 | 18 | 49 | 255 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 10 | 10 | 18 | 142 | 255 | 255 |# +--------+------------+------------+------------+------------+------------+# | 100 | 8 | 11 | 49 | 143 | 255 |# +--------+------------+------------+------------+------------+------------+复制代码

可见counter增长与访问次数呈现对数增长的趋势，随着访问次数越来越大，counter增长的越来越慢。

新生key策略

其余一个问题是，当创建新工具的时候，工具的counter如果为0，很随意马虎就会被淘汰掉，还须要为新生key设置一个初始counter，createObject:

robj createObject(int type, void ptr) { robj o = zmalloc(sizeof(o)); o->type = type; o->encoding = OBJ_ENCODING_RAW; o->ptr = ptr; o->refcount = 1; / Set the LRU to the current lruclock (minutes resolution), or alternatively the LFU counter. / if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) { o->lru = (LFUGetTimeInMinutes()<<8) | LFU_INIT_VAL; } else { o->lru = LRU_CLOCK(); } return o;}复制代码

counter会被初始化为LFU_INIT_VAL，默认5。

总结一下：Redis的LFU缓存淘汰策略复用了redis工具中的24 bits lru, 不过分成了分成16 bits与8 bits利用，高16 bits用来记录最近一次计数器降落的韶光ldt，单位是分钟，低8 bits记录计数器数值counter。
Redis工具的计数器并不是线性增长的，而是供应了lfu-log-factor配置项来掌握技能器的增长速率。
为理解决历史数据影响将来数据的“缓存污染”问题，Redis工具的计数会根据lfu_decay_time配置项随韶光做调度。
redis为每一个新增的key都设置了初始counter，目的是防止新增的key很随意马虎就被淘汰掉。

FIFO（First in First out），前辈先出。
在FIFO Cache设计中，核心原则便是：如果一个数据最前辈入缓存中，则该当最早淘汰掉。
实现方法很大略，只要利用行列步队数据构造即可实现。

由于缓存命中率比较低，FIFO缓存策略常日不会在项目中利用。
客不雅观唯心主义的理论：存在即合理，下边笔者就描述一下FIFO行列步队在Redis主从复制过程中的运用。

在Redis主从构造中，主节点要将数据同步给从节点，从一开始主从建立连接到数据同步一共分为三个阶段：

第一阶段首先建立连接，然后第二阶段主节点发送rdb文件给从节点同步全量数据；我们紧张看第三阶段主节点反复同步增量数据给从节点的过程是什么样的。

从节点和主节点建立连接时，主节点做事器会掩护一个复制积压缓冲区来暂存增量的同步命令；当从节点向主节点哀求同步数据时，主节点根据从节点同步数据的offset将数据增量的同步给从节点，反复进行。

复制积压缓冲区是一个前辈先出(FIFO)的环形行列步队，用于存储做事端实行过的命令，每次传播命令，master节点都会将传播的命令记录下来，保存在这里。

复制积压缓冲区由两部分组成：偏移量和字节值。
字节值是redis指令字节的存储（redis指令以一种Redis序列化文本协议的格式存储），偏移量offset便是当前字节值在环形行列步队中的偏移量。

主节点掩护了每个从节点的offset，这样每次同步数据时，主节点就知道该同步哪一部分数据给从节点了。
通过这样一个复制积压缓冲区，Redis的主从架构实现了数据的增量同步，想要理解更多主从同步细节的读者可以参考我的另一篇博客：Redis高可用——主从复制

本节花费了大量篇幅先容缓存淘汰策略，我们再来从缓存命中率、实现繁芜度、存储本钱、毛病这四个方面来对这三种缓存策略做一个比拟：

缓存淘汰策略

缓存命中率

实现繁芜度

存储本钱

毛病

FIFO

低

非常大略

很低

速率很快，不过没有什么实用代价

LRU

高

相对大略

高

偶发性的、周期性的批量操作会导致LRU命中率急剧低落，缓存污染情形比较严重。

LFU

非常高

相对繁芜

很高，须要很大的存储空间

L存在历史数据影响将来数据的“缓存污染”

Redis、Mysql的缓存设计都考虑了本节讲到的缓存淘汰策略的思想，并结合自身的业务场景进行了改进实现。
缓存淘汰策略没有十全十美的，根据详细的业务和需求选择得当缓存淘汰算法，提升缓存命中率是我们学习本节的目的。

缓存安全是非常热点的话题，大多数企业在的架构师在设计缓存系统时都会考虑“缓存安全”干系的问题，尤其是当做事到达一定量级之后，“缓存安全”便是一个不得不考虑的问题了。
其余在口试过程中，“缓存安全”干系的问题也是热点，由于懂得这些太主要了，每一个问题产生的缘故原由可能是什么？有效的办理方案有哪些？若何避免这些问题的产生？这些都是一个合格的程序员该当知道的。

本节就结合redis缓存中间件的利用，和大家一块谈谈“缓存安全”中最常见的问题。
并先容干系的办理方案和规避方法。

俗话说万事开头难，对付运用了redis缓存中间件的系统来说也会存在这样的问题。
当系统并发很高，并采取了主从架构的时候，做事启动便是一件很困难的事情！
究其缘故原由，系统刚启动时，缓存中没有数据，那么做事启动就须要大量的访问数据库，并瞬间产生大量的缓存数据，主从之间吞吐量增大，数据同步频度增加，可能做事刚启动不久就会宕机。

办理方案也很大略，我们最好先统计出访问频度比较高的热点数据，根据统计结果将数据分类，让redis缓存做事优先加载那些访问频度高的热点数据。
当然了，这个过程最好做成“预加载”，在做事启动之前先加载了热点数据，手工实行方案难以实现时，可以借助脚本或者CDN的办法进行。

总结来讲：缓存预热便是系统启动前，提前将干系的缓存数据直接加载到缓存系统。
避免用户要求的时候，先查询数据库，然后再将数据缓存的问题，让用户直接查询被预热的缓存数据。

缓存雪崩是缓存做事中常常遇见的问题，下边是一个缓存雪崩事件发生的大致过程：

排查上述缓存雪崩问题涌现的缘故原由，我们就会得到这样一个结论：

产生“缓存雪崩”的根本缘故原由是：在一个较短的韶光内，缓存中较多的key集中过期了。

我们可以利用这个结论来阐明一下上述征象发生的过程。
缓存中大量的key同时过期往后，redis缓存无法命中，要求就会到达数据库；如果并发量很大，数据库根本无法及时处理，Redis的要求就会被积压，并逐渐涌现超时征象；数据库随着流量的激增崩溃了，这个时候重启做事器是没故意义的，由于系统的关键问题是缓存中无可用数据，Redis的做事器资源被占用，做事器也随着崩溃，集群崩塌，运用做事器也会随着客户真个要求增加而崩溃。
涌现了这个局势往后，我们重启做事器、redis和数据库都是没故意义的！
下面缓存雪崩的大略示意图：

如果“缓存雪崩”问题已经发生了，该当若何办理呢？下边列举一些有效的方案：

既然我们知道了“缓存雪崩”产生的缘故原由是一个较短的韶光内，大量的热点key集中过期导致的，我们有必要学习一些方法来预防“缓存雪崩”的发生。
最有效的方法便是根据业务数据将缓存的有效期错峰，数据的过期韶光采取固定时间 + 随机韶光戳的办法，稀释集中到期key的数量，乃至说超热的数据，采取永久key也是可以的。
还记得我们第二部分提到的缓存淘汰策略吗？将LRU切换为LFU淘汰策略，也是可以有效预防“缓存雪崩”的。
如果你认为问题还是不太好办理，想要采取手动掩护的办法也是可以的，可以定期对访问数据做统计，给热点数据续租过期韶光也是可以的。

总结来讲：缓存雪崩便是瞬间过期数据量太大，给数据库做事器造成压力。
如果能够有效避免过期韶光集中，就可以有效防止雪崩问题的涌现，再合营其它策略的一起利用，并监控做事器的运行数据并做及时的调度，基本是可以防止“缓存雪崩”情形发生的。

理解了缓存雪崩之后，我们不妨思考这样一个问题：造成缓存雪崩的缘故原由是大量的热点key在集中过期，如果一个超热的key过期，会不会也造成这种问题呢？

答案是肯定的！
我们试想这样的场景，双11秒杀活动一台mac电脑99元，秒杀活动一开始，几百万的QPS上来了，缓存数据过期了，这么大的访问量达到了数据库，数据库肯定挂了！
这便是我们本节要讲的“缓存击穿”。

比拟“缓存雪崩”我们会创造，“缓存击穿”和“缓存雪崩”在很多征象上来说是比较相似的，而且我们上节说到的办理“缓存雪崩”的方案拿到这里，大都是能够适用的。
和“缓存雪崩”不同的是，“缓存击穿”发生后，redis的内存和CPU并不会有非常，也不会造成运用做事器的崩溃，也便是说“缓存击穿”不太随意马虎发生，造成的后果也没有“缓存雪崩”严重。
但是在“秒杀”场景下确确实实会存在这样的问题。

我们还是先来说一下如何办理和预防“缓存击穿”的问题吧。
一样平常来讲，“缓存击穿”的问题发生前都是可以预见的，比如“秒杀”活动开始前后，肯定会有大量的客户端要求，那么当系统中高热的缓存key过期后，手动的加载到redis肯定是可以的。
再或者活动期间我们就利用永久的key，并配置LFU的缓存淘汰策略，也是可以办理这个问题的。
当然还有其它的一些办理方案，就比如作者之前曾剖析过12306是若何承受高并发流量的，个中利用了本地缓存合营redis缓存的多级缓存办法，这种办法对付办理缓存击穿也是有效的，只要本地缓存和redis中的缓存不要同时过期就行，大量的流量也不会压到数据库。

总结一下：缓存过期便是单个高热数据过期的瞬间，数据访问量较大，未命中redis后，流量到达了数据库。
应对策略因此预防为主，合营监控及时调度就可以，紧张是在设计缓存系统时要考虑到这个问题。

本小节我们来谈论一下“缓存穿透”，首先“缓存穿透”和“缓存击穿”是不一样的，“缓存穿透”常常被黑客利用，目的是为了拖垮我们的做事器。

我们看一下发生“缓存穿透”是一种什么样的征象：系统平稳运行时，有了突发流量，Redis缓存的命中率开始低落，内存并没有什么非常，但是CPU开始激增，数据库访问也开始激增，直到数据库崩溃。

追查问题发生的实质缘故原由竟然是客户端访问的key在Redis缓存中不存在，并且数据库中也没有干系数据，基本上都是这样的key，彷佛有人故意而为之。
碰着这种情形，开拓者一定要提高当心，很有可能是涌现了黑客攻击！

查到问题往后，我们该如何办理呢？大部分人最先想到的便是既然黑客知道我们缓存中没有key，那么就将key缓存到Redis中，value是NULL就可以了。
如果你这么想，只能解释你太年轻了，首先黑客不至于傻到利用相同的key做攻击，再者大量的无效key缓存到redis内存中，redis就失落去了缓存的意义了。
当然，如果你创造这些要求都来自同一个ip或者客户端，可以临时的设置黑名单将攻击流量拒之门外，但是黑客一样平常都会采取DDos（分布式谢绝做事攻击），这种方法每每是无效的。

面对这样一种困境，业内最常用的方案是利用“布隆过滤器”。
虽然有一定的误判概率，但是只要参数设置的合理，确实能够有效地办理问题。

布隆过滤器是什么？

可以把布隆过滤器理解为一个不怎么精确的set构造，当你利用它的contains方法判断某个工具是否存在时，它可能会误判。
但是布隆过滤器也不是特殊的禁绝确，只要参数设置的合理，它的精确度是可以得到保障的。
当布隆过滤器说某个值不存在时，这个值可能不存在；但是它只要说某个值不存在，这个值就肯定不存在。

布隆过滤器的实现事理

每个布隆过滤器对应到Redis的数据构造里边便是一个大型的位数组和几个不一样的无偏hash函数（能够把元素的hash值算的比较均匀，让函数被hash映射到位数组中的位置比较随机）。
如果所示，f、g、h便是这样的hash函数。

向布隆过滤器中添加key时，会利用多个hash函数对key进行hash，先算得一个整数索引值，然后对位数组长度进行取模运算得到一个位置，每个hash函数都会算得一个不同的位置，再把位数组的这几个位置都设置为1。
向布隆过滤器中讯问key是否存在时，跟添加一样，也会把key通过hash得到的几个位置都算出来，看看数组中这几个位置是否都为1，只要有一个位置为0，那么解释这个值在布隆过滤器中是不存在的。

除了布隆过滤器这种方案，笔者认为，对业务中的key进行加密也是很有必要的，由于只要业务中的key如果是有规律可循的，黑客一样平常是不会知道的，我们就可以通过key的判断将黑客的攻击流量抵挡到redis缓存做事器前边。
此外缓存数据的监控一定要做好，能够及时地创造缓存命中率低落，就能够越早地采纳方法。

总结一下：“缓存穿透”是客户端访问了缓存和数据库中都不存在的数据，大量的这种访问会击垮数据库，当运维职员监控到这种情形时，一定要及时给出报警信息，根据上边提到的方法进行有效处理。

前边几个小节，我们在谈论各种缓存隐患时，反复的强调做好监控的主要性。
这里笔者单独抽出一个小节来总结一下在平时的缓存系统业务场景中，我们该当监控哪些性能指标，有哪些命令能够帮助我们剖析问题，这些方法和技能对付担保我们的系统安全是非常有用的。

对付性能指标监控，笔者这里列出五大类，分别以表格的形式呈现。

Name

Description

latency

Redis相应一个要求的韶光

instantaneous_ops_per_sec

均匀每秒处理要求总数

hit rate(calculated)

缓存命中率（打算出来的）

Name

Description

use_memory

已利用内存

mem_fragmentation_ratio

内存碎片率

evicted_keys

由于最大内存限定移除key的数量

blocked_clients

由于BLPOP、BRPOP or BLPUSH、BRPUSH而被受壅塞的客户端

Name

Description

connected_clients

客户端连接数

connected_slaves

Slave数量

master_last_io_seconds_ago

最近一次主从交互之后的秒数

key_space

数据库中key值总数

Name

Description

rdb_last_save_time

末了一次持久化保存到数据库的韶光戳

rdb_change_since_last_save

自末了一次持久化以来数据库的变动次数

Name

Description

rejected_connections

由于达到maxclient限定而被谢绝的连接数

keyspace_misses

key值查找失落败(没有命中)次数

master_link_down_since_seconds

主从断开的持续韶光(以秒为单位)

以上所列举的都是做事中比较主要的指标，监控redis的这些指标有一些开源的工具，例如：Cloud Insight Redis、Prometheus、Redis-stat、Redis-faina。
但是这些工具在我们比较定制化的业务中，每每不能起到太大效果，每每企业会针对自己的业务开拓自己的监控做事。

Redis供应了一些命令也能帮助我们排查问题。
比如showlog、monitor；此外redis还供应了benchmark指令，通过利用它我们可以得到redis的吞吐量、缓存命中率这些性能指标数据。

这篇文章断断续续的整理了半个月，笔者参考了大量的资料才提炼出了以上内容。
文章中很多地方确实不足深入，也有一些空洞的理论，加上笔者本身事情履历不是很丰富，关于mysql、redis和php，很多底层的知识也没有研究到位，文章中难免有表达不恰当和缺点之处，希望读者查找出往后一定在留言区进行示正。

回过分来看这篇文章，笔者在这里大谈“缓存”确实有点大言不惭，但是都是我的心血，也就当是我的一篇学习条记了。

涉及到“缓存”干系的系统设计和运用绝不仅仅是我提到的这些，比如：缓存数据构造的选择和压缩、多级缓存之间的数据同步等等，这些都没有谈到，如果将来有机会，希望能深入的学习一下这些知识，再对文章做一些补充。

原文链接：https://juejin.cn/post/6844904136207499277