分布式多级缓存设计方案，解决海量数据读取的性能问题，包含多级缓存的存储设计，流程设计；利用多数据副本保证数据的可用性，同时通过不同数据源特点提供更高性能、更多场景数据差异化的支持

今天我们来聊聊缓存这个话题，看看在微服务环境下如何设计有效的多级缓存架构。主要涉及三方面内容： Web 应用的客户端缓存； 应用层静态资源缓存； 服务层多级缓存

对于高并发系统来说，有三个重要的机制来保障其高效运行，它们分别是：缓存、限流和熔断。而缓存是排在最前面也是高并发系统之所以高效运行的关键手段，那么问题来了：缓存只使用 Redis 就够了吗？ 1.冗余

@[TOC] 一、背景 公司想对一些不经常变动的数据做一些本地缓存，我们使用AOP+Caffeine来实现 二、实现 1、定义注解 2、切面 3、缓存工具类 三、测试

背景 项目开发中对于缓存使用的不规范，如redis工具类使用五花八门，配置五花八门，生成key不规范，存储数据，序列化等不规范，对于缓存使用场景无法精确把控缓存使用粒度，对于缓存规模无法预估，缓存击穿

redis 作为常用中间件，虽然我们一般业务系统（毕竟业务量有限）不会遇到如下图 在随着 data-size 的增大和数据结构的复杂的造成性能下降，但网络 IO 消耗会成为整个调用链路中不可忽视的部分。尤其在 微服务架构中，一次调用往往会涉及多次调用 例如pig oauth2.…

多级缓存设计案例 从用户发出请求到最底层的数据库，实际上会经过多个节点。因此，在整个链路上都可以设置缓存。根据缓存最近原则，将缓存放置在离用户最近的位置可以最大限度地提高系统响应效率，并明显提升系统的

项目场景： 有位同事因为缓存被后台删除，导致一堆高并发请求直接怼到DB上，导致数据库cpu 100% 解决方案： 处理缓存击穿问题：像布隆过滤器，或者说提前设置热点key 就是热点key检测，这里谈到

社交直播缓存管道上线快1年时间，从派对房选取一个小业务作为试点开始，如今已经大规模应用在了社交直播活动业务中，很关键的支持了活动扩展点组件、活动交易平台的发展。