随着互联网的普及，内容越来越复杂，用户和数据量越来越大，所以我们的应用应该支持更高的并发数，但是由于我们的服务器和数据库服务器资源量是有限的
所以如何更加高效的利用这有限的资源，并提供尽可能大的数据吞吐量？ 一个有效可行的办法就是引入缓存，打破数据流动的标准流程，有效提升响应速度，让有限的资源服务更多用户
缓存的使用可以出现在1～4的各个环节中，每个环节的缓存方案与使用各有特点。
图：互联网应用一般流程
命中率是缓存设置的重要指标，直接决定了该缓存对系统性能的影响。
1.业务场景和业务需求
缓存通常适合读多写少的业务场景，反之的使用意义并不多，命中率会很低。业务需求也决定了实时性的要求，直接影响到过期时间和更新策略，实时性要求越低越适合缓存。
2.缓存的设计（策略和粒度）
通常情况下缓存的粒度越小，命中率越高。比如说缓存一个用户信息的对象，只有当这个用户的信息发生变化的时候才更新缓存，而如果是缓存一个集合的话，集合中任何一个对象发生变化都要重新更新缓存。
当数据发生变化时，直接更新缓存的值比移除缓存或者让缓存过期它的命中率更高，不过这个时候系统的复杂度过高。
3.缓存的容量和基础设施
缓存的容量有限就会容易引起缓存的失效和被淘汰。目前多数的缓存框架和中间件都采用LRU这个算法。同时采用缓存的技术选型也是至关重要的，比如采用本地内置的应用缓存，就比较容易出现单机瓶颈。而采用分布式缓存就更加容易扩展。所以需要做好系统容量规划，系统是否可扩展。
一旦缓存中元素数量超过这个值（或者缓存数据所占空间超过其最大支持空间），那么将会触发缓存启动清空策略根据不同的场景合理的设置最大元素值往往可以一定程度上提高缓存的命中率，从而更有效的利用缓存。
虽然从硬件介质上来看，无非就是内存和硬盘两种，但从技术上，可以分成内存、硬盘文件、数据库。
FIFO/LFU/LRU/过期时间/随机
系统层面：
软件系统设计层面：
缓存有各类特征，而且有不同介质的区别，那么实际工程中我们怎么去对缓存分类呢? 在目前的应用服务框架中，比较常见的是根据缓存与应用的藕合度，分为local cache（本地缓存）和remote cache（分布式缓存）：
目前各种类型的缓存都活跃在成千上万的应用服务中，还没有一种缓存方案可以解决一切的业务场景或数据类型，我们需要根据自身的特殊场景和背景，选择最适合的缓存方案。缓存的使用是程序员、架构师的必备技能，好的程序员能根据数据类型、业务场景来准确判断使用何种类型的缓存，如何使用这种缓存，以最小的成本最快的效率达到最优的目的。
当数据时效性要求很高时，需要保证缓存中的数据与数据库中的保持一致，而且需要保证缓存节点和副本中的数据也保持一致，不能出现差异现象。这就比较依赖缓存的过期和更新策略。一般会在数据发生更改的时，主动更新缓存中的数据或者移除对应的缓存。
由于缓存的加入，数据并不能保证强一致性，只能保证最终一致性，所以在一些需要数据库强一致性的业务场景，缓存就不那么适用了。
redis缓存一致性
缓存过期后将尝试从后端数据库获取数据，这是一个看似合理的流程。但是，在高并发场景下，有可能多个请求并发的去从数据库获取数据，对后端数据库造成极大的冲击，甚至导致 “雪崩”现象。此外，当某个缓存key在被更新时，同时也可能被大量请求在获取，这也会导致一致性的问题。那如何避免类似问题呢? 我们会想到类似“锁”的机制，在缓存更新或者过期的情况下，先尝试获取到锁，当更新或者从数据库获取完成后再释放锁，其他的请求只需要牺牲一定的等待时间，即可直接从缓存中继续获取数据。
缓存击穿是访问一个存在的key,在缓存过期的一刻,同时有大量的请求,这些请求都会击穿到DB,造成瞬时DB请求量大、压力骤增。
缓存穿透是访问一个不存在的key,缓存不起作用,请求会穿透到DB,流量大时DB会挂掉。
在高并发场景下，如果某一个key被高并发访问，没有被命中，出于对容错性考虑，会尝试去从后端数据库中获取，从而导致了大量请求达到数据库，而当该key对应的数据本身就是空的情况下，这就导致数据库中并发的去执行了很多不必要的查询操作，从而导致巨大冲击和压力。
可以通过下面的几种常用方式来避免缓存传统问题：
对查询结果为空的对象也进行缓存，如果是集合，可以缓存一个空的集合（非null），如果是缓存单个对象，可以通过字段标识来区分。这样避免请求穿透到后端数据库。同时，也需要保证缓存数据的时效性。这种方式实现起来成本较低，比较适合命中不高，但可能被频繁更新的数据。
对所有可能对应数据为空的key进行统一的存放，并在请求前做拦截，这样避免请求穿透到后端数据库。这种方式实现起来相对复杂，比较适合命中不高，但是更新不频繁的数据。
缓存雪崩就是指由于缓存的原因，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难。导致这种现象的原因有很多种，上面提到的“缓存并发”，“缓存穿透”，“缓存颠簸”等问题，其实都可能会导致缓存雪崩现象发生。这些问题也可能会被恶意攻击者所利用。还有一种情况，例如某个时间点内，系统预加载的缓存周期性集中失效了，也可能会导致雪崩。为了避免这种周期性失效，可以通过设置不同的过期时间，来错开缓存过期，从而避免缓存集中失效。
从应用架构角度，我们可以通过限流、降级、熔断等手段来降低影响，也可以通过多级缓存来避免这种灾难。
此外，从整个研发体系流程的角度，应该加强压力测试，尽量模拟真实场景，尽早的暴露问题从而防范。
缓存抖动可以看做是一种比“雪崩”更轻微的故障，但是也会在一段时间内对系统造成冲击和性能影响。一般是由于缓存节点故障导致。业内推荐的做法是通过一致性Hash算法来解决。
不合理使用缓存非但不能提高系统的性能，还会成为系统的累赘，甚至风险。
如果缓存中保存的是频繁修改的数据，就会出现数据写入缓存后，应用还来不及读取缓存，数据就已经失效，徒增系统负担。一般来说，数据的读写比在2：1（写入一次缓存，在数据更新前至少读取两次）以上，缓存才有意义。
如果应用系统访问数据没有热点，不遵循二八定律，那么缓存就没有意义。
一般会对缓存的数据设置失效时间，一旦超过失效时间，就要从数据库中重新加载。因此要容忍一定时间的数据不一致，如卖家已经编辑了商品属性，但是需要过一段时间才能被买家看到。还有一种策略是数据更新立即更新缓存，不过这也会带来更多系统开销和事务一致性问题。
缓存会承担大部分数据库访问压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃时，数据库会因为完全不能承受如此大压力而宕机，导致网站不可用。这种情况被称作缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复。
实践中，有的网站通过缓存热备份等手段提高缓存可用性：当某台缓存服务器宕机时，将缓存访问切换到热备服务器上。但这种设计有违缓存的初衷，缓存根本就不应该当做一个可靠的数据源来使用。
通过分布式缓存服务器集群，将缓存数据分布到集群多台服务器上可在一定程度上改善缓存的可用性。当一台缓存服务器宕机时，只有部分缓存数据丢失，重新从数据库加载这部分数据不会产生很大的影响。
缓存中存放的是热点数据，热点数据又是缓存系统利用LRU（最近最久未用算法）对不断访问的数据筛选淘汰出来，这个过程需要花费较长的时间。新系统的缓存系统如果没有任何数据，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，那么最好在缓存系统启动时就把热点数据加载好，这个缓存预加载手段叫缓存预热。对于一些元数据如城市地名列表、类目信息，可以在启动时加载数据库中全部数据到缓存进行预热。
