Redis提供了高性能的数据存取功能,所以广泛应用在缓存场景中,既能有效地提升业务应用的响应速度,还可以避免把高并发压力发送到数据库层。
因为Redis用作缓存的普遍性以及它在业务应用中的重要作用,所以需要系统地掌握缓存的一系列内容,包括工作原理、替换策略、异常处理和扩展机制。
今天我们了解缓存的特征和Redis缓存的工作机制。
主要有两个特征:
一是在一个层次化的系统中,缓存一定是一个快速子系统,数据存在缓存中时,能避免每次从慢速子系统中存取数据。
二是缓存系统的容量大小总是小于后端慢速系统的,我们不可能把所有数据都放在缓存系统中。
把Redis用作缓存时,会把Redis部署在数据库的前端,业务应用在访问数据时,会先查询Redis中是否保存了相应的数据。此时,根据数据是否存在缓存中,会有两种情况:
因为Redis是独立的系统软件,和业务应用程序是两个软件,因此使用Redis缓存时,要在应用程序中增加三方面代码:
下面是一段示例代码:
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是内存数据库,一旦出现掉电或宕机,内存中的数据就会丢失。
所以,根据业务应用对数据可靠性和缓存性能的不同要求,会有两种策略,分别是同步直写和异步写回。
使用只读缓存时,是先把修改写到后端数据中,再把缓存中的数据删除。下次访问时,再从后端数据库读取。
使用读写缓存时,是同时修改数据库和缓存中的值。
当数据库或缓存修改失败时:
总结一下:只读缓存牺牲一定性能,优先保证数据库和缓存的一致性,更适合对于一致性要求比较高的业务场景。对于数据库和缓存一致性要求不高,或者不存在并发修改同一个值的情况,使用读写缓存比较合适,保证更好的性能。