本地缓存在商品中心的应用

手动加载: 直接调用cache.put(key, value)
同步加载: Caffeine.build()
异步加载：Caffeine.buildAsync()，默认使用ForkJoinPool.commonPool()来执行异步线程，但是我们可以通过Caffeine.executor(Executor) 方法来替换线程池。

//同步加载
private LoadingCache<Long, InventoryEntity> inventoryLocalCache = Caffeine.newBuilder()
            .expireAfterWrite(15, TimeUnit.MINUTES)
            .initialCapacity(1024 * 64)
            .maximumSize(1024 * 1024)
            .executor(ThreadPoolConfiguration.localCacheExecutor)
            .build(new CacheLoader<Long, InventoryEntity>() {
                @Override
                public InventoryEntity load(@NotNull Long key) throws Exception {
                    return inventoryCache.getInventoryById(key);
                }
            });


//异步加载 
private LoadingCache<Long, InventoryEntity> asyncLoadingCache = Caffeine.newBuilder()
            .expireAfterWrite(15, TimeUnit.MINUTES)
            .initialCapacity(1024 * 64)
            .maximumSize(1024 * 1024)
            .executor(ThreadPoolConfiguration.localCacheExecutor)
            .buildAsync(new CacheLoader<Long, InventoryEntity>() {
                @Override
                public InventoryEntity load(@NotNull Long key) throws Exception {
                    return inventoryCache.getInventoryById(key);
                }
            });

//异步加载返回Future
CompletableFuture result = asyncLoadingCache.get(id);
//异步转同步，synchronous 返回了一个LoadingCacheView视图, 可以转换成了一个同步加载的缓存LoadingCache。底层还是通过异步来获取值，只是封装了一下future.get()
loadingCache = asyncLoadingCache.synchronous();

3.2.2 失效策略

基于大小
- Caffeine.maximumSize(MAX_SIZE)，当数量超过 MAX_SIZE 时，会使用Window TinyLfu策略来删除缓存。

基于时间
- expireAfterAccess(long, TimeUnit):在最后一次访问或者写入后开始计时，在指定的时间后过期。假如一直有请求访问该key，那么这个缓存将一直不会过期。
- expireAfterWrite(long, TimeUnit): 在最后一次写入缓存后开始计时，在指定的时间后过期。
- expireAfter(Expiry): 自定义策略，过期时间由Expiry实现独自计算

基于引用：AsyncLoadingCache不支持弱引用和软引用
- Caffeine.weakKeys() 使用弱引用存储key。如果没有其他地方对该key有强引用，那么该缓存就会被垃圾回收器回收。
  
  Caffeine.weakValues() 使用弱引用存储value。如果没有其他地方对该value有强引用，那么该缓存就会被垃圾回收器回收。
  
  Caffeine.softValues() 使用软引用存储value。当内存满了过后，软引用的对象以将使用最近最少使用(least-recently-used ) 的方式进行垃圾回收。由于使用软引用是需要等到内存满了才进行回收，所以我们通常建议给缓存配置一个使用内存的最大值。
- Caffeine.weakValues()和Caffeine.softValues()不可以一起使用。

3.2.3 刷新策略

刷新的是通过LoadingCache.refresh(key)方法来指定，并通过调用CacheLoader.reload方法来执行，刷新key会异步地为这个key加载新的value，并返回旧的值（如果有的话）。

刷新操作是使用Executor异步执行的，默认执行程序是ForkJoinPool.commonPool(), 可以通过 Caffeine.executor(Executor)覆盖。

注意：由于是异步刷新，所以从本地缓存get的时候，会返回旧值再去异步刷新，如果在访问量特别小并且机器数特别多的时候，旧值可能会存在很长一段时间。所以可以结合expireAfterWrite 一起使用，expireAfterWrite在访问时会判断是否过期，如果过期了，会同步加载并返回新结果

private LoadingCache<Long, InventoryEntity> inventoryLocalCache = Caffeine.newBuilder()
            .expireAfterWrite(15, TimeUnit.MINUTES)
            .initialCapacity(1024 * 64)
            .maximumSize(1024 * 1024)
            .executor(ThreadPoolConfiguration.localCacheExecutor)
            .build(new CacheLoader<Long, InventoryEntity>() {
                @Override
                public InventoryEntity load(@NotNull Long key) throws Exception {
                    return inventoryCache.getInventoryById(key);
                }

                @Override
                public @NotNull
                Map<Long, InventoryEntity> loadAll(@NotNull Iterable<? extends Long> keys)
                        throws Exception {
                    List<InventoryEntity> inventoryEntities = inventoryCache.getInventoriesByIds(Lists.newArrayList(keys));
                    Map<Long, InventoryEntity> inventoryEntityMap = inventoryEntities
                            .stream()
                            .collect(Collectors.toMap(InventoryEntity::getId, Function.identity()));
                    return inventoryEntityMap;
                }
            });

3.3 Caffeine原理简介

