基于Spring接口集成Caffeine+Redis兩級(jí)緩存
前言
在上一篇文章Redis+Caffeine兩級(jí)緩存的實(shí)現(xiàn)中，我們介紹了3種整合Caffeine和Redis作為兩級(jí)緩存使用的方法，雖然說能夠?qū)崿F(xiàn)功能，但實(shí)現(xiàn)手法還是太粗糙了，并且遺留了一些問題沒有處理。本文將在上一篇的基礎(chǔ)上，圍繞兩個(gè)方面進(jìn)行進(jìn)一步的改造：
JSR107定義了緩存使用規(guī)范，spring中提供了基于這個(gè)規(guī)范的接口，所以我們可以直接使用spring中的接口進(jìn)行Caffeine和Redis兩級(jí)緩存的整合改造- 在分布式環(huán)境下，如果一臺(tái)主機(jī)的本地緩存進(jìn)行修改，需要通知其他主機(jī)修改本地緩存，解決分布式環(huán)境下本地緩存一致性問題
好了，在明確了需要的改進(jìn)問題后，下面我們開始正式修改。
改造
在上篇文章的v3版本中，我們使用自定義注解的方式實(shí)現(xiàn)了兩級(jí)緩存通過一個(gè)注解管理的功能。本文我們換一種方式，直接通過擴(kuò)展spring提供的接口來實(shí)現(xiàn)這個(gè)功能，在進(jìn)行整合之前，我們需要簡單了解一下JSR107緩存規(guī)范。
JSR107 規(guī)范
在JSR107緩存規(guī)范中定義了5個(gè)核心接口，分別是CachingProvider,CacheManager,Cache, Entry和Expiry，參考下面這張圖，可以看到除了Entry和Expiry以外，從上到下都是一對多的包含關(guān)系。
從上面這張圖我們可以看出，一個(gè)應(yīng)用可以創(chuàng)建并管理多個(gè)CachingProvider，同樣一個(gè)CachingProvider也可以管理多個(gè)CacheManager，緩存管理器CacheManager中則維護(hù)了多個(gè)Cache。
Cache是一個(gè)類似Map的數(shù)據(jù)結(jié)構(gòu)，Entry就是其中存儲(chǔ)的每一個(gè)key-value數(shù)據(jù)對，并且每個(gè)Entry都有一個(gè)過期時(shí)間Expiry。而我們在使用spring集成第三方的緩存時(shí)，只需要實(shí)現(xiàn)Cache和CacheManager這兩個(gè)接口就可以了，下面分別具體來看一下。
Cache
spring中的Cache接口規(guī)范了緩存組件的定義，包含了緩存的各種操作，實(shí)現(xiàn)具體緩存操作的管理。例如我們熟悉的RedisCache、EhCacheCache等，都實(shí)現(xiàn)了這個(gè)接口。
在Cache接口中，定義了get、put、evict、clear等方法，分別對應(yīng)緩存的存入、取出、刪除、清空操作。不過我們這里不直接使用Cache接口，上面這張圖中的AbstractValueAdaptingCache是一個(gè)抽象類，它已經(jīng)實(shí)現(xiàn)了Cache接口，是spring在Cache接口的基礎(chǔ)上幫助我們進(jìn)行了一層封裝，所以我們直接繼承這個(gè)類就可以。
繼承AbstractValueAdaptingCache抽象類后，除了創(chuàng)建Cache的構(gòu)造方法外，還需要實(shí)現(xiàn)下面的幾個(gè)方法：
// 在緩存中實(shí)際執(zhí)行查找的操作，父類的get()方法會(huì)調(diào)用這個(gè)方法 protected abstract Object lookup(Object key); // 通過key獲取緩存值，如果沒有找到，會(huì)調(diào)用valueLoader的call()方法 public <T> T get(Object key, Callable<T> valueLoader); // 將數(shù)據(jù)放入緩存中 public void put(Object key, Object value); // 刪除緩存 public void evict(Object key); // 清空緩存中所有數(shù)據(jù) public void clear(); // 獲取緩存名稱，一般在CacheManager創(chuàng)建時(shí)指定 String getName(); // 獲取實(shí)際使用的緩存 Object getNativeCache();
因?yàn)橐?code>RedisTemplate和Caffeine的Cache，所以這些都需要在緩存的構(gòu)造方法中傳入，除此之外構(gòu)造方法中還需要再傳出緩存名稱cacheName，以及在配置文件中實(shí)際配置的一些緩存參數(shù)。先看一下構(gòu)造方法的實(shí)現(xiàn)：
public class DoubleCache extends AbstractValueAdaptingCache {
private String cacheName;
private RedisTemplate<Object, Object> redisTemplate;
private Cache<Object, Object> caffeineCache;
private DoubleCacheConfig doubleCacheConfig;
protected DoubleCache(boolean allowNullValues) {
super(allowNullValues);
}
public DoubleCache(String cacheName,RedisTemplate<Object, Object> redisTemplate,
Cache<Object, Object> caffeineCache,
DoubleCacheConfig doubleCacheConfig){
super(doubleCacheConfig.getAllowNull());
this.cacheName=cacheName;
this.redisTemplate=redisTemplate;
this.caffeineCache=caffeineCache;
this.doubleCacheConfig=doubleCacheConfig;
}
//...
}抽象父類的構(gòu)造方法中只有一個(gè)boolean類型的參數(shù)allowNullValues，表示是否允許緩存對象為null。除此之外，AbstractValueAdaptingCache中還定義了兩個(gè)包裝方法來配合這個(gè)參數(shù)進(jìn)行使用，分別是toStoreValue和fromStoreValue，特殊用途是用于在緩存null對象時(shí)進(jìn)行包裝、以及在獲取時(shí)進(jìn)行解析并返回。
我們之后會(huì)在CacheManager中調(diào)用后面這個(gè)自己實(shí)現(xiàn)的構(gòu)造方法，來實(shí)例化Cache對象，參數(shù)中DoubleCacheConfig是使用@ConfigurationProperties讀取的yml配置文件封裝的數(shù)據(jù)對象，會(huì)在后面使用。
當(dāng)一個(gè)方法添加了@Cacheable注解時(shí)，執(zhí)行時(shí)會(huì)先調(diào)用父類AbstractValueAdaptingCache中的get(key)方法，它會(huì)再調(diào)用我們自己實(shí)現(xiàn)的lookup方法。在實(shí)際執(zhí)行查找操作的lookup方法中，我們的邏輯仍然是先查找Caffeine、沒有找到時(shí)再查找Redis：
@Override
protected Object lookup(Object key) {
// 先從caffeine中查找
Object obj = caffeineCache.getIfPresent(key);
if (Objects.nonNull(obj)){
log.info("get data from caffeine");
return obj;
}
//再從redis中查找
String redisKey=this.name+":"+ key;
obj = redisTemplate.opsForValue().get(redisKey);
if (Objects.nonNull(obj)){
log.info("get data from redis");
caffeineCache.put(key,obj);
}
return obj;
}如果lookup方法的返回結(jié)果不為null，那么就會(huì)直接返回結(jié)果給調(diào)用方。如果返回為null時(shí)，就會(huì)執(zhí)行原方法，執(zhí)行完成后調(diào)用put方法，將數(shù)據(jù)放入緩存中。接下來我們實(shí)現(xiàn)put方法：
@Override
public void put(Object key, Object value) {
if(!isAllowNullValues() && Objects.isNull(value)){
log.error("the value NULL will not be cached");
return;
}
//使用 toStoreValue(value) 包裝，解決caffeine不能存null的問題
caffeineCache.put(key,toStoreValue(value));
// null對象只存在caffeine中一份就夠了，不用存redis了
if (Objects.isNull(value))
return;
String redisKey=this.cacheName +":"+ key;
Optional<Long> expireOpt = Optional.ofNullable(doubleCacheConfig)
.map(DoubleCacheConfig::getRedisExpire);
if (expireOpt.isPresent()){
redisTemplate.opsForValue().set(redisKey,toStoreValue(value),
expireOpt.get(), TimeUnit.SECONDS);
}else{
redisTemplate.opsForValue().set(redisKey,toStoreValue(value));
}
}上面我們對于是否允許緩存空對象進(jìn)行了判斷，能夠緩存空對象的好處之一就是可以避免緩存穿透。需要注意的是，Caffeine中是不能直接緩存null的，因此可以使用父類提供的toStoreValue()方法，將它包裝成一個(gè)NullValue類型。在取出對象時(shí)，如果是NullValue，也不用我們自己再去調(diào)用fromStoreValue()將這個(gè)包裝類型還原，父類的get方法中已經(jīng)幫我們做好了。
另外，上面在put方法中緩存空對象時(shí)，只在Caffeine緩存中一份即可，可以不用在Redis中再存一份。
緩存的刪除方法evict()和清空方法clear()的實(shí)現(xiàn)就比較簡單了，直接刪除一跳或全部數(shù)據(jù)即可：
@Override
public void evict(Object key) {
redisTemplate.delete(this.cacheName +":"+ key);
caffeineCache.invalidate(key);
}
@Override
public void clear() {
Set<Object> keys = redisTemplate.keys(this.cacheName.concat(":*"));
for (Object key : keys) {
redisTemplate.delete(String.valueOf(key));
}
caffeineCache.invalidateAll();
}獲取緩存cacheName和實(shí)際緩存的方法實(shí)現(xiàn)：
@Override
public String getName() {
return this.cacheName;
}
@Override
public Object getNativeCache() {
return this;
}最后，我們再來看一下帶有兩個(gè)參數(shù)的get方法，為什么把這個(gè)方法放到最后來說呢，因?yàn)槿绻覀冎皇鞘褂米⒔鈦砉芾砭彺娴脑?，那么這個(gè)方法不會(huì)被調(diào)用到，簡單看一下實(shí)現(xiàn)：
@Override
public <T> T get(Object key, Callable<T> valueLoader) {
ReentrantLock lock=new ReentrantLock();
try{
lock.lock();//加鎖
Object obj = lookup(key);
if (Objects.nonNull(obj)){
return (T)obj;
}
//沒有找到
obj = valueLoader.call();
put(key,obj);//放入緩存
return (T)obj;
}catch (Exception e){
log.error(e.getMessage());
}finally {
lock.unlock();
}
return null;
}方法的實(shí)現(xiàn)比較容易理解，還是先調(diào)用lookup方法尋找是否已經(jīng)緩存了對象，如果沒有找到那么就調(diào)用Callable中的call方法進(jìn)行獲取，并在獲取完成后存入到緩存中去。至于這個(gè)方法如何使用，具體代碼我們放在后面使用這一塊再看。
需要注意的是，這個(gè)方法的接口注釋中強(qiáng)調(diào)了需要我們自己來保證方法同步，因此這里使用了ReentrantLock進(jìn)行了加鎖操作。到這里，Cache的實(shí)現(xiàn)就完成了，下面我們接著看另一個(gè)重要的接口CacheManager。
CacheManager
從名字就可以看出，CacheManager是一個(gè)緩存管理器，它可以被用來管理一組Cache。在上一篇文章的v2版本中，我們使用的CaffeineCacheManager就實(shí)現(xiàn)了這個(gè)接口，除此之外還有RedisCacheManager、EhCacheCacheManager等也都是通過這個(gè)接口實(shí)現(xiàn)。
下面我們要自定義一個(gè)類實(shí)現(xiàn)CacheManager接口，管理上面實(shí)現(xiàn)的DoubleCache作為spring中的緩存使用。接口中需要實(shí)現(xiàn)的方法只有下面兩個(gè)：
//根據(jù)cacheName獲取Cache實(shí)例，不存在時(shí)進(jìn)行創(chuàng)建 Cache getCache(String name); //返回管理的所有cacheName Collection<String> getCacheNames();
在自定義的緩存管理器中，我們要使用ConcurrentHashMap維護(hù)一組不同的Cache，再定義一個(gè)構(gòu)造方法，在參數(shù)中傳入已經(jīng)在spring中配置好的RedisTemplate，以及相關(guān)的緩存配置參數(shù)：
public class DoubleCacheManager implements CacheManager {
Map<String, Cache> cacheMap = new ConcurrentHashMap<>();
private RedisTemplate<Object, Object> redisTemplate;
private DoubleCacheConfig dcConfig;
public DoubleCacheManager(RedisTemplate<Object, Object> redisTemplate,
DoubleCacheConfig doubleCacheConfig) {
this.redisTemplate = redisTemplate;
this.dcConfig = doubleCacheConfig;
}
//...
}然后實(shí)現(xiàn)getCache方法，邏輯很簡單，先根據(jù)name從Map中查找對應(yīng)的Cache，如果找到則直接返回，這個(gè)參數(shù)name就是上一篇文章中提到的cacheName，CacheManager根據(jù)它實(shí)現(xiàn)不同Cache的隔離。
如果沒有根據(jù)名稱找到緩存的話，那么新建一個(gè)DoubleCache對象，并放入Map中。這里使用的ConcurrentHashMap的putIfAbsent()方法放入，避免重復(fù)創(chuàng)建Cache以及造成Cache內(nèi)數(shù)據(jù)的丟失。具體代碼如下：
@Override
public Cache getCache(String name) {
Cache cache = cacheMap.get(name);
if (Objects.nonNull(cache)) {
return cache;
}
cache = new DoubleCache(name, redisTemplate, createCaffeineCache(), dcConfig);
Cache oldCache = cacheMap.putIfAbsent(name, cache);
return oldCache == null ? cache : oldCache;
}在上面創(chuàng)建DoubleCache對象的過程中，需要先創(chuàng)建一個(gè)Caffeine的Cache對象作為參數(shù)傳入，這一過程主要是根據(jù)實(shí)際項(xiàng)目的配置文件中的具體參數(shù)進(jìn)行初始化，代碼如下：
private com.github.benmanes.caffeine.cache.Cache createCaffeineCache(){
Caffeine<Object, Object> caffeineBuilder = Caffeine.newBuilder();
Optional<DoubleCacheConfig> dcConfigOpt = Optional.ofNullable(this.dcConfig);
dcConfigOpt.map(DoubleCacheConfig::getInit)
.ifPresent(init->caffeineBuilder.initialCapacity(init));
dcConfigOpt.map(DoubleCacheConfig::getMax)
.ifPresent(max->caffeineBuilder.maximumSize(max));
dcConfigOpt.map(DoubleCacheConfig::getExpireAfterWrite)
.ifPresent(eaw->caffeineBuilder.expireAfterWrite(eaw,TimeUnit.SECONDS));
dcConfigOpt.map(DoubleCacheConfig::getExpireAfterAccess)
.ifPresent(eaa->caffeineBuilder.expireAfterAccess(eaa,TimeUnit.SECONDS));
dcConfigOpt.map(DoubleCacheConfig::getRefreshAfterWrite)
.ifPresent(raw->caffeineBuilder.refreshAfterWrite(raw,TimeUnit.SECONDS));
return caffeineBuilder.build();
}getCacheNames方法很簡單，直接返回Map的keySet就可以了，代碼如下：
@Override
public Collection<String> getCacheNames() {
return cacheMap.keySet();
}配置&使用
在application.yml文件中配置緩存的參數(shù)，代碼中使用@ConfigurationProperties接收到DoubleCacheConfig類中：
doublecache: allowNull: true init: 128 max: 1024 expireAfterWrite: 30 #Caffeine過期時(shí)間 redisExpire: 60 #Redis緩存過期時(shí)間
配置自定義的DoubleCacheManager作為默認(rèn)的緩存管理器：
@Configuration
public class CacheConfig {
@Autowired
DoubleCacheConfig doubleCacheConfig;
@Bean
public DoubleCacheManager cacheManager(RedisTemplate<Object,Object> redisTemplate,
DoubleCacheConfig doubleCacheConfig){
return new DoubleCacheManager(redisTemplate,doubleCacheConfig);
}
}Service中的代碼還是老樣子，不需要在代碼中手動(dòng)操作緩存，只要直接在方法上使用@Cache相關(guān)注解即可：
@Service @Slf4j
@AllArgsConstructor
public class OrderServiceImpl implements OrderService {
private final OrderMapper orderMapper;
@Cacheable(value = "order",key = "#id")
public Order getOrderById(Long id) {
Order myOrder = orderMapper.selectOne(new LambdaQueryWrapper<Order>()
.eq(Order::getId, id));
return myOrder;
}
@CachePut(cacheNames = "order",key = "#order.id")
public Order updateOrder(Order order) {
orderMapper.updateById(order);
return order;
}
@CacheEvict(cacheNames = "order",key = "#id")
public void deleteOrder(Long id) {
orderMapper.deleteById(id);
}
//沒有注解,使用get(key,callable)方法
public Order getOrderById2(Long id) {
DoubleCacheManager cacheManager = SpringContextUtil.getBean(DoubleCacheManager.class);
Cache cache = cacheManager.getCache("order");
Order order =(Order) cache.get(id, (Callable<Object>) () -> {
log.info("get data from database");
Order myOrder = orderMapper.selectOne(new LambdaQueryWrapper<Order>()
.eq(Order::getId, id));
return myOrder;
});
return order;
}
}
注意最后這個(gè)沒有添加任何注解的方法，只有以這種方式調(diào)用時(shí)才會(huì)執(zhí)行我們在DoubleCache中自己實(shí)現(xiàn)的get(key,callable)方法。到這里，基于JSR107規(guī)范和spring接口的兩級(jí)緩存改造就完成了，下面我們看一下遺漏的第二個(gè)問題。
分布式環(huán)境改造
前面我們說了，在分布式環(huán)境下，可能會(huì)存在各個(gè)主機(jī)上一級(jí)緩存不一致的問題。當(dāng)一臺(tái)主機(jī)修改了本地緩存后，其他主機(jī)是沒有感知的，仍然保持了之前的緩存，那么這種情況下就可能取到臟數(shù)據(jù)。既然我們在項(xiàng)目中已經(jīng)使用了Redis，那么就可以使用它的發(fā)布/訂閱功能來使各個(gè)節(jié)點(diǎn)的緩存進(jìn)行同步。
定義消息體
在使用Redis發(fā)送消息前，需要先定義一個(gè)消息對象。其中的數(shù)據(jù)包括消息要作用于的Cache名稱、操作類型、數(shù)據(jù)以及發(fā)出消息的源主機(jī)標(biāo)識(shí)：
@Data
@NoArgsConstructor
@AllArgsConstructor
public class CacheMassage implements Serializable {
private static final long serialVersionUID = -3574997636829868400L;
private String cacheName;
private CacheMsgType type; //標(biāo)識(shí)更新或刪除操作
private Object key;
private Object value;
private String msgSource; //源主機(jī)標(biāo)識(shí)，用來避免重復(fù)操作
}定義一個(gè)枚舉來標(biāo)識(shí)消息的類型，是要進(jìn)行更新還是刪除操作：
public enum CacheMsgType {
UPDATE,
DELETE;
}消息體中的msgSource是添加的一個(gè)消息源主機(jī)的標(biāo)識(shí)，添加這個(gè)是為了避免收到當(dāng)前主機(jī)發(fā)送的消息后，再進(jìn)行重復(fù)操作，也就是說收到本機(jī)發(fā)出的消息直接丟掉什么都不做就可以了。源主機(jī)標(biāo)識(shí)這里使用的是主機(jī)ip加項(xiàng)目端口的方式，獲取方法如下：
public static String getMsgSource() throws UnknownHostException {
String host = InetAddress.getLocalHost().getHostAddress();
Environment env = SpringContextUtil.getBean(Environment.class);
String port = env.getProperty("server.port");
return host+":"+port;
}這樣消息體的定義就完成了，之后只要調(diào)用redisTemplate的convertAndSend方法就可以把這個(gè)對象發(fā)布到指定的主題上了。
Redis消息配置
要使用Redis的消息監(jiān)聽功能，需要配置兩項(xiàng)內(nèi)容：
MessageListenerAdapter：消息監(jiān)聽適配器，可以在其中指定自定義的監(jiān)聽代理類，并且可以自定義使用哪個(gè)方法處理監(jiān)聽邏輯RedisMessageListenerContainer： 一個(gè)可以為消息監(jiān)聽器提供異步行為的容器，并且提供消息轉(zhuǎn)換和分派等底層功能
@Configuration
public class MessageConfig {
public static final String TOPIC="cache.msg";
@Bean
RedisMessageListenerContainer container(MessageListenerAdapter listenerAdapter,
RedisConnectionFactory redisConnectionFactory){
RedisMessageListenerContainer container = new RedisMessageListenerContainer();
container.setConnectionFactory(redisConnectionFactory);
container.addMessageListener(listenerAdapter, new PatternTopic(TOPIC));
return container;
}
@Bean
MessageListenerAdapter adapter(RedisMessageReceiver receiver){
return new MessageListenerAdapter(receiver,"receive");
}
}在上面的監(jiān)聽適配器MessageListenerAdapter中，我們傳入了一個(gè)自定義的RedisMessageReceiver接收并處理消息，并指定使用它的receive方法來處理監(jiān)聽到的消息，下面我們就來看看它如何接收消息并消費(fèi)。
消息消費(fèi)邏輯
定義一個(gè)類RedisMessageReceiver來接收并消費(fèi)消息，需要在它的方法中實(shí)現(xiàn)以下功能：
- 反序列化接收到的消息，轉(zhuǎn)換為前面定義的
CacheMassage類型對象 - 根據(jù)消息的主機(jī)標(biāo)識(shí)判斷這條消息是不是本機(jī)發(fā)出的，如果是那么直接丟棄，只有接收到其他主機(jī)發(fā)出的消息才進(jìn)行處理
- 使用
cacheName得到具體使用的那一個(gè)DoubleCache實(shí)例 - 根據(jù)消息的類型判斷要執(zhí)行的是更新還是刪除操作，調(diào)用對應(yīng)的方法
@Slf4j @Component
@AllArgsConstructor
public class RedisMessageReceiver {
private final RedisTemplate redisTemplate;
private final DoubleCacheManager manager;
//接收通知，進(jìn)行處理
public void receive(String message) throws UnknownHostException {
CacheMassage msg = (CacheMassage) redisTemplate
.getValueSerializer().deserialize(message.getBytes());
log.info(msg.toString());
//如果是本機(jī)發(fā)出的消息，那么不進(jìn)行處理
if (msg.getMsgSource().equals(MessageSourceUtil.getMsgSource())){
log.info("收到本機(jī)發(fā)出的消息，不做處理");
return;
}
DoubleCache cache = (DoubleCache) manager.getCache(msg.getCacheName());
if (msg.getType()== CacheMsgType.UPDATE) {
cache.updateL1Cache(msg.getKey(),msg.getValue());
log.info("更新本地緩存");
}
if (msg.getType()== CacheMsgType.DELETE) {
log.info("刪除本地緩存");
cache.evictL1Cache(msg.getKey());
}
}
}在上面的代碼中，調(diào)用了DoubleCache中更新一級(jí)緩存方法updateL1Cache、刪除一級(jí)緩存方法evictL1Cache，我們會(huì)后面在DoubleCache中進(jìn)行添加。
修改DoubleCache
在DoubleCache中先添加上面提到的兩個(gè)方法，由CacheManager獲取到具體緩存后調(diào)用，進(jìn)行一級(jí)緩存的更新或刪除操作：
// 更新一級(jí)緩存
public void updateL1Cache(Object key,Object value){
caffeineCache.put(key,value);
}
// 刪除一級(jí)緩存
public void evictL1Cache(Object key){
caffeineCache.invalidate(key);
}好了，完事具備只欠東風(fēng)，我們要在什么場合發(fā)送消息呢？答案是在DoubleCache中存入緩存的put方法和移除緩存的evict方法中。首先修改put方法，方法中前面的邏輯不變，在最后添加發(fā)送消息通知其他節(jié)點(diǎn)更新一級(jí)緩存的邏輯：
public void put(Object key, Object value) {
// 省略前面的不變代碼...
//發(fā)送信息通知其他節(jié)點(diǎn)更新一級(jí)緩存
CacheMassage cacheMassage
= new CacheMassage(this.cacheName, CacheMsgType.UPDATE,
key,value, MessageSourceUtil.getMsgSource());
redisTemplate.convertAndSend(MessageConfig.TOPIC,cacheMassage);
}然后修改evict方法，同樣保持前面的邏輯不變，在最后添加發(fā)送消息的代碼：
public void evict(Object key) {
// 省略前面的不變代碼...
//發(fā)送信息通知其他節(jié)點(diǎn)刪除一級(jí)緩存
CacheMassage cacheMassage
= new CacheMassage(this.cacheName, CacheMsgType.DELETE,
key,null, MessageSourceUtil.getMsgSource());
redisTemplate.convertAndSend(MessageConfig.TOPIC,cacheMassage);
}適配分布式環(huán)境的改造工作到此結(jié)束，下面進(jìn)行一下簡單的測試工作。
測試
我們可以用idea的Allow parallel run功能同時(shí)啟動(dòng)兩個(gè)一樣的springboot項(xiàng)目，來模擬分布式環(huán)境下的兩臺(tái)主機(jī)，注意在啟動(dòng)參數(shù)中添加-Dserver.port參數(shù)來啟動(dòng)到不同端口。
首先測試更新操作，使用接口修改某一個(gè)主機(jī)的本地緩存，可以看到發(fā)出消息的主機(jī)在收到消息后，直接丟棄不做任何處理：
查看另一臺(tái)主機(jī)的日志，收到消息并更新了本地緩存：
再看一下緩存的刪除情況，同樣本地刪除后再收到消息不做處理：
看另一臺(tái)主機(jī)收到消息后，會(huì)刪除本地的一級(jí)緩存：
可以看到，分布式環(huán)境下本地緩存通過Redis消息的發(fā)布訂閱機(jī)制保證了一級(jí)緩存的一致性。
另外，如果更加嚴(yán)謹(jǐn)一些的話，其實(shí)還應(yīng)該處理一下緩存更新失敗的情況，這里留個(gè)坑以后再填。簡單說一下思路，我們應(yīng)該在代碼中捕獲緩存更新失敗的異常，然后刪除二級(jí)緩存、本機(jī)以及其他主機(jī)的一級(jí)緩存，再等待下一次訪問時(shí)直接拉取最新的數(shù)據(jù)進(jìn)行緩存。同樣，要想實(shí)現(xiàn)緩存失效同時(shí)作用于所有單機(jī)節(jié)點(diǎn)的本地緩存這一功能，也可以使用上面的發(fā)布訂閱來實(shí)現(xiàn)。
總結(jié)
好了，這次縫縫補(bǔ)補(bǔ)的填坑之旅到這里就要結(jié)束了?？梢钥吹绞褂没?code>JSR107規(guī)范的spring接口進(jìn)行修改后，代碼看起來舒服了很多，并且支持直接使用spring的@Cache相關(guān)注解。如果想在項(xiàng)目中使用的話，自己封裝一個(gè)簡單的starter就可以了，使用起來也非常簡單。
以上就是基于Spring接口集成Caffeine+Redis兩級(jí)緩存的詳細(xì)內(nèi)容，更多關(guān)于集成Caffeine+Redis兩級(jí)緩存的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
Java基于ReadWriteLock實(shí)現(xiàn)鎖的應(yīng)用
這篇文章主要介紹了Java基于ReadWriteLock實(shí)現(xiàn)鎖的應(yīng)用,文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-10-10
Java?獲取Zookeeper節(jié)點(diǎn)下所有數(shù)據(jù)詳細(xì)步驟
本文介紹了如何使用Java獲取ZooKeeper節(jié)點(diǎn)下所有數(shù)據(jù),實(shí)際應(yīng)用示例中,我們演示了如何從ZooKeeper節(jié)點(diǎn)下獲取配置信息并輸出到控制臺(tái),ZooKeeper是一個(gè)開源的分布式協(xié)調(diào)服務(wù),適用于分布式系統(tǒng)中的數(shù)據(jù)同步、配置管理、命名服務(wù)等功能,感興趣的朋友一起看看吧2024-11-11
面試官：怎么做JDK8的垃圾收集器的調(diào)優(yōu)(面試常問)
這篇文章主要介紹了面試官：怎么做JDK8的垃圾收集器的調(diào)優(yōu),本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2020-08-08
Spring Data Jpa 自動(dòng)生成表結(jié)構(gòu)的方法示例
這篇文章主要介紹了Spring Data Jpa 自動(dòng)生成表結(jié)構(gòu)的方法示例，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-04-04
Kotlin-Coroutines中的async與await異步協(xié)程管理
這篇文章主要為大家介紹了Kotlin-Coroutines中的async與await異步協(xié)程管理,提升程序性能解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-10-10
EasyExcel自定義下拉注解的三種實(shí)現(xiàn)方式總結(jié)
使用EasyExcel設(shè)置下拉數(shù)據(jù)時(shí),每次都要?jiǎng)?chuàng)建一個(gè)SheetWriteHandler組件確實(shí)比較繁瑣,為了優(yōu)化這個(gè)過程,我們可以通過自定義注解來簡化操作,下面就來看看具體實(shí)現(xiàn)方法吧2024-10-10
Spring實(shí)現(xiàn)Logback日志模板設(shè)置動(dòng)態(tài)參數(shù)功能
本文介紹如何在Spring應(yīng)用中實(shí)現(xiàn)Logback日志模板的動(dòng)態(tài)參數(shù)設(shè)置,通過設(shè)計(jì)traceId鏈路標(biāo)識(shí),將其動(dòng)態(tài)添加到日志輸出中,從而實(shí)現(xiàn)簡易的鏈路追蹤功能,感興趣的朋友跟隨小編一起看看吧2024-11-11
這篇文章主要為大家詳細(xì)介紹了Java堆排序算法的相關(guān)代碼，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2017-09-09
java對數(shù)據(jù)庫更新的操作方式及注意事項(xiàng)
這篇文章主要介紹了java對數(shù)據(jù)庫更新的操作方式及注意事項(xiàng),具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2025-04-04
SpringBoot2.x過后static下的靜態(tài)資源無法訪問的問題
這篇文章主要介紹了SpringBoot2.x過后static下的靜態(tài)資源無法訪問的問題，具有很好的參考價(jià)值，希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2023-01-01