redis的旁路设计 redis旁路缓存_缓存


redis的旁路设计 redis旁路缓存_数据_02


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

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

跟内存相比，LLC 的访问速度更快，而跟磁盘相比，内存的访问是更快的。所以，我们可以看出来缓存的第一个特征：在一个层次化的系统中，缓存一定是一个快速子系统，数据存在缓存中时，能避免每次从慢速子系统中存取数据。对应到互联网应用来说，Redis 就是快速子系统，而数据库就是慢速子系统了。

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

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

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

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

如果应用程序想要使用 Redis 缓存，我们就要在程序中增加相应的缓存操作代码。所以，我们也把 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 GET 接口，查询数据是否存在。而所有的数据写请求，会直接发往后端的数据库，在数据库中增删改。对于删改的数据来说，如果 Redis 已经缓存了相应的数据，应用需要把这些缓存的数据删除，Redis 中就没有这些数据了。

当应用再次读取这些数据时，会发生缓存缺失，应用会把这些数据从数据库中读出来，并写到缓存中。这样一来，这些数据后续再被读取时，就可以直接从缓存中获取了，能起到加速访问的效果。

需要注意，无论是修改或者删除之后，如果Redis有的话，都会将数据删除，当再次访问到这个数据的时候才会将它插入Redis。

读写缓存

读写缓存和只读缓存不一样的地方在于，使用只读缓存时，客户端只向Redis发送读请求。而使用读写缓存时，客户端可以向Redis进行增删改查操作，提高业务响应速度。
但这显然是有风险的，如果新数据写入Redis但还没来及写入后端的数据库的时候出现掉电或者宕机，新数据就会丢失，给业务带来风险。

所以可以根据业务对可靠性及缓存性能的不同要求，我们有同步直写和异步写回两种策略。

同步直写与异步写回

同步直写是指，写请求发给缓存的同时，也会发给后端数据库进行处理，等到缓存和数据库都写完数据，才给客户端返回。这样，即使缓存宕机或发生故障，最新的数据仍然保存在数据库中，这就提供了数据可靠性保证。不过，同步直写会降低缓存的访问性能。

而异步写回策略，则是优先考虑了响应延迟。此时，所有写请求都先在缓存中处理。等到这些增改的数据要被从缓存中淘汰出来时，缓存将它们写回后端数据库。这样一来，处理这些数据的操作是在缓存中进行的，很快就能完成。只不过，如果发生了掉电，而它们还没有被写回数据库，就会有丢失的风险了。

redis的旁路设计 redis旁路缓存_缓存_03