redis：作为旁路缓存的redis是怎么使用的

缓存的特性

一个系统中的不同层之间的访问速度不一样，所以我们才需要缓存，这样就可以把一些需要频繁访问的数据放到缓存中，以加快它们的访问速度。

举个例子，计算机系统的存储结构一般是下面这样的：

所以，计算机系统中，默认有两种缓存：

• CPU里面的LLC缓存，用来缓存内存中的数据，避免每次从内存中存取数据
• 内存中的高速页缓存page cache，用来缓存磁盘中的数据，避免每次从磁盘中存取数据

从上面，我们可以看出缓存的第一条特性：在一个层次化的系统中，缓存一定是一个快速子系统，数据存在缓存中时，能避免每次从慢速子系统中存取数据。对应到互联网应用来说，Redis 就是快速子系统，而数据库就是慢速子系统了。

我们再看一下刚才的计算机分层结构。LLC 的大小是 MB 级别，page cache 的大小是 GB级别，而磁盘的大小是 TB 级别。这其实包含了缓存的第二个特征：缓存系统的容量大小总是小于后端慢速系统的，我们不可能把所有数据都放在缓存系统中

所以，缓存和后端数据库之间，一定存在数据写回和再读取的交互过程。简单来说，缓存中的数据需要按一定规则淘汰出去，写回后端系统，而新的数据又要从后端系统中读取进来，写入缓存。

而redis本身就支持按照一定规则淘汰数据，相当于实现了缓存的数据淘汰。这也是 Redis 适合用作缓存的一个重要原因。

那么缓存是怎么处理请求的呢？实际上，业务应用在访问 Redis 缓存中的数据时，数据不一定存在，因# 此，处理的方式也不同。

redis缓存处理请求的两种情况

把redis用作缓存时，我们会把redis部署在数据库的前端，业务应用在访问数据时，会先查询redis中是否保存了想要的数据。此时，根据数据是否在缓存中，会有两种情况：

• 缓存命中：redis中有相应数据，就直接读取 redis，性能非常快。
• 缓存缺失：redis中没有保存相应数据，就会从后端数据库中读取数据，性能就会变慢。而且，一旦发生缓存缺失，为了让后继请求能从缓存中读取到数据，我们需要把缺失的数据写入redis，这个过程叫做缓存更新（缓存更新操作会涉及到保证缓存和数据库之间的数据一致性问题）

也就是说，使用 Redis 缓存时，我们基本有三个操作：

• 应用读取数据时，需要先读取redis
• 发生缓存缺失时，需要从数据库中读取数据
• 发生缓存缺失时，还需要更新缓存

那么，这些操作具体是由谁来做的呢？这和 Redis 缓存的使用方式相关。接下来我们来看看Redis 作为旁路缓存的使用操作方式。

Redis 作为旁路缓存的使用操作

redis是一个独立的系统组件，和业务应用程序是两个软件，当我们部署了redis实例时，它只会被动的等待客户端发送请求，然后再进行处理。所以，如果应用程序想要使用redis缓存，我们就要在程序中增加相应的缓存操作代码。所以，我们把redis称为旁路缓存。也就是说，读取缓存、读取数据库和更新缓存的操作都需要在应用程序中来完成。

这和计算机系统中的LLC和page cache不一样。平时在开发程序时，我们是没有专门在代码中显式地创建 LLC 或 page cache 的实例的，也没有显式调用过它们的 GET 接口。这是因为，我们在构建计算机硬件系统时，已经把LLC和page cache放在了应用程序的数据访问路径上，应用程序访问数据时直接就能用上缓存。

那么，使用 Redis 缓存时，具体来说，我们需要在应用程序中增加三方面的代码：

• 在应用程序需要读取数据时，我们需要在代码中显示调用redis的get操作接口，进行查询
• 如果缓存缺失了，应用程序需要和后端数据库进行连接，从数据库中读取数据
• 当缓存中的数据需要更新时，我们也需要在应用程序中显式地调用 SET 操作接口，把更新的数据写入缓存。

String cacheKey = “productid_11010003”;
String cacheValue = redisCache.get(cacheKey)；
//缓存命中
if ( cacheValue != NULL)
	return cacheValue;
//缓存缺失
else
	cacheValue = getProductFromDB();
	redisCache.put(cacheValue) //缓存更新

所以，Redis 并不适用于那些无法获得源码的应用，例如一些很早之前开发的应用程序，它们的源码已经没有再维护了，或者是第三方供应商开发的应用，没有提供源码，所以，我们就没有办法在这些应用中进行缓存操作。

也就是说，通过在应用程序中加入redis的操作代码，我们可以让应用程序使用redis缓存数据。不过，除了从redis缓存中查询、读取数据之外，应用程序还可能会对数据进行修改，这时，我们既可以在缓存中修改，也可以在后端数据库中修改。该怎么选择呢？

