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是内存数据库，一旦出现掉电或宕机，内存中的数据就会丢失。
所以，根据业务应用对数据可靠性和缓存性能的不同要求，会有两种策略，分别是同步直写和异步写回。
- 同步直写，优先保证数据可靠性：写请求发给缓存，同时也会发给后端数据库进行处理，等到缓存和数据库都写完数据，才给客户端返回。
- 异步写回，优先提供快速响应：所有写请求都先在缓存中处理，等到这些增改的数据要被缓存淘汰时，缓存再写回后端数据库。
只读缓存和读写缓存的选择
- 如果需要对写请求进行回事，选择读写缓存。
- 如果写请求很少，或者是只需要提升读请求的响应速度的话，选择只读缓存。
只读缓存和使用直写策略的读写缓存有什么区别？
使用只读缓存时，是先把修改写到后端数据中，再把缓存中的数据删除。下次访问时，再从后端数据库读取。
- 优点：数据库和缓存完全一致，缓存中永远保留的是经常访问的热点数据。
- 缺点：数据删除后访问会触发一次缓存缺失，从后端数据库加载数据到缓存中，这个过程访问延时会变大。
使用读写缓存时，是同时修改数据库和缓存中的值。
- 优点：被修改后的数据永远在缓存中存在，下次访问直接命中缓存。
- 缺点：在高并发场景下，可能会导致缓存和数据库的不一致
当数据库或缓存修改失败时：
- 只读缓存：数据库和缓存中的数据保持一致
- 读写缓存：可能导致缓存和数据库的不一致
总结一下：只读缓存牺牲一定性能，优先保证数据库和缓存的一致性，更适合对于一致性要求比较高的业务场景。对于数据库和缓存一致性要求不高，或者不存在并发修改同一个值的情况，使用读写缓存比较合适，保证更好的性能。