最新发布
Redis 修炼之路【第20讲：滑动窗口限流器】
本文介绍了一种基于 Redis ZSet 实现的滑动窗口限流方案，用于防止接口被恶意高频调用。核心思路是将每次请求的时间戳作为 score 存入 ZSet，通过统计窗口期内元素数量判断是否超限。方案支持通过 pipeline 批量执行清理过期数据、添加记录、计数和设置过期时间等操作，并可按用户、接口或 IP 等不同维度进行限流控制。这种实现简单高效，能有效应对突发流量问题。
辰风沐阳 阅读 22 2026-07-23
RabbitMQ 消息队列【第35讲：订单超时自动取消】
电商订单超时自动取消功能的实现方案对比：传统定时任务扫描数据库方式存在延迟高、数据库压力大、扩展性差等问题；而采用 RabbitMQ 的 TTL + 死信队列机制，通过消息过期自动触发取消逻辑，具有实时性强、无数据库压力、扩展灵活等优势。关键实现步骤包括：下单时发送带TTL的消息，消息过期后转入死信队列，消费者处理时校验订单状态并执行原子性取消操作。该方案成为处理延迟任务的经典实践，比传统方案更高效可靠。
辰风沐阳 阅读 38 2026-07-23
RabbitMQ 消息队列【第34讲：异步发送邮件和短信】
本文通过用户注册场景介绍了 RabbitMQ 的应用价值。当注册流程需要同步调用不可控的外部服务（邮件/短信接口）时，会导致响应延迟和流程强耦合。作者对比了传统异步方案（数据库轮询）存在的延迟高、扩展难等问题，提出使用 RabbitMQ 将非核心操作异步化：注册成功后立即返回，通过消息队列实现短信/邮件的可靠投递，支持自动重试。进一步建议使用 Fanout Exchange 实现发布订阅模式，使注册系统与通知系统完全解耦。案例展示了消息队列在异步处理、系统解耦、可靠投递等方面的核心价值，为后续订单超时等复杂场景奠定基础
辰风沐阳 阅读 35 2026-07-22
Redis 修炼之路【第19讲：延迟队列实现】
本文介绍如何使用 Redis 的 ZSet 实现延迟队列功能。核心思路是将任务执行时间戳存入 ZSet 的 score，任务内容作为 member。通过 zrangebyscore 获取到期任务，配合 zrem 实现任务消费的原子性操作，防止重复执行。消费逻辑采用先删除再执行的策略，利用 zrem 返回值确保多 worker 安全。失败任务可通过重试机制处理，设置最大重试次数。该方法适用于简单场景，复杂需求建议使用专业消息队列如 RabbitMQ/RocketMQ。
辰风沐阳 阅读 21 2026-07-22
Redis 修炼之路【第18讲：Redis 分布式锁实战】
本文介绍了分布式系统中使用 Redis 实现锁机制的方法。核心问题在于多服务器并发操作库存导致的超卖情况。基础方案是使用 set NX EX 命令加锁，配合删除操作。但存在锁过期误删问题，需通过 UUID 标识锁归属，并用 Lua 脚本保证原子性释放。针对长任务需引入看门狗机制自动续期，推荐直接使用 Redisson 工具库实现。关键点包括：唯一标识防误删、原子操作脚本、自动续期设计，强调原理理解与实际工具使用并重。
辰风沐阳 阅读 29 2026-07-21
RabbitMQ 消息队列【第33讲：RabbitMQ 集群部署实战】
本文梳理了 RabbitMQ 集群部署的演进过程：从单机部署（易单点故障）→普通集群（解决连接分散但无数据冗余）→镜像队列（实现数据冗余但存在消息丢失风险）→最终推荐 Quorum Queue（可靠高可用方案）。文章强调理解各阶段解决的问题和局限性比记忆命令更重要，建议生产环境直接采用3节点奇数配置的 Quorum Queue 集群，配合负载均衡和监控。核心在于掌握不同方案的优劣，而非具体部署步骤。
辰风沐阳 阅读 48 2026-07-21
RabbitMQ 消息队列【第32讲：Quorum Queue 仲裁队列】
RabbitMQ 的 Quorum Queue（仲裁队列）是官方推荐的镜像队列替代方案，解决了异步同步导致的消息丢失、主节点瓶颈和脑裂风险三大问题。Quorum Queue 采用多数节点确认机制（如3节点需2个确认），确保消息可靠性和一致性，但需要奇数节点且性能略降。相比镜像队列，它显著提升了数据安全性，成为高可用场景的首选方案，尤其适合订单支付等关键业务，不过不支持优先级队列等部分高级功能。
辰风沐阳 阅读 54 2026-07-20
Redis 修炼之路【第17讲：缓存雪崩为什么这么危险】
缓存雪崩指大批 key 同时失效或 Redis 宕机，导致请求直接冲击数据库，比缓存穿透和击穿更严重。解决方案包括：为 key 设置随机过期时间避免同时失效、采用多级缓存（本地+Redis）、部署 Redis 高可用集群（哨兵/Cluster模式）、实施限流降级保护数据库。与穿透（查询不存在key）和击穿（热点key失效）相比，雪崩影响范围更广，需综合运用多种策略保障系统稳定性。
辰风沐阳 阅读 51 2026-07-20
Redis 修炼之路【第16讲：缓存击穿和热点 Key】
缓存击穿指热点 key 突然过期，导致大量请求直接冲击 MySQL。解决方案包括： 互斥锁：仅允许一个请求查询数据库，其他请求等待，可能影响用户体验； 逻辑过期：value 中存储逻辑过期时间，先返回旧数据并异步更新，平衡一致性与性能； 热点 Key 防护：提前缓存、延长过期时间或使用本地缓存（如Caffeine）。与缓存穿透（查询不存在的key）不同，缓存击穿针对热点 key 失效场景，需结合业务选择合适策略。
辰风沐阳 阅读 75 2026-07-19
RabbitMQ 消息队列【第31讲：镜像队列是什么】
本文介绍了 RabbitMQ 镜像队列的工作原理和特点。镜像队列通过将队列数据复制到多个节点实现高可用，包含一个主节点（负责读写）和多个镜像节点（负责备份）。当主节点故障时，系统会自动选择镜像节点接替。配置通过 Policy 实现，可选择全部或部分节点进行镜像。然而镜像队列存在性能开销大、主节点瓶颈、故障转移可靠性不足以及集群状态不一致风险等问题。正因如此，RabbitMQ 3.8 版本推出了 Quorum Queue 作为其替代方案。
辰风沐阳 阅读 69 2026-07-19
RabbitMQ 消息队列【第30讲：普通集群模式】
本文介绍了 RabbitMQ 普通集群的特点和局限性。普通集群通过多节点共享元数据实现连接分散，减轻单机压力，但队列数据仅存储在声明节点上，不具备数据冗余能力。当队列所在节点宕机时，该队列将不可用。因此普通集群只能解决连接分散问题，无法实现真正的高可用。文章通过具体场景说明这个容易被误解的特性，并指出要实现高可用需要使用镜像队列（将在下篇文章介绍）。关键结论：普通集群是"能用"而非"高可用"的解决方案。
辰风沐阳 阅读 82 2026-07-18
Redis 修炼之路【第15讲：缓存穿透到底怎么解决】
本文介绍了缓存穿透问题及其解决方案。当恶意请求大量不存在的数据时，请求会绕过缓存直接访问数据库，导致数据库过载。解决方案包括：1. 缓存空值，但会占用内存；2. 使用布隆过滤器预先过滤无效请求；3. 在接口层进行参数校验。三种方法结合使用可有效防止缓存穿透问题。
辰风沐阳 阅读 68 2026-07-18