五、本地缓存在商品中的应用[本地缓存+广播消息]

一、分析

由于本地缓存会带来数据一致性的问题，可以把商品的信息分为三类：

数据永远不会发生改变：比如id关联关系 [skuId – spuId]
数据会发生改变，但不会影响下单: 比如价格、商品基本信息
数据会发生改变，但严重影响下单：比如库存 [库存不足时，下单肯定会失败]

		特点	本地缓存
1	数据永远不会改变	不存在数据一致性问题	缓存时间以天为单位
2	数据会改变，但不影响下单	数据一致性容忍度比较高	缓存时间以秒为单位
3	数据会改变，跟下单强相关	数据一致性容忍度较低	尽量不要进行本地缓存

二、存在的问题

1、本地缓存数据一致性问题

商品中心库存访问量巨大，Redis承受压力大。由于库存是否还有剩余跟用户能否下单强关联，在一致性上面希望能尽量准确，所以通过本地缓存能减少Redis压力，但是在一定程度上又希望库存量能够保证一致性，两者是相悖的，所以要么本地缓存时间尽可能小，要么解决数据一致性的问题。

1、方案一：库存本地缓存时间尽量小，尽可能保证数据一致性

由于辅导在售规格超过百万，业务会定期来刷新数据，所以在这样场景下，本地缓存时间设置得很小（比如1s），缓存命中的几率也十分小，并不能解决问题

2、方案二：通过消息广播解决数据一致性问题

通过广播消息把每台服务器的本地缓存置为失效，库存本地缓存主动失效时间可以设置以分为单位
准备数据修复任务，防止数据错误，手动修复

2、本地缓存大小问题[可暂不解决]

以当前的数据量：在售规格数为百万，与之对应的库存数也是百万。如果全部放在本地缓存里，大约100M，所以能够支撑。但是如果后续业务发展迅速，则不能有多少在售库存数就缓存多少

3、广播消息性能问题[可暂不解决]

库存广播消息目前跟下单的qps有关，当库存发生变化后，会进行广播消息，如果下单量特别大，则存在单台服务器会不断消费消息。目前下单量不超过100 QPS，所以单台服务器也能够支撑

3、最终方案

	数据特点	信息	缓存特点	结果
1	不存在数据一致性问题：不会变更	skuId- spuId映射关系	缓存时间以天为单位缓存大小：在售规格大小失效策略：基于时间写入后失效缓存命中率接近 100%	46w → 23w
2	数据一致性容忍度比较高 && 请求量不高	spu信息	缓存时间以秒为单位缓存大小：偏小失效策略：基于时间写入后失效缓存命中率较低
3	数据一致性容忍度较低或者请求量巨大	sku信息库存信息	缓存时间以分为单位缓存大小：在售规格大小失效策略：基于时间写入后失效 && 更新后失效【消息广播】缓存命中率：高	sku：360w → 20w 库存：320w → 10w

数据特点

信息

缓存特点

结果

不存在数据一致性问题：不会变更

skuId- spuId映射关系

缓存时间以天为单位
缓存大小：在售规格大小
失效策略：基于时间写入后失效
缓存命中率接近 100%

46w → 23w

数据一致性容忍度比较高

&& 请求量不高

spu信息

缓存时间以秒为单位
缓存大小：偏小
失效策略：基于时间写入后失效
缓存命中率较低

数据一致性容忍度较低

或者

请求量巨大

sku信息

库存信息

缓存时间以分为单位
缓存大小：在售规格大小
失效策略：基于时间写入后失效 && 更新后失效【消息广播】
缓存命中率：高

sku：360w → 20w

库存：320w → 10w

4、后续展望

缓存数量大小：在目前的业务下，在售规格数量全部放进本地缓存里还能接受
库存变更频繁：下单引发的库存更新需要所有服务器处理广播消息，目前也能支持。

但是如果后续业务不断发展，则这种方案就会存在问题

1、库存本地缓存数量的大小

问题：在售库存数太多，不能够全部放进本地缓存里

目标：减少库存本地缓存的数量

方式：筛选热点数据，只针对热点数据进行本地缓存。

方案	Redis分布式统计	单机内存统计
特点	能够筛选出全局下的热点数据但是通过Redis计数反而会增加Redis压力	只能筛选单机下的热点数据，下次请求可能并不会请求到本地缓存机器众多，缓存命中率？？
实现方案	本地先统计，定时上报至Redis，比如30s上报一次，可通过异步方式实现。通过zset可以快速获取到热点数据
	本地统计 –> 异步上报

方案

Redis分布式统计

单机内存统计

特点

能够筛选出全局下的热点数据

但是通过Redis计数反而会增加Redis压力

只能筛选单机下的热点数据，下次请求可能并不会请求到本地缓存

机器众多，缓存命中率？？

实现方案

本地先统计，定时上报至Redis，比如30s上报一次，可通过异步方式实现。通过zset可以快速获取到热点数据

本地统计 –> 异步上报