Redis缓存篇（一）Redis是如何工作的

Redis提供了高性能的数据存取功能，所以广泛应用在缓存场景中，既能有效地提升业务应用的响应速度，还可以避免把高并发压力发送到数据库层。

因为Redis用作缓存的普遍性以及它在业务应用中的重要作用，所以需要系统地掌握缓存的一系列内容，包括工作原理、替换策略、异常处理和扩展机制。

今天我们了解缓存的特征和Redis缓存的工作机制。

缓存特征

主要有两个特征：

一是在一个层次化的系统中，缓存一定是一个快速子系统，数据存在缓存中时，能避免每次从慢速子系统中存取数据。

二是缓存系统的容量大小总是小于后端慢速系统的，我们不可能把所有数据都放在缓存系统中。

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

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

缓存命中：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，但是会删除相应的数据。当再次读取数据时，会发生缓存缺失，然后从数据库中读取并写入缓存。

读写缓存

读写缓存指除了读请求会发到缓存处理，写请求也会发到缓存处理。

和只读缓存不一样的是，在使用读写缓存时，最新的数据是在Redis中，而Redis是内存数据库，一旦出现掉电或宕机，内存中的数据就会丢失。

所以，根据业务应用对数据可靠性和缓存性能的不同要求，会有两种策略，分别是同步直写和异步写回。

同步直写，优先保证数据可靠性：写请求发给缓存，同时也会发给后端数据库进行处理，等到缓存和数据库都写完数据，才给客户端返回。
异步写回，优先提供快速响应：所有写请求都先在缓存中处理，等到这些增改的数据要被缓存淘汰时，缓存再写回后端数据库。

只读缓存和读写缓存的选择

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

只读缓存和使用直写策略的读写缓存有什么区别？

使用只读缓存时，是先把修改写到后端数据中，再把缓存中的数据删除。下次访问时，再从后端数据库读取。

优点：数据库和缓存完全一致，缓存中永远保留的是经常访问的热点数据。
缺点：数据删除后访问会触发一次缓存缺失，从后端数据库加载数据到缓存中，这个过程访问延时会变大。

使用读写缓存时，是同时修改数据库和缓存中的值。

优点：被修改后的数据永远在缓存中存在，下次访问直接命中缓存。
缺点：在高并发场景下，可能会导致缓存和数据库的不一致

当数据库或缓存修改失败时：

只读缓存：数据库和缓存中的数据保持一致
读写缓存：可能导致缓存和数据库的不一致

总结一下：只读缓存牺牲一定性能，优先保证数据库和缓存的一致性，更适合对于一致性要求比较高的业务场景。对于数据库和缓存一致性要求不高，或者不存在并发修改同一个值的情况，使用读写缓存比较合适，保证更好的性能。

参考资料

23 | 旁路缓存：Redis是如何工作的？