极简缓存架构通过JSR107规范，我们将框架定义为客户端层、缓存提供层、缓存管理层、缓存存储层。其中缓存存储层又分为基本存储层、LRU存储层和Weak存储层。其中：
客户端层：使用者直接通过该层与数据进行交互。
缓存提供层：主要对缓存管理层的生命周期进行维护，负责缓存管理层的创建，保存、获取以及销毁。
缓存管理层：主要对缓存客户端的生命周期进行维护，负责缓存客户端的创建，保存、获取以及销毁
缓存存储层：负责数据以什么样的形式进行存储。
基本存储层：是以普通的ConcurrentHashMap为存储核心,数据不淘汰。
LRU存储层：是以最近最少用为原则进行的数据存储和缓存淘汰机制。
Weak存储层：是以弱引用为原则的数据存储和缓存淘汰机制。
容量评估，缓存系统主要消耗的是服务器的内存，因此，在使用缓存时必须先对应用需要缓存的数据大小进行评估，包括缓存的数据结构、缓存大小、缓存数量、缓存的失效时间，然后根据业务情况自行推算在未来一定时间内的容量的使用情况，根据容量评估的结果来申请和分配缓存资源，否则会造成资源浪费或者缓存空间不够。
业务分离，建议将使用缓存的业务进行分离，核心业务和非核心业务使用不同的缓存实例，从物理上进行隔离，如果有条件，则请对每个业务使用单独的实例或者集群，以减小应用之间互相影响的可能性。笔者就经常听说有的公司应用了共享缓存，造成缓存数据被覆盖以及缓存数据错乱的线上事故。
监控为王，所有的缓存实例都需要添加监控，这是非常重要的，我们需要对慢查询、大对象、内存使用情况做可靠的监控。
失效时间，任何缓存的key都必须设定缓存失效时间，且失效时间不能集中在某一点，否则会导致缓存占满内存或者缓存雪崩。
大量Key同时失效时间的危害
在使用缓存时需要进行缓存设计，要充分考虑如何避免常见的缓存穿透、缓存雪崩、缓存并发等问题，尤其是对于高并发的缓存使用，需要对key的过期时间进行随机设置，例如，将过期时间设置为10秒+random(2)，也就是将过期时间随机设置成10～12秒。
先更新数据库后更新缓存有啥问题，如果两个线程同时执行更新操作，线程1更新数据库后，线程2也更新了数据库，然后开始写缓存，但线程2先执行了更新缓存的操作，而线程1在执行更新缓存的时候就把线程2更新的数据给覆盖掉了，这样就会出现数据不一致。
先删缓存，行不行，“先删缓存，然后执行数据库事务”也有人讨论这种方案，不过这种操作对于如商品这种查询非常频繁的业务不适用，因为在你删缓存的同时，已经有另一个系统来读缓存了，此时事务还没有提交。当然对于如用户维度的业务是可以考虑的。
数据库和缓存数据一致性；先更新数据库，再删除缓存的一种实践；本地缓存的挑战；缓存热点与多级缓存；缓存失效的连接风暴；缓存预热；超时时间设计；不要把缓存到存储；缓存崩溃解决之道；缓存崩溃后的快速恢复；开启Nginx Proxy Cache性能不升反降；网络抖动时，返回502错误，缘于timeout;应对恶意刷的经验；网卡打满了咋办；缓存组件的选择；