1.Redis入门

什么是 Redis？

Redis 的使用场景，说到底就是两个关键词：高频访问 和 低延迟需求。只要是这两类问题，Redis 基本都能派上用场。最典型的当然是做缓存，尤其是那些读取频率高、更新频率低的数据，比如用户信息、商品详情、首页推荐内容。把这些热点数据放进 Redis，可以有效减少数据库压力，提升整体响应速度。

除此之外，像排行榜、实时计数、限流控制、登录状态存储这些场景，也很适合 Redis 来处理。例如使用 ZSet 可以轻松实现按分数排序的排行榜，比如直播打赏榜、热度文章榜等；利用 INCR 和 EXPIRE 可以实现精准的接口请求频控，避免刷接口带来的系统波动；甚至可以用 Redis 做一些简单的异步任务调度，比如基于 List 实现生产者-消费者模型，或用 Stream 做轻量消息流转，虽然不如 Kafka 专业，但在小流量系统中也足够灵活可靠。

需要特别提醒的是，缓存系统本身并不是百分百可靠的"保险箱"。在实际业务中，像缓存穿透、缓存击穿、缓存雪崩这些老问题，如果防护没做好，反而会让 Redis 成为压垮系统的导火索。所以不仅要设置合理的过期策略和热点预热机制，还要考虑空值缓存、互斥锁限流等兜底方案。

总而言之，Redis 是解决系统性能问题的一把利器，但这把刀要用在合适的位置，配上合适的策略，才能真正发挥威力。

---

使用 Redis 有哪些好处？

说白了，Redis的优势就是：速度快、结构灵活、功能强大。

• 速度快：数据都放在内存中，性能上直接碾压传统数据库，特别适合高QPS访问场景；
• 结构灵活：内建String、Hash、List、Set、ZSet等结构，能搞定从session共享到实时排行榜等一系列场景；
• 功能强大：支持AOF/RDB持久化，挂了还能恢复；支持哨兵+集群，宕了还能自动切换；甚至能写Lua脚本做原子操作。 另外值得注意的是，很多初学者容易忽视 Redis 的结构复杂性。以我自己的实践来看，如果能把 Redis 的基本命令与业务场景高度结合，会让系统设计变得更加清晰且性能更稳定。特别是大流量系统中，缓存设计和 Key 设计往往决定了系统的上限，越早重视，越少返工。

---

为什么 MySQL 做存储，Redis 做缓存？

简单来说：Redis是快枪手，MySQL是后勤兵。

我们这么设计，一方面是 职责分离，把读多写少、访问频繁的数据交给Redis缓存，减少MySQL的压力和慢查询；另一方面是 性能对比，Redis作为内存系统，读取延迟可以达到微秒级，而MySQL毕竟是磁盘IO为主的数据库，延迟在毫秒级。

当然这也带来了挑战，比如缓存一致性、过期策略、缓存穿透等问题，但这些都是可控的"代价"，相比带来的性能提升，是值得的。 另外值得注意的是，很多初学者容易忽视 Redis 的结构复杂性。以我自己的实践来看，如果能把 Redis 的基本命令与业务场景高度结合，会让系统设计变得更加清晰且性能更稳定。特别是大流量系统中，缓存设计和 Key 设计往往决定了系统的上限，越早重视，越少返工。

---

Redis 常用的业务场景有哪些？

以我的经验来看，Redis几乎是系统里的"万能胶水"，但常见高频场景主要有这几个：

• 缓存热点数据：比如首页推荐、用户资料、商品详情，读取频率高、更新不频繁，最适合放Redis；
• 分布式锁：基于SET NX机制，配合过期时间，能实现简单但可靠的分布式互斥控制；
• 排行榜系统：ZSet让你轻松搞定各种按分值排序的排行榜，比如直播打赏榜、文章热度榜；
• 限流和计数器：通过INCR/EXPIRE配合，实现接口限流、行为统计、请求计数等操作；
• 延时任务/消息队列：虽然不是专业队，但小场景里，List/Stream能"兼职"消息队列，用起来也够灵活。 另外值得注意的是，很多初学者容易忽视 Redis 的结构复杂性。以我自己的实践来看，如果能把 Redis 的基本命令与业务场景高度结合，会让系统设计变得更加清晰且性能更稳定。特别是大流量系统中，缓存设计和 Key 设计往往决定了系统的上限，越早重视，越少返工。

你有实际使用过Redis做什么应用么？

在实际应用中，Redis的应用场景非常丰富。对于没有太多实际经验的同学来说，建议重点掌握两个最常用的场景：缓存和分布式锁。这两个场景不仅应用广泛，而且能够很好地展示对Redis的理解。

在缓存场景中，Redis主要用于存储热点数据，比如用户信息、商品详情等。通过合理的缓存策略，可以显著提升系统的响应速度，减轻数据库压力。这个场景能够很好地展示对缓存原理的理解。

在分布式锁场景中，Redis的原子性特性使其成为实现分布式锁的理想选择。通过Redis实现的分布式锁，可以有效地解决分布式环境下的并发控制问题。这个场景能够展示对分布式系统设计的理解。