Redis缓存真有那么神奇吗？聊聊它怎么帮我们减轻数据流量压力

（引用来源：知乎专栏“架构师之路”、Redis官方文档、多位资深后端开发者的经验分享）

Redis缓存真有那么神奇吗？这个问题问得好，说实话，对于没接触过它的人来说，它可能被传得神乎其神，但一旦你明白了它的核心工作原理，你就会发现，它的“神奇”之处并不在于用了多高深的技术，而在于它用一种非常巧妙且直接的方式，击中了现代互联网应用的一个普遍痛点——高并发下的数据读取压力，它就像一个设置在你家门口的超高效快递驿站，让你不用每次都跑大老远去邮局取件，极大地节省了你的时间和体力。

要理解Redis如何帮我们减轻数据流量压力,我们得先看看在没有它的时候，系统是怎么工作的，想象一下一个热门电商网站的场景，双十一”期间，成千上万的用户同时在刷新首页，查看热门商品信息，这些商品信息，比如名称、价格、库存，都存放在一个核心的数据库里（比如MySQL），如果每次用户点开页面，我们的服务器都直接去这个数据库里查询数据，会发生什么？数据库就像是一个兢兢业业但处理能力有限的柜台服务员，每秒钟能服务的客户（即处理的数据查询请求）是有上限的，当几万、几十万人同时涌过来问同一个问题：“这个手机卖多少钱？”时，这个服务员很快就会不堪重负，响应速度变慢，甚至直接“崩溃”宕机，结果就是，用户页面加载不出来，一直转圈圈，体验极差，这就是我们常说的“数据库压力过大”。

Redis是怎么解决这个问题的呢？它的角色就是插在应用程序和核心数据库之间的一个“高速临时存储器”，它把数据库中最常被访问的数据（比如那款热门手机的信息），提前拷贝一份，放在自己的“地盘”里，Redis最厉害的地方是，它这个“地盘”是建在服务器的内存（RAM）里的，内存的读写速度，比硬盘（数据库通常数据存储在硬盘上）要快成千上万倍，几乎是瞬间完成。

我们再来看那个场景：当第一个用户来查询手机价格时，系统还是会去数据库里取数据，但在把数据返回给用户的同时，系统会“多留一个心眼”，把这份数据也写到Redis缓存里，并设置一个有效期（比如5分钟），在接下来的5分钟内，如果有第二个、第三个乃至第一万个用户再来查询同一款手机的信息，系统就不再需要去“打扰”那个已经忙不过来的数据库服务员了，而是直接转向速度极快的Redis问：“嘿，那款手机的信息你有吗？”Redis立刻就能从内存里把数据返回，这样一来，绝大部分的读取请求都被Redis轻松消化掉了，真正到达数据库的请求量可能只剩下原来的百分之一甚至更少，数据库的压力瞬间就被卸掉了，自然就能保持流畅运行，这就好比在去邮局的主干道上开了一个便民驿站，大部分人都能在驿站直接取到包裹，只有驿站没有的包裹才需要去邮局，邮局门口自然就不堵了。

除了这种最基本的“减轻数据库读压力”，Redis还能在其他方面帮我们“分流”：

应对“秒杀”场景，秒杀开始时，海量用户同时点击“下单”，如果每个请求都直接去数据库里扣减库存，数据库绝对瞬间崩溃，这时候，可以先用Redis来预存商品库存数量，用户的秒杀请求先到达Redis，Redis利用其单线程和原子操作的优势，确保在高并发下也能准确无误地完成库存的扣减，只有那些成功在Redis里抢到购买资格的用户请求，才会被允许进入后续的数据库下单流程，这样，数据库只处理成功的订单，流量压力变得可控。

再比如,存储用户的登录会话信息，用户登录后，系统会生成一个标识用户身份的令牌（Token），如果把这个令牌对应的用户信息直接存在Redis里，那么后续用户访问网站的任何页面，服务器只需要快速查询一下Redis，就能知道你是谁，而不用每次都去查询用户数据库，这对于分布式系统尤其重要，无论用户的请求被分配到哪台服务器上，这台服务器都能通过访问同一个Redis来获取用户的登录状态，实现了“无状态”服务，大大提升了系统的扩展性。

Redis也不是万能的银弹,它作为缓存，数据是临时存储在内存中的，存在丢失的风险（虽然有其持久化机制，但主要还是用于缓存），所以绝对不能用来替代数据库存储核心的、不能丢失的数据，它更像是一个完美的“僚机”，辅助主数据库（主机）完成高并发的任务。

回到最初的问题,Redis缓存神奇吗？说它神奇，是因为它用相对简单的思路——用内存的高速读写来弥补硬盘数据库的并发瓶颈——就解决了困扰众多大型网站的核心难题，说它不神奇，是因为它的原理一旦点破，就显得那么直观和必然，它就像给高速运转的数字世界加了一个“超级缓冲区”，默默无闻地扛住了我们每一次刷新、每一次点击背后汹涌的数据洪流，让我们能够享受流畅的互联网体验，这，就是它实实在在的价值。