如何设计一个系统的 Redis 缓存以提高吞吐量和防止缓存雪崩？

每天来一次技术“灵魂”的考验。

对于一个业务复杂、高并发和大流量的系统，缓存是重要组成部分，提升系统性能的主要方式之一就是缓存。它可以挡掉大部分的数据库访问的冲击，如果没有它，系统很可能会因为数据库不可用导致整个系统崩溃。

缓存带来了另外一些棘手的问题：数据的一致性和实时性。

例如，数据库中的数据状态已经改变，但是在页面上看到的仍然是缓存的旧值，直到缓冲时间失效之后，才能重新更新缓存。这个问题怎么解决？

还有缓存数据如果没有失效的话，是会一直保持在内存中的，所以对服务器的内存也是负担，那么什么数据可以放缓存，什么数据不可以，这是系统设计之初必须考虑的问题。

什么数据可以放缓存？

1，不需要实时更新但是又极其消耗数据库的数据。比如网站首页的商品销售的排行榜，热搜商品等等，这些数据基本上都是一天统计一次，用户不会关注其是否是实时的。

2，需要实时更新，但是数据更新的频率不高的数据。

3，每次获取这些数据都经过复杂的处理逻辑，比如生成报表。

什么数据不应该使用缓存？

实际上，在电商系统中，大部分数据都是可以缓存的，不能使用缓存的数据很少。这类数据包括比如涉及到钱、密钥、业务关键性核心数据等。总之，如果你发现，系统里面的大部分数据都不能使用缓存，这说明架构本身出了问题。

如何解决一致性和实时性的问题？

保证一致性和实时性的办法就是：一旦数据库更新了，就必须把原来的缓存更新。

说一说我们的缓存方案：

我们目前的缓存系统：Redis（主从）+ RabbitMQ + 缓存清理服务组成，具体如下图：

缓存清理作业订阅 RabbitMQ消息队列，一有数据更新进入队列，就将数据重新更新到Redis缓存服务器。

当然，有些朋友的方案，是数据库更新完成之后，立马去更新相关缓存数据。这样就不需要MQ 和 缓存清理作业。不过，这同时也增加了系统的耦合性。具体得看自己的业务场景和平台大小。

缓存雪崩

缓存雪崩是由于原有缓存失效（过期），新缓存未到期间。所有请求都去查询数据库，而对数据库 CPU 和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

1. 碰到这种情况，一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。

2. 加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。

假设在高并发下，缓存重建期间key是锁着的，这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法。

3. 给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。

缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存。

缓存数据：它的过期时间比缓存标记的时间延长1倍，例：标记缓存时间30分钟，数据缓存设置为60分钟。 这样当缓存标记 key 过期后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存。

这样做后，可以一定程度上提高系统吞吐量。