当前位置：首页 > 问答 > 正文

Redis那些理论和实践结合的真实案例分享，帮你更懂redis怎么用

Redis作为一个高性能的键值数据库,很多人知道它快，但到底怎么把它用在实际项目中解决实际问题，可能就比较模糊了，下面我就分享几个把Redis理论和实践结合起来的真实案例，让你看看Redis是怎么在真实场景中发挥威力的。

秒杀系统——用Redis抵挡第一波洪峰（理论：高性能与原子操作）

秒杀的场景大家都不陌生,比如限量100件商品，瞬间有10万人来抢，如果所有请求都直接打到数据库上，数据库瞬间就会崩溃，这时候，Redis就成为了一个完美的“前台”。

实践方案：
1. 预热库存： 在秒杀开始前，先把商品库存（比如100件）提前设置到Redis中，用一个简单的键值对，如 seckill:item:123:stock，值为100。
2. 判断与扣减： 用户点击秒杀时，系统并不直接操作数据库，而是先访问Redis，这里的关键是使用Redis的原子操作DECR（递减），每个请求过来，就对 seckill:item:123:stock 执行一次DECR命令。
3. 原子性的重要性： DECR命令是原子性的，意味着在并发环境下，多个请求同时执行这个命令，Redis会确保每个请求都能得到唯一且正确的结果值，执行后，如果返回值大于等于0，说明用户抢购成功；如果返回值小于0，说明库存已售罄。
4. 后续处理： 抢购成功的用户，系统会将其订单信息写入消息队列，再由后台服务异步地、平稳地写入数据库，完成后续的支付等流程。
怎么懂了Redis： 这个案例让你看到，Redis不仅仅是做个简单的缓存，它的高性能和原子操作能力，可以作为一个临时的“计数器”或“库存中心”，完美解决了高并发下数据一致性和系统承压的核心难题。

社交媒体的好友关注与粉丝列表——用Redis的Set实现（理论：丰富的数据结构）

在微博或抖音这样的应用中,你需要快速查询“我关注了谁”、“谁关注了我”，以及“我们的共同好友是谁”，如果用数据库的关联表来查，当用户关系量达到亿级时，查询效率会非常低。

实践方案：
1. 数据结构选择： Redis提供了Set（集合）数据结构，它天生适合存储不重复的元素，并且支持求交集、并集、差集等操作。
2. 存储关系： 为每个用户创建两个Set：
  - follows:user:id：存储这个用户关注的所有人的ID。
  - fans:user:id：存储所有关注这个用户的人的ID。
3. 操作实现：
  - 关注操作： 当用户A关注用户B时，使用SADD命令向 follows:user:A 集合添加用户B的ID，同时向 fans:user:B 集合添加用户A的ID。
  - 查看共同关注： 想知道用户A和用户C共同关注了谁？直接使用SINTER命令求 follows:user:A 和 follows:user:C 两个集合的交集，结果瞬间就出来了。
  - 可能认识的人： 可以计算“关注我的人还关注了谁”，比如用 SDIFF 命令求 follows:user:B (B是A的粉丝) 和 follows:user:A (A自己已经关注的) 的差集，来给A做推荐。
怎么懂了Redis： 这个案例展示了Redis丰富的数据结构的威力，与其把所有数据都当成简单的Key-Value，不如根据业务场景选择最合适的结构，Set结构让复杂的关系运算变得简单而高效，这是传统关系数据库难以比拟的。

新闻App的首页信息流——用Redis做多级缓存（理论：缓存策略与过期机制）

新闻App的首页需要聚合很多内容：热点新闻、用户个性化推荐、关注的博主动态等，这些数据来源不同，查询复杂，直接读数据库压力巨大。

实践方案：
1. 多级缓存设计：
  - 第一级：本地缓存（如Caffeine）： 在应用服务器本地缓存一些全站最热门的新闻ID列表，响应速度极快，但容量小，且无法在多个服务器间共享。
  - 第二级：Redis缓存： 缓存更大量的数据，
    - 热点数据： 设置一个hot_news的key，存储排名前1000的热点新闻ID列表，并设置一个较短的过期时间（如5分钟），保证热点内容的时效性。
    - 个性化列表： 为每个用户生成一个信息流列表的Key，如 feed:user:id，存储为其个性化推荐的新闻ID列表，这个列表的过期时间可以设置得长一些（如1小时），因为用户的兴趣不会瞬间改变。
2. 缓存更新策略：
  - 当有新的热点事件产生时,系统会主动更新Redis中的hot_news Key。
  - 当用户主动刷新首页时,可能会触发一次新的个性化计算，并更新其个人的 feed:user:id。
  - 通过给Key设置合理的过期时间（TTL），即使更新程序出问题，缓存也能自动失效，然后从数据库重新加载，保证数据的最终一致性。
怎么懂了Redis： 这个案例说明了缓存不是简单地把数据库查询结果存起来就行了，它需要设计，比如分层（本地+远程）、分类（全局数据+用户数据），并配合灵活的过期策略，才能在保证性能的同时，兼顾数据的准确性和新鲜度。

分布式锁——控制分布式系统有序工作（理论：单线程与SETNX命令）

在分布式系统中,多个服务实例可能同时要处理同一个任务（比如定时给用户发优惠券），但同一个任务我们只希望它被执行一次。

实践方案：
1. 获取锁： 使用Redis的SET key value NX PX milliseconds命令，NX表示只有当Key不存在时才能设置成功（即获取锁），PX给这个Key设置一个毫秒级的过期时间。SET lock:send_coupon_20241111 server01 NX PX 10000，如果返回OK，说明server01这个服务器成功获取了锁，有效期10秒。
2. 为什么这样设计：
  - NX： 保证了互斥性，同一时间只有一个客户端能设置成功。
  - PX： 设置了过期时间，避免了因为持有锁的服务器崩溃而导致的“死锁”问题，即使server01挂了，10秒后锁也会自动释放。
  - Value设置为唯一标识： 防止误删，假设server01执行任务超时（超过10秒），锁自动释放了，此时server02拿到了锁，如果这时server01执行完了，它不能简单地根据Key来删除锁，否则会删掉server02的锁，所以它需要检查Value是不是自己当初设置的server01，如果是才删除（这需要Lua脚本保证原子性）。
3. 释放锁： 任务完成后，通过执行一段Lua脚本来原子性地判断Value并删除Key。
怎么懂了Redis： 这个案例利用了Redis单线程执行命令的特性（保证了NX操作的原子性）和灵活的键值操作，实现了一个简单却非常实用的分布式协调工具，它让你看到Redis的用途可以远远超出“缓存”的范畴。