Nresource服务日均4.5亿流量，考虑到未来流量急增场景，我们打算对大流量接口进行缓存化处理；根据服务管理平台数据统计显示getUsableResoureCount接口调用量很大，接近40%，故对此接口进行缓存化处理。
2、 方案调研
getUsableResoureCount接口用途：获取用户的可用资源数，契约为：Map<String, Integer> getUsableResoureCount(long userId, int resourceType, ResourceCountTypeEnum typeEnum, List<Integer> cities, List<Integer> caties) throws Exception；支持传入资源数类型（全国/本地）多城市和多类目按照包含的策略进行资源过滤；
由于资源库存表设计字段：城市和类目写入格式为：1,2,3，即以逗号组合的字符串，所以如果缓存用户对应城市和类目的所有余量，实现难度大且意义不大。
通过对接口返回值的观察，我们发现getUsableResoureCount接口返回值很多都是查询用户所有资源余量，不区分城市和类目，且查询结果都为0，所以我们切换思路：是不是可以把这些无余量的数据缓存起来？
通过2021-07-27 10:00:00数据统计我们发现，单节点一分钟getUsableResoureCount接口调用量为395，其中查询所有资源余量的微287，返回值为0的为183，接近46%的请求是无数据的，所以缓存用户无余量的数据是有意义的，能挡住接近50%的无用请求。
缓存用户无余量的数据，我们需要在所有涉及余量增减的操作，同时维护redis中余量变化，如何维护db与缓存中数据的一致性，也是面临的问题，所以我们想：可不可以不缓存余量，只缓存一个余量标识，这样既能挡住无用请求，又不需要维护db与缓存的数据一致性呢？参考布隆过滤器，我们决定对此接口进行缓存余量标识，只记录有还是没有，即1和0。
3、 方案实施
getUsableResoureCount接口先查询缓存，如果返回值为0，则放入缓存，所有增加余量的操作均需要更新redis标识为1。基本目标就是：保证更新标识为有的操作一定成功。考虑到服务并发，写操作（更新redis标识为1）可能会被读操作（更新redis标识为0）覆盖，所以更新redis标识为0的时候，先增加时间校验即晚一分钟更新，因为redis标识更新为0或null，不会影响最终查询，而是会查询db，晚一分钟又可以避免读写覆盖的问题。最终采用lua脚本实现读操作，而写操作采用同步set异步重试保证最终成功；
lua脚本如下：
4、最终效果
接口响应耗时：
2021.9.2 VS 2021.9.9
2021.9.8 VS 2021.9.9
性能提升(ms)：1.4 -> 0.9 提升超过30%
整体服务响应耗时：
2021.9.8 VS 2021.9.9
性能提升(ms)：1.8 -> 1.6 提升超过10%
缓存命中率统计：
服务节点：10.***.60.***
命中率接近80%
5、未来考量
1）缓存的扩展性，未来新的写接口需要更新redis标识为1；
2）缓存的接口适配性，考虑更多查询接口应用缓存；
ps: 整体思路，由于业务原因，没有采用传统缓存用redis存有效数据的思路，我们是反其道行之，用redis来挡住无效流量