这就涉及到了redis缓存的两种类型：只读缓存和读写缓存。只读缓存能加速读请求，而读写缓存可以同时加速读写请求。而且，读写缓存又有两种数据写回策略，可以让我们根据业务需求，在保证性能和保证数据可靠性之间进行选择。

缓存的类型

按照 Redis 缓存是否接受写请求，我们可以把它分成只读缓存和读写缓存

只读缓存（并不是不修改redis）

当 Redis 用作只读缓存时（复习的时候直接看例子，下面描述太繁琐了）：

• 应用要读取数据的话，会先调用 Redis GET 接口，查询数据是否存在。
• 而所有的数据写请求，会直接发往后端的数据库，在数据库中增删改。
• 对于删改的数据来说，如果 Redis 已经缓存了相应的数据，应用需要把这些缓存的数据删除，Redis中就没有这些数据了。
• 当应用再次读取这些数据时，会发生缓存缺失，应用会把这些数据从数据库中读出来，并写到缓存中。这样一来，这些数据后续再被读取时，就可以直接从缓存中获取了，能起到加速访问的效果。

举个具体的例子：

• 假设业务应用要修改数据 A，此时，数据 A 在 Redis 中也缓存了，那么，应用会先直接在数据库里修改 A，并把 Redis 中的 A 删除。
• 等到应用需要读取数据 A时，会发生缓存缺失，此时，应用从数据库中读取 存中直接读取A，并写入 Redis，以便后续请求从缓存中直接读取

只读缓存直接在数据库中更新数据的好处是，所有最新的数据都在数据库中，而数据库是提供数据可靠性保障的，这些数据不会有丢失风险

读写缓存

• 对于读写缓存来说，除了读请求会发送到缓存进行处理（直接在缓存中查询数据是否存在)，所有的写请求也会发送到缓存，在缓存中直接对数据进行增删改操作。此时，得益于Redis 的高性能访问特性，数据的增删改操作可以在缓存中快速完成，处理结果也会快速返回给业务应用，这就可以提升业务应用的响应速度。
• 但是和只读缓存不一样的话，在使用读写缓存时，最新的数据是在redis中，而redis是内存数据库，一旦宕机内存中的数据就会丢失。
• 所以，根据业务应对数据可靠性和缓存性能的不同要求，我们会有同步直写和异步写回这两种策略
  • 同步直写策略优先保证数据可靠性
  • 异步写回策略优先提供快速响应

那怎么选择这两种策略呢？

• 同步直写是指，写请求发给缓存的同时，也会发给后端数据库进行处理，等待缓存和数据库都写完数据库，才给客户端返回。
  • 这样，即使缓存宕机或者发生故障，最新的数据仍然保证在数据库中，这就提供了数据可靠性保证
  • 不过，同步直写回降低缓存的访问性能。是因为缓存中处理写请求的速度是很快的，而数据库处理写请求的速度较慢。即使缓存很快地处理了写请求，也需要等待数据库处理完所有的写请求，才能给应用返回结果，这就增加了缓存的响应延迟。
• 异步写回策略，则是优先考虑了响应延迟。此时，所有写请求都在缓存中处理，等到这些增改的数据要被从缓存中淘汰出来时，缓存将它们写回后端数据库。但是，如果发生宕机而没有被写回数据库，就会有丢失的风险了

怎么选择

到底是选择只读缓存，还是读写缓存呢？这就要看我们是否需要对写请求加速：

• 如果需要对写请求进行加速，我们选择读写缓存；
• 如果写请求很少，或者是只需要提升读请求的响应速度的话，我们选择只读缓存。

举个例子，在商品大促的场景中，商品的库存信息会一直被修改。如果每次修改都需到数据库中处理，就会拖慢整个应用，此时，我们通常会选择读写缓存的模式。而在短视频App 的场景中，虽然视频的属性有很多，但是，一般确定后，修改并不频繁，此时，在数据库中进行修改对缓存影响不大，所以只读缓存模式是一个合适的选择。

总结

缓存的两个特性：

• 在分层系统中，数据暂存在快速子系统中有助于加速访问；
• 缓存容量有限，缓存写满时，数据需要被淘汰。

redis天然具有高性能和数据淘汰机制，正好符合缓存的这两个特性的要求，所以非常适合用作缓存

redis作为旁路缓存的特性：

• 旁路缓存就意味着需要在应用程序中新增缓存逻辑处理的代码
• 如果是无法修改源码的应用场景，就不能使用 Redis 做缓存了。

Redis 做缓存时，还有两种模式，分别是只读缓存和读写缓存。其中，读写缓存还提供了同步直写和异步写回这两种模式，同步直写模式侧重于保证数据可靠性，而异步写回模式则侧重于提供低延迟访问，我们要根据实际的业务场景需求来进行选择。