聊聊缓存

在设计高并发、高性能的系统架构时，缓存是绕不开的一个话题，之所以用缓存，是因为不同的存储介质的访问速度存在巨大差异，例如SSD（固态硬盘）每秒钟可以读写几千次，而内存的随机读写速度是SSD的10万倍。使用内存作为缓存来加速应用程序的访问速度，是几乎所有高性能系统都会采用的方法。

缓存的思想很简单：把低速存储的数据，复制一份放到高速存储中，用来加速数据访问。

缓存的分类

缓存主要分为两大类：

• 读写缓存
• 只读缓存

这两类缓存的区别在于更新数据的时候是否经过缓存。

读写缓存

Kafka使用的PageCache就是典型的读写缓存。操作系统会利用系统空闲的物理内存来给文件读写做缓存，应用程序在写文件的时候，操作系统会先把数据写入到PageCache中，数据在成功写到PageCache之后，对于用户代码来说，写入就结束嘞。操作系统再通过异步的方式将数据更新到磁盘的文件中。应用程序在读文件的时候，操作系统也是先尝试从PageCache中寻找数据，如果找到就直接返回数据，找不到就会触发一个缺页中断，然后操作系统把数据从文件读取到PageCache中，再返回给应用程序。

我么可以看到写数据时，并不是同时将数据写到PageCache和磁盘上，这中间会有一个延迟。操作系统可以保证，即使是应用程序意外退出了，操作系统也会把这部分数据同步到磁盘上，但是如果服务器突然掉电了，这部分数据就会丢失。

读写缓存这种设计，天然就不是可靠的，这是一种牺牲数据一致性换取性能的设计。

写缓存的实现是非常复杂的，应用恒旭不停地更新PageCache中的数据，操作系统需要记录哪些数据有变化，同时还要在另外一个线程中，把缓存中变化的数据更新到磁盘中。在提供并发读写的同时来异步更新数据，这个过程中要保证数据的一致性，并且有非常好的性能，很不容易。

Kafka为什么可以使用PageCache提升性能？

Kafka可以使用PageCache并取得性能提升，有三个原因：

1. 消息队列中数据的读写比例基本是1:1，我们用消息队列发送的大部分数据都是一收一发的。
2. Kafka不是靠磁盘来保证数据的可靠性，它更依赖于不同节点上的多副本来解决数据可靠性问题。
3. PageCache的读写缓存是操作系统实现的，Kafka只需要按照正确的方法来使用就可以了，不会涉及到实现复杂度的问题。

对于不同的使用场景，我们选择缓存的方式也有区别，如果读次数是写次数的几倍到几十倍，那么可以选择只读缓存，如果数据的读写次数基本一致，那么可以选择读写缓存。

只读缓存

对于只读缓存来说，我们需要考虑一个问题：缓存的数据来源于磁盘，那么应该怎么更新缓存中的数据呢？

我们可以有三种方法来更新只读缓存的数据：

1. 数据更新时，同时更新磁盘和缓存，这种方法可能会带来数据不一致的问题，例如我们是选择同步还是异步来更新缓存？如果同步更新，磁盘更新成功了，缓存更新失败嘞，需要反复重试来保证更新成功吗？如果多次重试都失败，那么这次更新算成功还是失败呢？如果是异步更新缓存，怎么保证更新的时序？
2. 定时将磁盘上的数据同步到缓存中，同步时可以采用全量更新，也可以选择增量更新。这种方法的缺点是缓存更新不会很及时，优点是实现起来非常简单。
3. 我们不去更新缓存中的数据，而是给缓存中的每条数据设置一个比较短的过期时间，数据过期以后即使它还在缓存中，我们也会认为它不再有效，需要从磁盘中再次加载，这样就实现了数据更新。

缓存置换策略

当应用程序要访问某些数据时，如果这些数据在缓存中，那么直接访问缓存中的数据就可以了，这种情况我们称为一次缓存命中；如果数据不在缓存中，那只能去磁盘访问数据，我们称为缓存穿透。

一般来说我们都会在数据首次被访问时，把这条数据放到缓存中，随着访问的数据越来越多，缓存空间会被占完，这时就需要把缓存中的一些数据删掉，以便存放新的数据，这个过程称为缓存置换。

我们有两种缓存置换思路：

1. 根据业务逻辑，定制化缓存置换策略。例如，当我们知道某些数据已经被删了，永远不会再访问到，那么优先置换这些数据是没有问题的。
2. 使用通用的置换算法，例如LRU算法， 也称为最近最少使用算法，它的思想是最近刚刚被访问到的数据，它在将来被访问的可能性也很大，而很久都没有被访问过的数据，未来再被访问的几率也不大。