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