最新发布
RabbitMQ 消息队列【第24讲：延迟队列实现方案】
本文介绍了延迟队列的三种实现方案及其适用场景。延迟队列用于管理未来某个时间点执行的任务，如订单超时取消、会议提醒等。经典方案是 RabbitMQ 的TTL+DLX 组合，适合固定时长的延迟需求；RabbitMQ 官方延迟插件更灵活但需额外安装；Redis 方案则适合已有 Redis 的项目，但需自行实现定时任务。作者建议根据项目现状选择最简单可行的方案，多数情况下 TTL+DLX 已能满足需求，避免为简单需求引入复杂方案。
辰风沐阳 阅读 37 2026-07-11
RabbitMQ 消息队列【第23讲：死信队列 DLX】
本文介绍了 RabbitMQ 死信队列（DLX）的实现与应用。主要内容包括： 死信概念：消息过期、消费者拒收或队列满时，消息会变成死信，需通过死信队列处理。 DLX 机制：死信队列是一个普通 Exchange，用于接收死信并路由到指定队列，无需额外代码。 实现步骤： 声明死信 Exchange 和队列（如dlx_exchange和timeout_queue）。 业务队列绑定 DLX 参数（x-dead-letter-exchange和路由键）。 消息过期后自动转发至死信队列，触发取消订单等逻辑。
辰风沐阳 阅读 50 2026-07-10
Redis 修炼之路【第8讲：Hash 适合存对象吗】
本文介绍了 Redis 中 Hash 类型的特点和应用场景。Hash 支持在单个 key 下存储多个字段，可独立读写字段值，避免了 String 类型存 JSON 时整体读写的弊端。底层采用 ziplist（字段少时）或 hashtable（字段多时）两种编码结构。与 String 存 JSON 相比，Hash 适合字段多、频繁修改单个字段的场景，如用户信息、商品详情等，并以购物车为例展示了具体操作命令。String 则更适合字段少、整体读写的场景。Hash 提供了更灵活高效的对象存储方案。
辰风沐阳 阅读 48 2026-07-10
RabbitMQ 消息队列【第22讲：消息过期 TTL】
本文介绍了如何利用消息队列实现电商订单30分钟未支付自动取消的功能。传统定时任务扫表方案存在延迟、资源浪费和数据库压力问题，而基于 RabbitMQ 的 TTL（Time To Live）机制可以更高效地实现这一需求。TTL 允许为消息设置过期时间，超过时间未消费的消息将被丢弃或转入死信队列。文章详细说明了两种 TTL 设置方式（单条消息设置和队列级别设置），并给出了代码示例。同时指出单纯 TTL 的局限性，为后续介绍死信队列（DLX）解决方案做了铺垫。
辰风沐阳 阅读 47 2026-07-09
Redis 修炼之路【第7讲：String 为什么是万能结构】
Redis 的 String 结构底层采用 SDS（Simple Dynamic String），相比C原生字符串具有 O(1) 获取长度和二进制安全的优势。String 支持三种编码（int、embstr、raw），根据数据自动选择以优化内存和性能。其应用场景广泛： 缓存：存储高频查询结果，减轻数据库压力； 计数器：原子操作incr实现阅读量、点赞统计； 分布式锁：基础版通过 set nx ex 实现； 验证码：设置过期时间自动清理； 分布式 Session：解决多服务器 Session 共享问题。
辰风沐阳 阅读 50 2026-07-09
RabbitMQ 消息队列【第21讲：日志分级系统实战】
本文介绍了如何利用 RabbitMQ 的 Topic Exchange 实现日志分级处理系统。系统将日志分为 info、warning、error 三个级别，分别对应不同的处理方式：存储分析、监控统计和实时告警。通过模块.级别的路由规则（如order.error），配合通配符绑定（.error、.warning、*.info和#），实现日志的精准分流到不同队列。文章提供了 PHP 代码示例展示 Exchange 声明、队列绑定、消息发布和消费逻辑，并验证了不同级别日志能正确路由到对应队列。
辰风沐阳 阅读 55 2026-07-08
Redis 修炼之路【第6讲：Redis 为什么是单线程】
Redis 的单线程设计解析：6.0版本后网络IO多线程化，但命令执行仍保持单线程。单线程优势在于避免锁竞争和上下文切换，内存操作速度极快（纳秒级），性能瓶颈主要在网络IO。6.0引入多线程处理网络请求（配置4-8个线程），但核心逻辑保持单线程以保证简单高效。需警惕大key和慢命令（如keys*/hgetall等）造成的阻塞风险，建议使用scan系列命令替代。该设计平衡了性能与复杂度，网络吞吐成为主要优化方向。
辰风沐阳 阅读 62 2026-07-08
RabbitMQ 消息队列【第20讲：Headers Exchange 头匹配】
本文介绍了 RabbitMQ 中的 Headers Exchange，它通过消息头属性（headers）而非路由键（routing key）进行消息路由，支持多维度键值对匹配，提供 all（全匹配）和 any（任一匹配）两种模式。相比 Topic Exchange，Headers Exchange 灵活性更高但性能较差，实际使用频率较低，仅适用于消息维度复杂、需多属性组合匹配的场景。文中对比了四种 Exchange 类型：Direct（精确匹配）、Fanout（广播）、Topic（通配符匹配）和 Headers（属性匹配）
辰风沐阳 阅读 38 2026-07-07
Redis 修炼之路【第5讲：Redis 常用命令实战】
本文介绍了 Redis 常用命令操作，分为 Key 操作和五大核心数据结构（String、Hash、List、Set、ZSet）的使用方法。主要内容包括：keys/del/ttl 等通用命令；字符串的 incr/setnx 操作；哈希表的字段管理；列表的阻塞弹出；集合的运算操作；有序集合的排名控制等。还给出了 info/dbsize 等管理命令，并强调生产环境避免使用 keys * 和 flushdb 危险命令。作者建议读者通过实践掌握这些基础操作，为后续理解Redis单线程特性等高级话题打下基础。
辰风沐阳 阅读 54 2026-07-07
RabbitMQ 消息队列【第19讲：Topic Exchange 通配符路由】
本文介绍了 RabbitMQ 的 Topic Exchange 模式。该模式通过通配符匹配规则实现灵活的消息路由，解决了 Direct Exchange 精确匹配和 Fanout Exchange 全量广播的局限性。 核心要点： 通配符规则： *匹配一个词（如*.error匹配order.error） #匹配多个词（如order.#匹配order.error/order.info等） 典型应用场景： 日志分级收集系统 按模块/类型批量分发消息 需要灵活路由规则的业务场景
辰风沐阳 阅读 50 2026-07-06
Redis 修炼之路【第4讲：Redis 五大核心数据结构】
Redis 核心数据结构包括5种类型：String（字符串，适合存单值/计数器）、Hash（哈希，适合存对象字段）、List（列表，支持队列操作）、Set（集合，自动去重并支持集合运算）、ZSet（有序集合，带分数排序）。String 使用存单值，Hash 适合存对象，List 可实现消息队列，Set 能高效处理共同好友等场景，ZSet 天然支持排行榜。选择依据数据特性：单值用 String，对象用 Hash，队列用 List，去重用 Set，排序用 ZSet。这些结构覆盖了大部分缓存和使用场景需求。
辰风沐阳 阅读 47 2026-07-06
RabbitMQ 消息队列【第18讲：Fanout Exchange 广播模式】
本文介绍了 RabbitMQ 的 Fanout Exchange 模式，适用于需要广播消息的场景。与 Direct Exchange 的精确投递不同，Fanout Exchange 会将消息无条件转发给所有绑定的队列，无需指定路由键。典型应用如用户注册后同时触发邮件、优惠券发放和数据分析等操作。文章通过 PHP 代码演示了 Fanout Exchange 的声明、队列绑定和消息发布流程，并对比了 Fanout 和 Direct 两种模式的特点：Fanout 实现"一发多收"的广播机制，而 Direct 则是"精确投递"。
辰风沐阳 阅读 61 2026-07-05
