xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-09-30 23:26:43 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
d9c5ffd627
learn.lianglianglee.com/专栏/消息队列高手课/16 缓存策略：如何使用缓存来减少磁盘IO？.md.html
周伟 0f006e4e9b add
2022-05-11 18:57:05 +08:00

975 lines
32 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
<link rel="icon" href="/static/favicon.png">
<title>16 缓存策略：如何使用缓存来减少磁盘IO？.md.html</title>
<!-- Spectre.css framework -->
<link rel="stylesheet" href="/static/index.css">
<!-- theme css & js -->
<meta name="generator" content="Hexo 4.2.0">
</head>
<body>
<div class="book-container">
<div class="book-sidebar">
<div class="book-brand">
<a href="/">
<img src="/static/favicon.png">
<span>技术文章摘抄</span>
</a>
</div>
<div class="book-menu uncollapsible">
<ul class="uncollapsible">
<li><a href="/" class="current-tab">首页</a></li>
</ul>
<ul class="uncollapsible">
<li><a href="../">上一级</a></li>
</ul>
<ul class="uncollapsible">
<li>
<a href="/专栏/消息队列高手课/00 开篇词 优秀的程序员，你的技术栈中不能只有“增删改查”.md.html">00 开篇词 优秀的程序员，你的技术栈中不能只有“增删改查”.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/00 预习 怎样更好地学习这门课？.md.html">00 预习 怎样更好地学习这门课？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/01 为什么需要消息队列？.md.html">01 为什么需要消息队列？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/02 该如何选择消息队列？.md.html">02 该如何选择消息队列？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/03 消息模型：主题和队列有什么区别？.md.html">03 消息模型：主题和队列有什么区别？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/04 如何利用事务消息实现分布式事务？.md.html">04 如何利用事务消息实现分布式事务？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/05 如何确保消息不会丢失.md.html">05 如何确保消息不会丢失.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/06 如何处理消费过程中的重复消息？.md.html">06 如何处理消费过程中的重复消息？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/07 消息积压了该如何处理？.md.html">07 消息积压了该如何处理？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/08 答疑解惑（一） 网关如何接收服务端的秒杀结果？.md.html">08 答疑解惑（一） 网关如何接收服务端的秒杀结果？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/09 学习开源代码该如何入手？.md.html">09 学习开源代码该如何入手？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/10 如何使用异步设计提升系统性能？.md.html">10 如何使用异步设计提升系统性能？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/11 如何实现高性能的异步网络传输？.md.html">11 如何实现高性能的异步网络传输？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/12 序列化与反序列化：如何通过网络传输结构化的数据？.md.html">12 序列化与反序列化：如何通过网络传输结构化的数据？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/13 传输协议：应用程序之间对话的语言.md.html">13 传输协议：应用程序之间对话的语言.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/14 内存管理：如何避免内存溢出和频繁的垃圾回收？.md.html">14 内存管理：如何避免内存溢出和频繁的垃圾回收？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/15 Kafka如何实现高性能IO？.md.html">15 Kafka如何实现高性能IO？.md.html</a>
</li>
<li>
<a class="current-tab" href="/专栏/消息队列高手课/16 缓存策略：如何使用缓存来减少磁盘IO？.md.html">16 缓存策略：如何使用缓存来减少磁盘IO？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/17 如何正确使用锁保护共享数据，协调异步线程？.md.html">17 如何正确使用锁保护共享数据，协调异步线程？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/18 如何用硬件同步原语（CAS）替代锁？.md.html">18 如何用硬件同步原语（CAS）替代锁？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/19 数据压缩：时间换空间的游戏.md.html">19 数据压缩：时间换空间的游戏.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/20 RocketMQ Producer源码分析：消息生产的实现过程.md.html">20 RocketMQ Producer源码分析：消息生产的实现过程.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/21 Kafka Consumer源码分析：消息消费的实现过程.md.html">21 Kafka Consumer源码分析：消息消费的实现过程.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/22 Kafka和RocketMQ的消息复制实现的差异点在哪？.md.html">22 Kafka和RocketMQ的消息复制实现的差异点在哪？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/23 RocketMQ客户端如何在集群中找到正确的节点？.md.html">23 RocketMQ客户端如何在集群中找到正确的节点？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/24 Kafka的协调服务ZooKeeper：实现分布式系统的“瑞士军刀”.md.html">24 Kafka的协调服务ZooKeeper：实现分布式系统的“瑞士军刀”.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/25 RocketMQ与Kafka中如何实现事务？.md.html">25 RocketMQ与Kafka中如何实现事务？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/26 MQTT协议：如何支持海量的在线IoT设备.md.html">26 MQTT协议：如何支持海量的在线IoT设备.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/27 Pulsar的存储计算分离设计：全新的消息队列设计思路.md.html">27 Pulsar的存储计算分离设计：全新的消息队列设计思路.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/28 答疑解惑（二）：我的100元哪儿去了？.md.html">28 答疑解惑（二）：我的100元哪儿去了？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/29 流计算与消息（一）：通过Flink理解流计算的原理.md.html">29 流计算与消息（一）：通过Flink理解流计算的原理.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/30 流计算与消息（二）：在流计算中使用Kafka链接计算任务.md.html">30 流计算与消息（二）：在流计算中使用Kafka链接计算任务.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/31 动手实现一个简单的RPC框架（一）：原理和程序的结构.md.html">31 动手实现一个简单的RPC框架（一）：原理和程序的结构.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/32 动手实现一个简单的RPC框架（二）：通信与序列化.md.html">32 动手实现一个简单的RPC框架（二）：通信与序列化.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/33 动手实现一个简单的RPC框架（三）：客户端.md.html">33 动手实现一个简单的RPC框架（三）：客户端.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/34 动手实现一个简单的RPC框架（四）：服务端.md.html">34 动手实现一个简单的RPC框架（四）：服务端.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/35 答疑解惑（三）：主流消息队列都是如何存储消息的？.md.html">35 答疑解惑（三）：主流消息队列都是如何存储消息的？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/加餐 JMQ的Broker是如何异步处理消息的？.md.html">加餐 JMQ的Broker是如何异步处理消息的？.md.html</a>
</li>
<li>
<a href="/专栏/消息队列高手课/结束语 程序员如何构建知识体系？.md.html">结束语 程序员如何构建知识体系？.md.html</a>
</li>
</ul>
</div>
</div>
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
<div class="sidebar-toggle-inner"></div>
</div>
<script>
function add_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.add('show')
}
function remove_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.remove('show')
}
function sidebar_toggle() {
let sidebar_toggle = document.querySelector('.sidebar-toggle')
let sidebar = document.querySelector('.book-sidebar')
let content = document.querySelector('.off-canvas-content')
if (sidebar_toggle.classList.contains('extend')) { // show
sidebar_toggle.classList.remove('extend')
sidebar.classList.remove('hide')
content.classList.remove('extend')
} else { // hide
sidebar_toggle.classList.add('extend')
sidebar.classList.add('hide')
content.classList.add('extend')
}
}
function open_sidebar() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.add('show')
overlay.classList.add('show')
}
function hide_canvas() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.remove('show')
overlay.classList.remove('show')
}
</script>
<div class="off-canvas-content">
<div class="columns">
<div class="column col-12 col-lg-12">
<div class="book-navbar">
<!-- For Responsive Layout -->
<header class="navbar">
<section class="navbar-section">
<a onclick="open_sidebar()">
<i class="icon icon-menu"></i>
</a>
</section>
</header>
</div>
<div class="book-content" style="max-width: 960px; margin: 0 auto;
overflow-x: auto;
overflow-y: hidden;">
<div class="book-post">
<p id="tip" align="center"></p>
<div><h1>16 缓存策略：如何使用缓存来减少磁盘IO？</h1>
<p>你好，我是李玥。这节课，我们一起来聊一聊缓存策略。</p>
<p>现代的消息队列，都使用磁盘文件来存储消息。因为磁盘是一个持久化的存储，即使服务器掉电也不会丢失数据。绝大多数用于生产系统的服务器，都会使用多块儿磁盘组成磁盘阵列，这样不仅服务器掉电不会丢失数据，即使其中的一块儿磁盘发生故障，也可以把数据从其他磁盘中恢复出来。</p>
<p>使用磁盘的另外一个原因是，磁盘很便宜，这样我们就可以用比较低的成本，来存储海量的消息。所以，不仅仅是消息队列，几乎所有的存储系统的数据，都需要保存到磁盘上。</p>
<p>但是，磁盘它有一个致命的问题，就是读写速度很慢。它有多慢呢？一般来说 SSD（固态硬盘）每秒钟可以读写几千次，如果说我们的程序在处理业务请求的时候直接来读写磁盘，假设处理每次请求需要读写 3～5 次，即使每次请求的数据量不大，你的程序最多每秒也就能处理 1000 次左右的请求。</p>
<p>而内存的随机读写速度是磁盘的 10 万倍！所以，<strong>使用内存作为缓存来加速应用程序的访问速度，是几乎所有高性能系统都会采用的方法。</strong></p>
<p>缓存的思想很简单，就是把低速存储的数据，复制一份副本放到高速的存储中，用来加速数据的访问。缓存使用起来也非常简单，很多同学在做一些业务系统的时候，在一些执行比较慢的方法上加上一个 @Cacheable 的注解，就可以使用缓存来提升它的访问性能了。</p>
<p>但是，你是否考虑过，采用 @Cacheable 注解的方式缓存的命中率如何？或者说怎样才能提高缓存的命中率？缓存是否总能返回最新的数据？如果缓存返回了过期的数据该怎么办？接下来，我们一起来通过学习设计、使用缓存的最佳实践，找到这些问题的答案。</p>
<h2>选择只读缓存还是读写缓存？</h2>
<p>使用缓存，首先你就会面临选择读缓存还是读写缓存的问题。他们唯一的区别就是，在更新数据的时候，是否经过缓存。</p>
<p>我们之前的课中讲到 Kafka 使用的 PageCache，它就是一个非常典型的读写缓存。操作系统会利用系统空闲的物理内存来给文件读写做缓存，这个缓存叫做 PageCache。应用程序在写文件的时候，操作系统会先把数据写入到 PageCache 中，数据在成功写到 PageCache 之后，对于用户代码来说，写入就结束了。</p>
<p>然后，操作系统再异步地把数据更新到磁盘的文件中。应用程序在读文件的时候，操作系统也是先尝试从 PageCache 中寻找数据，如果找到就直接返回数据，找不到会触发一个缺页中断，然后操作系统把数据从文件读取到 PageCache 中，再返回给应用程序。</p>
<p>我们可以看到，在数据写到 PageCache 中后，它并不是同时就写到磁盘上了，这中间是有一个延迟的。操作系统可以保证，即使是应用程序意外退出了，操作系统也会把这部分数据同步到磁盘上。但是，如果服务器突然掉电了，这部分数据就丢失了。</p>
<p>你需要知道，**读写缓存的这种设计，它天然就是不可靠的，是一种牺牲数据一致性换取性能的设计。**当然，应用程序可以调用 sync 等系统调用，强制操作系统立即把缓存数据同步到磁盘文件中去，但是这个同步的过程是很慢的，也就失去了缓存的意义。</p>
<p>另外，写缓存的实现是非常复杂的。应用程序不停地更新 PageCache 中的数据，操作系统需要记录哪些数据有变化，同时还要在另外一个线程中，把缓存中变化的数据更新到磁盘文件中。在提供并发读写的同时来异步更新数据，这个过程中要保证数据的一致性，并且有非常好的性能，实现这些真不是一件容易的事儿。</p>
<p>所以说，一般情况下，不推荐你来使用读写缓存。</p>
<p>那为什么 Kafka 可以使用 PageCache 来提升它的性能呢？这是由消息队列的一些特点决定的。</p>
<p>首先，消息队列它的读写比例大致是 1：1，因为，大部分我们用消息队列都是一收一发这样使用。这种读写比例，只读缓存既无法给写加速，读的加速效果也有限，并不能提升多少性能。</p>
<p>另外，Kafka 它并不是只靠磁盘来保证数据的可靠性，它更依赖的是，在不同节点上的多副本来解决数据可靠性问题，这样即使某个服务器掉电丢失一部分文件内容，它也可以从其他节点上找到正确的数据，不会丢消息。</p>
<p>而且，PageCache 这个读写缓存是操作系统实现的，Kafka 只要按照正确的姿势来使用就好了，不涉及到实现复杂度的问题。所以，Kafka 其实在设计上，充分利用了 PageCache 这种读写缓存的优势，并且规避了 PageCache 的一些劣势，达到了一个非常好的效果。</p>
<p>和 Kafka 一样，大部分其他的消息队列，同样也会采用读写缓存来加速消息写入的过程，只是实现的方式都不一样。</p>
<p>不同于消息队列，我们开发的大部分业务类应用程序，读写比都是严重不均衡的，一般读的数据的频次会都会远高于写数据的频次。从经验值来看，读次数一般都是写次数的几倍到几十倍。这种情况下，使用只读缓存来加速系统才是非常明智的选择。</p>
<p>接下来，我们一起来看一下，在构建一个只读缓存时，应该侧重考虑哪些问题。</p>
<h2>保持缓存数据新鲜</h2>
<p>对于只读缓存来说，缓存中的数据来源只有一个途径，就是从磁盘上来。当数据需要更新的时候，磁盘中的数据和缓存中的副本都需要进行更新。我们知道，在分布式系统中，除非是使用事务或者一些分布式一致性算法来保证数据一致性，否则，由于节点宕机、网络传输故障等情况的存在，我们是无法保证缓存中的数据和磁盘中的数据是完全一致的。</p>
<p>如果出现数据不一致的情况，数据一定是以磁盘上的那份拷贝为准。我们需要解决的问题就是，尽量让缓存中的数据与磁盘上的数据保持同步。</p>
<p>那选择什么时候来更新缓存中的数据呢？比较自然的想法是，我在更新磁盘中数据的同时，更新一下缓存中的数据不就可以了？这个想法是没有任何问题的，缓存中的数据会一直保持最新。但是，在并发的环境中，实现起来还是不太容易的。</p>
<p>你是选择同步还是异步来更新缓存呢？如果是同步更新，更新磁盘成功了，但是更新缓存失败了，你是不是要反复重试来保证更新成功？如果多次重试都失败，那这次更新是算成功还是失败呢？如果是异步更新缓存，怎么保证更新的时序？</p>
<p>比如，我先把一个文件中的某个数据设置成 0，然后又设为 1，这个时候文件中的数据肯定是 1，但是缓存中的数据可不一定就是 1 了。因为把缓存中的数据更新为 0，和更新为 1 是两个并发的异步操作，不一定谁会先执行。</p>
<p>这些问题都会导致缓存的数据和磁盘中的数据不一致，而且，在下次更新这条数据之前，这个不一致的问题它是一直存在的。当然，这些问题也不是不能解决的，比如，你可以使用分布式事务来解决，只是付出的性能、实现复杂度等代价比较大。</p>
<p>另外一种比较简单的方法就是，定时将磁盘上的数据同步到缓存中。一般的情况下，每次同步时直接全量更新就可以了，因为是在异步的线程中更新数据，同步的速度即使慢一些也不是什么大问题。如果缓存的数据太大，更新速度慢到无法接受，也可以选择增量更新，每次只更新从上次缓存同步至今这段时间内变化的数据，代价是实现起来会稍微有些复杂。</p>
<p>如果说，某次同步过程中发生了错误，等到下一个同步周期也会自动把数据纠正过来。这种定时同步缓存的方法，缺点是缓存更新不那么及时，优点是实现起来非常简单，鲁棒性非常好。</p>
<p>还有一种更简单的方法，我们从来不去更新缓存中的数据，而是给缓存中的每条数据设置一个比较短的过期时间，数据过期以后即使它还存在缓存中，我们也认为它不再有效，需要从磁盘上再次加载这条数据，这样就变相地实现了数据更新。</p>
<p>很多情况下，缓存的数据更新不那么及时，我们的系统也是能够接受的。比如说，你刚刚发了一封邮件，收件人过了一会儿才收到。或者说，你改了自己的微信头像，在一段时间内，你的好友看到的你还是旧的头像，这些都是可以接受的。这种对数据一致性没有那么敏感的场景下，你一定要选择后面两种方法。</p>
<p>而像交易类的系统，它对数据的一致性非常敏感。比如，你给别人转了一笔钱，别人查询自己余额却没有变化，这种情况肯定是无法接受的。对于这样的系统，一般来说，都不使用缓存或者使用我们提到的第一种方法，在更新数据的时候同时来更新缓存。</p>
<h2>缓存置换策略</h2>
<p>在使用缓存的过程中，除了要考虑数据一致性的问题，你还需要关注的另一个重要的问题是，在内存有限的情况下，要优先缓存哪些数据，让缓存的命中率最高。</p>
<p>当应用程序要访问某些数据的时候，如果这些数据在缓存中，那直接访问缓存中的数据就可以了，这次访问的速度是很快的，这种情况我们称为一次缓存命中；如果这些数据不在缓存中，那只能去磁盘中访问数据，就会比较慢。这种情况我们称为“缓存穿透”。显然，缓存的命中率越高，应用程序的总体性能就越好。</p>
<p>那用什么样的策略来选择缓存的数据，能使得缓存的命中率尽量高一些呢？</p>
<p>如果你的系统是那种可以预测未来访问哪些数据的系统，比如说，有的系统它会定期做数据同步，每次同步的数据范围都是一样的，像这样的系统，缓存策略很简单，就是你要访问什么数据，就缓存什么数据，甚至可以做到百分之百的命中。</p>
<p>但是，大部分系统，它并没有办法准确地预测未来会有哪些数据会被访问到，所以只能使用一些策略来尽可能地提高缓存命中率。</p>
<p>一般来说，我们都会在数据首次被访问的时候，顺便把这条数据放到缓存中。随着访问的数据越来越多，总有把缓存占满的时刻，这个时候就需要把缓存中的一些数据删除掉，以便存放新的数据，这个过程称为缓存置换。</p>
<p>到这里，问题就变成了：当缓存满了的时候，删除哪些数据，才能会使缓存的命中率更高一些，也就是采用什么置换策略的问题。</p>
<p>**命中率最高的置换策略，一定是根据你的业务逻辑，定制化的策略。**比如，你如果知道某些数据已经删除了，永远不会再被访问到，那优先置换这些数据肯定是没问题的。再比如，你的系统是一个有会话的系统，你知道现在哪些用户是在线的，哪些用户已经离线，那优先置换那些已经离线用户的数据，尽量保留在线用户的数据也是一个非常好的策略。</p>
<p>另外一个选择，就是使用通用的置换算法。一个最经典也是最实用的算法就是 LRU 算法，也叫最近最少使用算法。这个算法它的思想是，最近刚刚被访问的数据，它在将来被访问的可能性也很大，而很久都没被访问过的数据，未来再被访问的几率也不大。</p>
<p>基于这个思想，**LRU 的算法原理非常简单，它总是把最长时间未被访问的数据置换出去。**你别看这个 LRU 算法这么简单，它的效果是非常非常好的。</p>
<p>Kafka 使用的 PageCache，是由 Linux 内核实现的，它的置换算法的就是一种 LRU 的变种算法
：LRU 2Q。我在设计 JMQ 的缓存策略时，也是采用一种改进的 LRU 算法。LRU 淘汰最近最少使用的页，JMQ 根据消息这种流数据存储的特点，在淘汰时增加了一个考量维度：页面位置与尾部的距离。因为越是靠近尾部的数据，被访问的概率越大。</p>
<p>这样综合考虑下的淘汰算法，不仅命中率更高，还能有效地避免“挖坟”问题：例如某个客户端正在从很旧的位置开始向后读取一批历史数据，内存中的缓存很快都会被替换成这些历史数据，相当于大部分缓存资源都被消耗掉了，这样会导致其他客户端的访问命中率下降。加入位置权重后，比较旧的页面会很快被淘汰掉，减少“挖坟”对系统的影响。</p>
<h2>小结</h2>
<p>这节课我们主要聊了一下，如何使用缓存来加速你的系统，减少磁盘 IO。按照读写性质，可以分为读写缓存和只读缓存，读写缓存实现起来非常复杂，并且只在消息队列等少数情况下适用。只读缓存适用的范围更广，实现起来也更简单。</p>
<p>在实现只读缓存的时候，你需要考虑的第一个问题是如何来更新缓存。这里面有三种方法，第一种是在更新数据的同时去更新缓存，第二种是定期来更新全部缓存，第三种是给缓存中的每个数据设置一个有效期，让它自然过期以达到更新的目的。这三种方法在更新的及时性上和实现的复杂度这两方面，都是依次递减的，你可以按需选择。</p>
<p>对于缓存的置换策略，最优的策略一定是你根据业务来设计的定制化的置换策略，当然你也可以考虑 LRU 这样通用的缓存置换算法。</p>
<h2>思考题</h2>
<p>课后来写点儿代码吧，实现一个采用 LRU 置换算法的缓存。</p>
<pre><code>/**
* KV 存储抽象
*/
public interface Storage&lt;K,V&gt; {
/**
* 根据提供的 key 来访问数据
* @param key 数据 Key
* @return 数据值
*/
V get(K key);
}
/**
* LRU 缓存。你需要继承这个抽象类来实现 LRU 缓存。
* @param &lt;K&gt; 数据 Key
* @param &lt;V&gt; 数据值
*/
public abstract class LruCache&lt;K, V&gt; implements Storage&lt;K,V&gt;{
// 缓存容量
protected final int capacity;
// 低速存储，所有的数据都可以从这里读到
protected final Storage&lt;K,V&gt; lowSpeedStorage;
public LruCache(int capacity, Storage&lt;K,V&gt; lowSpeedStorage) {
this.capacity = capacity;
this.lowSpeedStorage = lowSpeedStorage;
}
}
</code></pre>
<p>你需要继承 LruCache 这个抽象类，实现你自己的 LRU 缓存。lowSpeedStorage 是提供给你可用的低速存储，你不需要实现它。</p>
<p>欢迎你把代码上传到 GitHub 上，然后在评论区给出访问链接。大家来比一下，谁的算法性能更好。如果你有任何问题，也可以在评论区留言与我交流。</p>
</div>
</div>
<div>
<div style="float: left">
<a href="/专栏/消息队列高手课/15 Kafka如何实现高性能IO？.md.html">上一页</a>
</div>
<div style="float: right">
<a href="/专栏/消息队列高手课/17 如何正确使用锁保护共享数据，协调异步线程？.md.html">下一页</a>
</div>
</div>
</div>
</div>
</div>
</div>
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
</div>
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"709979683afa3cfa","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
</body>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('js', new Date());
gtag('config', 'G-NPSEEVD756');
var path = window.location.pathname
var cookie = getCookie("lastPath");
console.log(path)
if (path.replace("/", "") === "") {
if (cookie.replace("/", "") !== "") {
console.log(cookie)
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
}
} else {
setCookie("lastPath", path)
}
function setCookie(cname, cvalue) {
var d = new Date();
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
var expires = "expires=" + d.toGMTString();
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
}
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i].trim();
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
}
return "";
}
</script>
</html>
Reference in New Issue View Git Blame Copy Permalink