双缓存架构实践

在一些高并发场景下,不仅追求RT也寄希望于抗住超高的流量.比如像首页营销位、banner位、排行榜等,不仅用户点击量大,而且接口响应必须快,不然给用户有明显的延迟感.但是这些模块有一个共同的特点,一般只有在运营需要做活动的时候才会变更一下图片、顺序、用户标签等之类的基础信息.单纯的Db是很难扛住大流量的,redis作为高性能非关系型数据库虽然有良好的表现,但是网络IO瓶颈和带宽之类的问题无法解决.本文将设计一个双缓存的架构模型来解决首页底部金刚位动态展示的功能.

1. 技术选型

springboot+rocketMq+redisCluster+caffeineCache

2. Caffeine

Caffeine是新出现的一个高性能的Java缓存，在springcontext5.x之后不在支持Guava Cache，Caffeine采用了W-TinyLFU回收策略，集合了LRU和LFU的优点，提供了一个最佳的命中率，在效率上可以秒杀Guava Cache.

image.png

3. 为什么不用redis

首先redis存储结构选型上只能是String或者Hash,其他结构都不适合随机删除.对于集群模式下的批量获取,在redis3.x即redis集群架构体系下，是没有mget这个命令的,再有这批量的id分布在不同的节点上,在高并发下网络IO会成为一个瓶颈.如果采用for循环get,性能会大打折扣.这里我们用本地缓存来解决这种可遇见未来的访问,还能很好的解决网络IO开销问题.

4. 集群模式下的消息一致性问题

Caffeine是本地缓存,底层是基于ConCurrentHashMap.所以一旦需要更新本地缓存,是无法是同步其他节点消息.那解决办法有吗?答案当然是有的, 本文提供几种解决思路.
1).Caffeine提供提供了定时刷新机制,但是很遗憾不太适合我这种场景,因为我们的广告位很少有变更,甚至几周变一次,我们无法精确评估其失效时机,失效太快会频繁更新ConCurrentHashMap
2).基于redis做pub-sub,广播订阅机制(痛点就是消息发送即丢失)
3).基于mQ的广播消费的模式去同步所有节点的信息