初次谈穿透、并发、失效
缓存穿透
注：
上面三个图会有什么问题呢？
我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。
那这种问题有什么好办法解决呢？
要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 有一个比较巧妙的作法是，可以将这个不存在的key预先设定一个值。 比如，”key” , “&&”。
在返回这个&&值的时候，我们的应用就可以认为这是不存在的key，那我们的应用就可以决定是否继续等待继续访问，还是放弃掉这次操作。如果继续等待访问，过一个时间轮询点后，再次请求这个key，如果取到的值不再是&&，则可以认为这时候key有值了，从而避免了透传到数据库，从而把大量的类似请求挡在了缓存之中。
缓存并发
有时候如果网站并发访问高，一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况，如果并发确实很大，这也可能造成DB压力过大，还有缓存频繁更新的问题。
我现在的想法是对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询。
这种情况和刚才说的预先设定值问题有些类似，只不过利用锁的方式，会造成部分请求等待。
缓存失效
引起这个问题的主要原因还是高并发的时候，平时我们设定一个缓存的过期时间时，可能有一些会设置1分钟啊，5分钟这些，并发很高时可能会出在某一个时间同时生成了很多的缓存，并且过期时间都一样，这个时候就可能引发一当过期时间到后，这些缓存同时失效，请求全部转发到DB，DB可能会压力过重。
那如何解决这些问题呢？
其中的一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
我们讨论的第二个问题时针对同一个缓存，第三个问题时针对很多缓存。
总结来看
- 缓存穿透：查询一个必然不存在的数据。比如文章表，查询一个不存在的id，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成影响。
- 缓存失效：如果缓存集中在一段时间内失效，DB的压力凸显。这个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。
当发生大量的缓存穿透，例如对某个失效的缓存的大并发访问就造成了缓存雪崩。
再谈缓存穿透与并发
相信不少朋友之前看过很多类似的文章，但是归根结底就是二个问题：
- 如何解决穿透
- 如何解决并发
当并发较高的时候，其实我是不建议使用缓存过期这个策略的，我更希望缓存一直存在，通过后台系统来更新缓存系统中的数据达到数据的一致性目的，有的朋友可能会质疑，如果缓存系统挂了怎么办，这样数据库更新了但是缓存没有更新，没有达到一致性的状态。
解决问题的思路是：
如果缓存是因为网络问题没有更新成功数据，那么建议重试几次，如果依然没有更新成功则认为缓存系统出错不可用，这时候客户端会将数据的KEY插入到消息系统中，消息系统可以过滤相同的KEY，只需保证消息系统不存在相同的KEY，当缓存系统恢复可用的时候，依次从mq中取出KEY值然后从数据库中读取最新的数据更新缓存。
**注意：**更新缓存之前，缓存中依然有旧数据，所以不会造成缓存穿透。
下图展示了整个思路的过程：
看完上面的方案以后，又会有不少朋友提出疑问，如果我是第一次使用缓存或者缓存中暂时没有我需要的数据，那又该如何处理呢？
解决问题的思路：
在这种场景下，客户端从缓存中根据KEY读取数据，如果读到了数据则流程结束，如果没有读到数据（可能会有多个并发都没有读到数据），这时候使用缓存系统中的setNX方法设置一个值（这种方法类似加个锁），没有设置成功的请求则sleep一段时间，设置成功的请求读取数据库获取值，如果获取到则更新缓存，流程结束，之前sleep的请求这时候唤醒后直接再从缓存中读取数据，此时流程结束。
在看完这个流程后，我想这里面会有一个漏洞，如果数据库中没有我们需要的数据该怎么处理，如果不处理则请求会造成死循环，不断的在缓存和数据库中查询，这时候我们会沿用我之前文章中的如果没有读到数据则往缓存中插入一个NULL字符串的思路，这样其他请求直接就可以根据“NULL”进行处理，直到后台系统在数据库成功插入数据后同步更新清理NULL数据和更新缓存。
流程图如下所示：
总结：
在实际工作中，我们往往将上面二个方案组合使用才能达到最佳效果，虽然第二种方案也会造成请求阻塞，但是只是在第一次使用或者缓存暂时没有数据的情况下才会产生，在生产中经过检验在TPS没有上万的情况下是不会造成问题的。
热点缓存解决方案
缓存使用背景
我们拿用户中心的一个案例来说明： 每个用户都会首先获取自己的用户信息，然后再进行其他相关的操作，有可能会有如下一些场景情况：
- 会有大量相同用户重复访问该项目。
- 会有同一用户频繁访问同一模块。
思路解析
- 因为用户本身是不固定的而且用户数量也有几百万尤其上千万，我们不可能把所有的用户信息全部缓存起来，通过第一个场景情况可以看到一些规律，那就是有大量的相同用户重复访问，但是究竟是哪些用户重复访问我们也并不知道。
- 如果有一个用户频繁刷新读取项目，那么对数据库本身也会造成较大压力，当然我们也会有相关的保护机制来确实恶意攻击，可以从前端控制，也可以有采黑名单等机制，这里不在赘述。如果用缓存的话，我们又该如何控制同一用户繁重读取用户信息呢。
请看下图：
我们会通过缓存系统做一个排序队列，比如1000个用户，系统会根据用户的访问时间更新用户信息的时间，越是最近访问的用户排名越排前，系统会定期过滤掉排名最后的200个用户，然后再从数据库中随机取出200个用户加入队列，这样请求每次到达的时候，会先从队列中获取用户信息，如果命中则根据userId，再从另一个缓存数据结构中读取用户信息，如果没有命中则说明该用户请求频率不高。
实现缓存最终一致性的二种方案
重客户端
写入缓存：
- 应用同时更新数据库和缓存
- 如果数据库更新成功，则开始更新缓存，否则如果数据库更新失败，则整个更新过程失败。
- 判断更新缓存是否成功，如果成功则返回
- 如果缓存没有更新成功，则将数据发到MQ中
- 应用监控MQ通道，收到消息后继续更新Redis。
**问题点：**如果更新Redis失败，同时在将数据发到MQ之前的时间，应用重启了，这时候MQ就没有需要更新的数据，如果Redis对所有数据没有设置过期时间，同时在读多写少的场景下，只能通过人工介入来更新缓存。
读缓存：
如何来解决这个问题？那么在写入Redis数据的时候，在数据中增加一个时间戳插入到Redis中。在从Redis中读取数据的时候，首先要判断一下当前时间有没有过期，如果没有则从缓存中读取，如果过期了则从数据库中读取最新数据覆盖当前Redis数据并更新时间戳。具体过程如下图所示：
客户端数据库与缓存解耦
上述方案对于应用的研发人员来讲比较重，需要研发人员同时考虑数据库和Redis是否成功来做不同方案，如何让研发人员只关注数据库层面，而不用关心缓存层呢？请看下图：
- 应用直接写数据到数据库中。
- 数据库更新binlog日志。
- 利用Canal中间件读取binlog日志。
- Canal借助于限流组件按频率将数据发到MQ中。
- 应用监控MQ通道，将MQ的数据更新到Redis缓存中。
可以看到这种方案对研发人员来说比较轻量，不用关心缓存层面，而且这个方案虽然比较重，但是却容易形成统一的解决方案。
整理于：http://www.spring4all.com
