缓存设计的典型方案
在使用缓存系统的时候，还需要考虑缓存设计的问题，重点在于缓存失效时的处理和如何更新缓存。
缓存失效是在使用缓存时不得不面对的问题。在业务开发中，缓存失效时由于找不到整个数据，一般会出于容错考虑，从存储层再进行查询，如果有则放入缓存。如果查找的数据在存储层根本就不存在，缓存失去意义，还会给后端服务带来巨大的请求压力，会进一步引起雪崩效应。这种现象又被称为缓存穿透。
目前常用的解决缓存穿透问题的方案如下。
1）在底层存储系统之上加一层布隆过滤器，将所有可能存在的数据哈希到一个足够大的BitMap中，一个一定不存在的数据会被这个BitMap拦截掉，从而避免了对底层存储系统的查询压力。
2）如果数据在存储层查询也为空，那么对此空结果也进行缓存，但要设置合适的失效时间。
更进一步地，解决缓存穿透问题其实和缓存的更新机制是相关的。缓存更新的常用3种模式如下。
Cache Aside Pattern：应用程序以数据库为准，失效则从底层存储更新，更新数据先
写入数据库再更新缓存。这是最常用的缓存更新模式。
Read/Write Through Pattern：以缓存为准，应用只读/写缓存，但是需要保证数据
同步更新到数据库中。
Write Behind Caching Pattern：以缓存为准，应用只读/写缓存，数据异步更新到数据库，不保证数据正确写回，会丢数据。可以采用Write Ahead Logging等机制避免丢数据。
如上，在缓存失效时采用何种策略去更新缓存，直接决定了能否解决缓存穿透的问题。Cache Aside Pattern 中缓存失效从底层存储更新，无法避免缓存穿透的问题。基于以上3种模式，采用下面更为细化的更新机制可以在一定程度上避免缓存穿透的问题。
缓存失效时，用加锁或者队列的方式单线程/进程去更新缓存并等待结果。
。缓存失效时，先使用旧值，同时异步（控制为同时只有一个线程/进程）更新缓存.
缓存更新失败则抛出异常。
.缓存失效时，先使用旧值，同时异步（控制为同时只有一个线程/进程）更新缓存，
缓存更新失败则延续旧值的有效期。
.数据写入或者修改时，更新数据存储后再更新缓存。缓存失效时即认为数据不存在。.数据写人或者修改时，只更新缓存，使用单独线程周期批量刷新缓存到底层存储。缓存失效时即认为数据不存在。这种方案不能保障数据的安全性，有可能会丢数据。、采用单独线程/ 进程周期将数据从底层存储放到缓存中。缓存失效时即认为数据不存在。这种方案无法保证缓存数据和底层存储的数据强一致性。
如果一开始设计缓存结构的时候注意切分粒度，把缓存力度划分得细一点，那么缓存
命中率相对会高，也能在一定程度上避免缓存穿透的问题。
此外，还可以在后端做流量控制、服务降级或者动态扩展，以应对缓存穿透带来的访
问压力。