网站建设方案书 百度文库,网站做产品的审核吗,宁波seo行业公司推荐,商城网站开发解决方案现代的消息队列#xff0c;都使用磁盘文件来存储消息。因为磁盘是一个持久化的存储#xff0c;即使服务器掉电也不会丢失数据。绝大多数用于生产系统的服务器#xff0c;都会使用多块儿磁盘组成磁盘阵列#xff0c;这样不仅服务器掉电不会丢失数据#xff0c;即使其中的一… 现代的消息队列都使用磁盘文件来存储消息。因为磁盘是一个持久化的存储即使服务器掉电也不会丢失数据。绝大多数用于生产系统的服务器都会使用多块儿磁盘组成磁盘阵列这样不仅服务器掉电不会丢失数据即使其中的一块儿磁盘发生故障也可以把数据从其他磁盘中恢复出来。使用磁盘的另外一个原因是磁盘很便宜这样我们就可以用比较低的成本来存储海量的消息。所以不仅仅是消息队列几乎所有的存储系统的数据都需要保存到磁盘上。但是磁盘它有一个致命的问题就是读写速度很慢。它有多慢呢一般来说 SSD(固态硬盘)每秒钟可以读写几千次如果说我们的程序在处理业务请求的时候直接来读写磁盘假设处理每次请求需要读写 35 次即使每次请求的数据量不大你的程序最多每秒也就能处理 1000 次左右的请求。而内存的随机读写速度是磁盘的 10 万倍所以使用内存作为缓存来加速应用程序的访问速度是几乎所有高性能系统都会采用的方法。缓存的思想很简单就是把低速存储的数据复制一份副本放到高速的存储中用来加速数据的访问。缓存使用起来也非常简单很多同学在做一些业务系统的时候在一些执行比较慢的方法上加上一个 Cacheable 的注解就可以使用缓存来提升它的访问性能了。但是你是否考虑过采用 Cacheable 注解的方式缓存的命中率如何或者说怎样才能提高缓存的命中率缓存是否总能返回最新的数据如果缓存返回了过期的数据该怎么办接下来我们一起来通过学习设计、使用缓存的最佳实践找到这些问题的答案。选择只读缓存还是读写缓存使用缓存首先你就会面临选择读缓存还是读写缓存的问题。他们唯一的区别就是在更新数据的时候是否经过缓存。我们之前的课中讲到 Kafka 使用的 PageCache它就是一个非常典型的读写缓存。操作系统会利用系统空闲的物理内存来给文件读写做缓存这个缓存叫做 PageCache。应用程序在写文件的时候操作系统会先把数据写入到 PageCache 中数据在成功写到 PageCache 之后对于用户代码来说写入就结束了。然后操作系统再异步地把数据更新到磁盘的文件中。应用程序在读文件的时候操作系统也是先尝试从 PageCache 中寻找数据如果找到就直接返回数据找不到会触发一个缺页中断然后操作系统把数据从文件读取到 PageCache 中再返回给应用程序。我们可以看到在数据写到 PageCache 中后它并不是同时就写到磁盘上了这中间是有一个延迟的。操作系统可以保证即使是应用程序意外退出了操作系统也会把这部分数据同步到磁盘上。但是如果服务器突然掉电了这部分数据就丢失了。你需要知道读写缓存的这种设计它天然就是不可靠的是一种牺牲数据一致性换取性能的设计。当然应用程序可以调用 sync 等系统调用强制操作系统立即把缓存数据同步到磁盘文件中去但是这个同步的过程是很慢的也就失去了缓存的意义。另外写缓存的实现是非常复杂的。应用程序不停地更新 PageCache 中的数据操作系统需要记录哪些数据有变化同时还要在另外一个线程中把缓存中变化的数据更新到磁盘文件中。在提供并发读写的同时来异步更新数据这个过程中要保证数据的一致性并且有非常好的性能实现这些真不是一件容易的事儿。所以说一般情况下不推荐你来使用读写缓存。那为什么 Kafka 可以使用 PageCache 来提升它的性能呢这是由消息队列的一些特点决定的。首先消息队列它的读写比例大致是 11因为大部分我们用消息队列都是一收一发这样使用。这种读写比例只读缓存既无法给写加速读的加速效果也有限并不能提升多少性能。另外Kafka 它并不是只靠磁盘来保证数据的可靠性它更依赖的是在不同节点上的多副本来解决数据可靠性问题这样即使某个服务器掉电丢失一部分文件内容它也可以从其他节点上找到正确的数据不会丢消息。而且PageCache 这个读写缓存是操作系统实现的Kafka 只要按照正确的姿势来使用就好了不涉及到实现复杂度的问题。所以Kafka 其实在设计上充分利用了 PageCache 这种读写缓存的优势并且规避了 PageCache 的一些劣势达到了一个非常好的效果。和 Kafka 一样大部分其他的消息队列同样也会采用读写缓存来加速消息写入的过程只是实现的方式都不一样。不同于消息队列我们开发的大部分业务类应用程序读写比都是严重不均衡的一般读的数据的频次会都会远高于写数据的频次。从经验值来看读次数一般都是写次数的几倍到几十倍。这种情况下使用只读缓存来加速系统才是非常明智的选择。接下来我们一起来看一下在构建一个只读缓存时应该侧重考虑哪些问题。保持缓存数据新鲜对于只读缓存来说缓存中的数据来源只有一个途径就是从磁盘上来。当数据需要更新的时候磁盘中的数据和缓存中的副本都需要进行更新。我们知道在分布式系统中除非是使用事务或者一些分布式一致性算法来保证数据一致性否则由于节点宕机、网络传输故障等情况的存在我们是无法保证缓存中的数据和磁盘中的数据是完全一致的。如果出现数据不一致的情况数据一定是以磁盘上的那份拷贝为准。我们需要解决的问题就是尽量让缓存中的数据与磁盘上的数据保持同步。那选择什么时候来更新缓存中的数据呢比较自然的想法是我在更新磁盘中数据的同时更新一下缓存中的数据不就可以了这个想法是没有任何问题的缓存中的数据会一直保持最新。但是在并发的环境中实现起来还是不太容易的。你是选择同步还是异步来更新缓存呢如果是同步更新更新磁盘成功了但是更新缓存失败了你是不是要反复重试来保证更新成功如果多次重试都失败那这次更新是算成功还是失败呢如果是异步更新缓存怎么保证更新的时序比如我先把一个文件中的某个数据设置成 0然后又设为 1这个时候文件中的数据肯定是 1但是缓存中的数据可不一定就是 1 了。因为把缓存中的数据更新为 0和更新为 1 是两个并发的异步操作不一定谁会先执行。这些问题都会导致缓存的数据和磁盘中的数据不一致而且在下次更新这条数据之前这个不一致的问题它是一直存在的。当然这些问题也不是不能解决的比如你可以使用分布式事务来解决只是付出的性能、实现复杂度等代价比较大。另外一种比较简单的方法就是定时将磁盘上的数据同步到缓存中。一般的情况下每次同步时直接全量更新就可以了因为是在异步的线程中更新数据同步的速度即使慢一些也不是什么大问题。如果缓存的数据太大更新速度慢到无法接受也可以选择增量更新每次只更新从上次缓存同步至今这段时间内变化的数据代价是实现起来会稍微有些复杂。如果说某次同步过程中发生了错误等到下一个同步周期也会自动把数据纠正过来。这种定时同步缓存的方法缺点是缓存更新不那么及时优点是实现起来非常简单鲁棒性非常好。还有一种更简单的方法我们从来不去更新缓存中的数据而是给缓存中的每条数据设置一个比较短的过期时间数据过期以后即使它还存在缓存中我们也认为它不再有效需要从磁盘上再次加载这条数据这样就变相地实现了数据更新。很多情况下缓存的数据更新不那么及时我们的系统也是能够接受的。比如说你刚刚发了一封邮件收件人过了一会儿才收到。或者说你改了自己的微信头像在一段时间内你的好友看到的你还是旧的头像这些都是可以接受的。这种对数据一致性没有那么敏感的场景下你一定要选择后面两种方法。而像交易类的系统它对数据的一致性非常敏感。比如你给别人转了一笔钱别人查询自己余额却没有变化这种情况肯定是无法接受的。对于这样的系统一般来说都不使用缓存或者使用我们提到的第一种方法在更新数据的时候同时来更新缓存。缓存置换策略在使用缓存的过程中除了要考虑数据一致性的问题你还需要关注的另一个重要的问题是在内存有限的情况下要优先缓存哪些数据让缓存的命中率最高。当应用程序要访问某些数据的时候如果这些数据在缓存中那直接访问缓存中的数据就可以了这次访问的速度是很快的这种情况我们称为一次缓存命中如果这些数据不在缓存中那只能去磁盘中访问数据就会比较慢。这种情况我们称为“缓存穿透”。显然缓存的命中率越高应用程序的总体性能就越好。那用什么样的策略来选择缓存的数据能使得缓存的命中率尽量高一些呢如果你的系统是那种可以预测未来访问哪些数据的系统比如说有的系统它会定期做数据同步每次同步的数据范围都是一样的像这样的系统缓存策略很简单就是你要访问什么数据就缓存什么数据甚至可以做到百分之百的命中。但是大部分系统它并没有办法准确地预测未来会有哪些数据会被访问到所以只能使用一些策略来尽可能地提高缓存命中率。一般来说我们都会在数据首次被访问的时候顺便把这条数据放到缓存中。随着访问的数据越来越多总有把缓存占满的时刻这个时候就需要把缓存中的一些数据删除掉以便存放新的数据这个过程称为缓存置换。到这里问题就变成了当缓存满了的时候删除哪些数据才能会使缓存的命中率更高一些也就是采用什么置换策略的问题。命中率最高的置换策略一定是根据你的业务逻辑定制化的策略。比如你如果知道某些数据已经删除了永远不会再被访问到那优先置换这些数据肯定是没问题的。再比如你的系统是一个有会话的系统你知道现在哪些用户是在线的哪些用户已经离线那优先置换那些已经离线用户的数据尽量保留在线用户的数据也是一个非常好的策略。另外一个选择就是使用通用的置换算法。一个最经典也是最实用的算法就是 LRU 算法也叫最近最少使用算法。这个算法它的思想是最近刚刚被访问的数据它在将来被访问的可能性也很大而很久都没被访问过的数据未来再被访问的几率也不大。基于这个思想LRU 的算法原理非常简单它总是把最长时间未被访问的数据置换出去。你别看这个 LRU 算法这么简单它的效果是非常非常好的。Kafka 使用的 PageCache是由 Linux 内核实现的它的置换算法的就是一种 LRU 的变种算法LRU 2Q。我在设计 JMQ 的缓存策略时也是采用一种改进的 LRU 算法。LRU 淘汰最近最少使用的页JMQ 根据消息这种流数据存储的特点在淘汰时增加了一个考量维度页面位置与尾部的距离。因为越是靠近尾部的数据被访问的概率越大。这样综合考虑下的淘汰算法不仅命中率更高还能有效地避免“挖坟”问题例如某个客户端正在从很旧的位置开始向后读取一批历史数据内存中的缓存很快都会被替换成这些历史数据相当于大部分缓存资源都被消耗掉了这样会导致其他客户端的访问命中率下降。加入位置权重后比较旧的页面会很快被淘汰掉减少“挖坟”对系统的影响。小结这节课我们主要聊了一下如何使用缓存来加速你的系统减少磁盘 IO。按照读写性质可以分为读写缓存和只读缓存读写缓存实现起来非常复杂并且只在消息队列等少数情况下适用。只读缓存适用的范围更广实现起来也更简单。在实现只读缓存的时候你需要考虑的第一个问题是如何来更新缓存。这里面有三种方法第一种是在更新数据的同时去更新缓存第二种是定期来更新全部缓存第三种是给缓存中的每个数据设置一个有效期让它自然过期以达到更新的目的。这三种方法在更新的及时性上和实现的复杂度这两方面都是依次递减的你可以按需选择。对于缓存的置换策略最优的策略一定是你根据业务来设计的定制化的置换策略当然你也可以考虑 LRU 这样通用的缓存置换算法。思考题课后来写点儿代码吧实现一个采用 LRU 置换算法的缓存。/*** KV 存储抽象*/public interface Storage {/*** 根据提供的 key 来访问数据* param key 数据 Key* return 数据值*/V get(K key);}/*** LRU 缓存。你需要继承这个抽象类来实现 LRU 缓存。* param 数据 Key* param 数据值*/public abstract class LruCache implements Storage{// 缓存容量protected final int capacity;// 低速存储所有的数据都可以从这里读到protected final Storage lowSpeedStorage;public LruCache(int capacity, Storage lowSpeedStorage) {this.capacity capacity;this.lowSpeedStorage lowSpeedStorage;}}复制代码你需要继承 LruCache 这个抽象类实现你自己的 LRU 缓存。lowSpeedStorage 是提供给你可用的低速存储你不需要实现它。欢迎你把代码上传到 GitHub 上然后在评论区给出访问链接。大家来比一下谁的算法性能更好。如果你有任何问题也可以在评论区留言与我交流。感谢阅读如果你觉得这篇文章对你有帮助的话也欢迎把它分享给你的朋友。
