最新发布
RabbitMQ 消息队列【第25讲：消息可靠性投递（上）】
本文介绍了 RabbitMQ 消息传递过程中可能丢失的四个环节及解决方案：1. Producer 到 Exchange 环节通过 Publisher Confirm 机制确保消息送达；2. Exchange 到Queue 环节通过 Return 机制处理路由失败；3. Queue 存储环节通过队列和消息持久化防止重启丢失；4. Consumer 处理环节通过手动 ACK 保证消费完成。完整可靠性方案会带来性能开销，建议根据业务重要性选择配置级别，如订单支付类关键业务需开启所有保障机制，而日志收集等场景可使用默认配置。
辰风沐阳 阅读 45 2026-07-12
Redis 修炼之路【第10讲：Set 怎么做共同好友】
Redis 的 Set 数据结构具有无序、不重复的特性，支持高效的集合运算（交集、并集、差集），适用于多种场景。例如： 共同关注/好友：通过 sinter 快速获取交集，避免遍历数据库。 抽奖系统：利用 spop 实现不重复中奖，或用 srandmember 随机查看。 标签系统：存储文章标签，通过交集分析内容相似性。 UV 统计：sadd 自动去重，scard 统计独立访客，但大数据量时建议改用 HyperLogLog。 Set 底层根据数据特点选择 intset 或 hashtable 存储，兼顾性能与内存效率。
辰风沐阳 阅读 34 2026-07-12
Redis 修炼之路【第9讲：List 能当消息队列吗】
Redis 的 List 结构可以实现简单的消息队列功能，通过 LPUSH 和 RPOP 命令实现先进先出队列，BRPOP 支持阻塞式消费，避免了空队列轮询的 CPU 浪费。但 List 作为消息队列存在明显局限：缺乏消息确认机制，不支持多消费者和消息回溯。它适用于最新消息展示、操作日志记录等简单场景，但对于需要 ACK 确认、发布订阅或历史消息回溯的复杂场景，应选择 RabbitMQ、Kafka 等专业消息队列。总结来说，List 适合轻量级任务队列，但在可靠性要求高的场景中功能不足。
辰风沐阳 阅读 38 2026-07-11
RabbitMQ 消息队列【第24讲：延迟队列实现方案】
本文介绍了延迟队列的三种实现方案及其适用场景。延迟队列用于管理未来某个时间点执行的任务，如订单超时取消、会议提醒等。经典方案是 RabbitMQ 的TTL+DLX 组合，适合固定时长的延迟需求；RabbitMQ 官方延迟插件更灵活但需额外安装；Redis 方案则适合已有 Redis 的项目，但需自行实现定时任务。作者建议根据项目现状选择最简单可行的方案，多数情况下 TTL+DLX 已能满足需求，避免为简单需求引入复杂方案。
辰风沐阳 阅读 50 2026-07-11
RabbitMQ 消息队列【第23讲：死信队列 DLX】
本文介绍了 RabbitMQ 死信队列（DLX）的实现与应用。主要内容包括： 死信概念：消息过期、消费者拒收或队列满时，消息会变成死信，需通过死信队列处理。 DLX 机制：死信队列是一个普通 Exchange，用于接收死信并路由到指定队列，无需额外代码。 实现步骤： 声明死信 Exchange 和队列（如dlx_exchange和timeout_queue）。 业务队列绑定 DLX 参数（x-dead-letter-exchange和路由键）。 消息过期后自动转发至死信队列，触发取消订单等逻辑。
辰风沐阳 阅读 61 2026-07-10
Redis 修炼之路【第8讲：Hash 适合存对象吗】
本文介绍了 Redis 中 Hash 类型的特点和应用场景。Hash 支持在单个 key 下存储多个字段，可独立读写字段值，避免了 String 类型存 JSON 时整体读写的弊端。底层采用 ziplist（字段少时）或 hashtable（字段多时）两种编码结构。与 String 存 JSON 相比，Hash 适合字段多、频繁修改单个字段的场景，如用户信息、商品详情等，并以购物车为例展示了具体操作命令。String 则更适合字段少、整体读写的场景。Hash 提供了更灵活高效的对象存储方案。
辰风沐阳 阅读 56 2026-07-10
RabbitMQ 消息队列【第22讲：消息过期 TTL】
本文介绍了如何利用消息队列实现电商订单30分钟未支付自动取消的功能。传统定时任务扫表方案存在延迟、资源浪费和数据库压力问题，而基于 RabbitMQ 的 TTL（Time To Live）机制可以更高效地实现这一需求。TTL 允许为消息设置过期时间，超过时间未消费的消息将被丢弃或转入死信队列。文章详细说明了两种 TTL 设置方式（单条消息设置和队列级别设置），并给出了代码示例。同时指出单纯 TTL 的局限性，为后续介绍死信队列（DLX）解决方案做了铺垫。
辰风沐阳 阅读 57 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 共享问题。
辰风沐阳 阅读 58 2026-07-09
RabbitMQ 消息队列【第21讲：日志分级系统实战】
本文介绍了如何利用 RabbitMQ 的 Topic Exchange 实现日志分级处理系统。系统将日志分为 info、warning、error 三个级别，分别对应不同的处理方式：存储分析、监控统计和实时告警。通过模块.级别的路由规则（如order.error），配合通配符绑定（.error、.warning、*.info和#），实现日志的精准分流到不同队列。文章提供了 PHP 代码示例展示 Exchange 声明、队列绑定、消息发布和消费逻辑，并验证了不同级别日志能正确路由到对应队列。
辰风沐阳 阅读 65 2026-07-08
Redis 修炼之路【第6讲：Redis 为什么是单线程】
Redis 的单线程设计解析：6.0版本后网络IO多线程化，但命令执行仍保持单线程。单线程优势在于避免锁竞争和上下文切换，内存操作速度极快（纳秒级），性能瓶颈主要在网络IO。6.0引入多线程处理网络请求（配置4-8个线程），但核心逻辑保持单线程以保证简单高效。需警惕大key和慢命令（如keys*/hgetall等）造成的阻塞风险，建议使用scan系列命令替代。该设计平衡了性能与复杂度，网络吞吐成为主要优化方向。
辰风沐阳 阅读 71 2026-07-08
RabbitMQ 消息队列【第20讲：Headers Exchange 头匹配】
本文介绍了 RabbitMQ 中的 Headers Exchange，它通过消息头属性（headers）而非路由键（routing key）进行消息路由，支持多维度键值对匹配，提供 all（全匹配）和 any（任一匹配）两种模式。相比 Topic Exchange，Headers Exchange 灵活性更高但性能较差，实际使用频率较低，仅适用于消息维度复杂、需多属性组合匹配的场景。文中对比了四种 Exchange 类型：Direct（精确匹配）、Fanout（广播）、Topic（通配符匹配）和 Headers（属性匹配）
辰风沐阳 阅读 47 2026-07-07
Redis 修炼之路【第5讲：Redis 常用命令实战】
本文介绍了 Redis 常用命令操作，分为 Key 操作和五大核心数据结构（String、Hash、List、Set、ZSet）的使用方法。主要内容包括：keys/del/ttl 等通用命令；字符串的 incr/setnx 操作；哈希表的字段管理；列表的阻塞弹出；集合的运算操作；有序集合的排名控制等。还给出了 info/dbsize 等管理命令，并强调生产环境避免使用 keys * 和 flushdb 危险命令。作者建议读者通过实践掌握这些基础操作，为后续理解Redis单线程特性等高级话题打下基础。
辰风沐阳 阅读 62 2026-07-07
