最新发布
RabbitMQ 消息队列【第29讲：为什么需要集群】
本文分析了 RabbitMQ 单机部署的三大风险：单点故障导致系统全停、单机性能容量瓶颈、无法应对流量洪峰。通过集群部署可以分散连接和存储压力，实现节点故障时系统仍可工作。但普通集群模式下，队列数据仍只存储在一个节点上，该节点故障时队列仍不可用。文章指出集群虽能提升可用性和扩展性，但普通集群方案存在局限性，无法彻底解决高可用问题，为后续讲解更完善的集群方案做铺垫。
辰风沐阳 阅读 22 2026-07-17
RabbitMQ 消息队列【第28讲：消息追踪与问题排查】
用户投诉下单后未收到短信通知，排查发现订单数据正常但消息丢失。RabbitMQ 消息流转涉及 Producer→Exchange→Queue→Consumer 多个环节，需逐层排查。建议优先通过 Producer/Consumer 日志、RabbitMQ 管理界面（检查Exchange/Queue状态）定位问题，常见问题包括路由错误、队列名不符、未ACK等。复杂场景可使用 Tracing 插件追踪消息轨迹，但多数问题通过常规工具即可解决。核心思路是沿消息流向有序排查，优先验证代码和配置而非中间件本身。
辰风沐阳 阅读 33 2026-07-16
Redis 修炼之路【第13讲：HyperLogLog 统计 UV】
本文介绍了使用 Redis 的 HyperLogLog 数据结构进行 UV（独立访客）统计的方法。相比传统 Set 集合，HyperLogLog 只需12KB固定内存即可统计2^64个元素，误差率仅0.81%，但不存储具体元素。基本操作包括 pfadd 添加元素、pfcount 统计数量和 pfmerge 合并多个集合。适用于大规模UV统计场景，如全站月度UV合并计算。当需要精确统计、小数据量或获取具体用户列表时，仍建议使用Set集合。HyperLogLog 通过哈希值前导零的统计实现概率估算，是高性能UV统计的理想选择。
辰风沐阳 阅读 38 2026-07-16
Redis 修炼之路【第12讲：Bitmap 统计签到】
本文介绍了 Redis 中 Bitmap 的妙用，Bitmap 底层是 String类型，每个 bit 表示一个状态（0/1），可高效存储签到、在线等二元状态数据。相比 Set 存储，100 万用户签到数据从 50MB+ 降至 125KB，节省400倍空间。演示 setbit/getbit/bitcount 操作和 Python 实现，指出 Bitmap 适用于布尔型场景，而需要存储具体信息时仍需使用Set。核心优势在于用1bit即可记录用户状态，极大节省存储空间。
辰风沐阳 阅读 29 2026-07-15
Redis 修炼之路【第11讲：ZSet 怎么实现排行榜】
Redis 的 ZSet（有序集合）是排行榜功能的高效实现方案。它通过 score 分数自动排序，支持快速查询和更新排名。核心操作包括 ZADD 添加元素、ZINCRBY 加分、ZRANGE/ZREVRANGE 查询排名范围、ZREVRANK 查询具体排名。相比 MySQL 排序查询，ZSet 在数据量大时性能更优。其底层采用跳表+哈希表结构，兼顾排序和快速查找。除排行榜外，ZSet 还可用于延时队列和限流等场景。典型应用如文章热度排行，通过简单命令即可实现点赞计数和 TopN 查询。
辰风沐阳 阅读 68 2026-07-14
RabbitMQ 消息队列【第27讲：消费幂等性】
RabbitMQ 消息重复投递可能导致业务异常（如重复扣库存、加积分），解决核心在于实现幂等性——同一消息多次处理结果一致。提出三种方案：1. 唯一业务ID+去重表检查；2. 利用数据库唯一索引；3. 通过状态机流转判断。方案各有适用场景，可组合使用。强调幂等性是业务层责任，与MQ机制无关。最终实现重复消息不影响业务逻辑的目标。
辰风沐阳 阅读 66 2026-07-14
RabbitMQ 消息队列【第26讲：消息可靠性投递（下）】
本文讨论了 RabbitMQ 中消息重复的问题及其解决方案。消息重复的原因包括生产者重发、消费者 ACK 丢失、消费者重启以及重试机制。RabbitMQ 能通过配置（如Confirm、Return、持久化、ACK）保证消息不丢失，但无法天然避免消息重复消费。解决重复消费需要业务层实现幂等性，确保同一条消息无论处理多少次结果都一致。RabbitMQ 的职责是消息传递，而业务去重需由消费者自行处理。
辰风沐阳 阅读 74 2026-07-13
Docker Hub 官方镜像（解决拉取官方镜像失败问题）
本文详细介绍了在国内网络环境下访问 Docker Hub 的常见问题及三种有效的解决方案。Docker Hub 作为全球最大的容器镜像仓库，在国内直接访问时常因网络问题导致连接超时或下载失败。文章首先分析了直接使用终端代理无法加速 Docker 守护进程的原因，并提供了通过 systemd 配置守护进程代理的具体步骤。随后，重点推荐了配置 Docker 镜像加速器这一最佳实践，列举了多个可用的国内镜像源地址，并给出了完整的配置命令和生效方法，帮助用户稳定、高效地拉取 Docker 镜像。
辰风沐阳 阅读 76 2026-07-13
RabbitMQ 消息队列【第25讲：消息可靠性投递（上）】
本文介绍了 RabbitMQ 消息传递过程中可能丢失的四个环节及解决方案：1. Producer 到 Exchange 环节通过 Publisher Confirm 机制确保消息送达；2. Exchange 到Queue 环节通过 Return 机制处理路由失败；3. Queue 存储环节通过队列和消息持久化防止重启丢失；4. Consumer 处理环节通过手动 ACK 保证消费完成。完整可靠性方案会带来性能开销，建议根据业务重要性选择配置级别，如订单支付类关键业务需开启所有保障机制，而日志收集等场景可使用默认配置。
辰风沐阳 阅读 91 2026-07-12
Redis 修炼之路【第10讲：Set 怎么做共同好友】
Redis 的 Set 数据结构具有无序、不重复的特性，支持高效的集合运算（交集、并集、差集），适用于多种场景。例如： 共同关注/好友：通过 sinter 快速获取交集，避免遍历数据库。 抽奖系统：利用 spop 实现不重复中奖，或用 srandmember 随机查看。 标签系统：存储文章标签，通过交集分析内容相似性。 UV 统计：sadd 自动去重，scard 统计独立访客，但大数据量时建议改用 HyperLogLog。 Set 底层根据数据特点选择 intset 或 hashtable 存储，兼顾性能与内存效率。
辰风沐阳 阅读 82 2026-07-12
Redis 修炼之路【第9讲：List 能当消息队列吗】
Redis 的 List 结构可以实现简单的消息队列功能，通过 LPUSH 和 RPOP 命令实现先进先出队列，BRPOP 支持阻塞式消费，避免了空队列轮询的 CPU 浪费。但 List 作为消息队列存在明显局限：缺乏消息确认机制，不支持多消费者和消息回溯。它适用于最新消息展示、操作日志记录等简单场景，但对于需要 ACK 确认、发布订阅或历史消息回溯的复杂场景，应选择 RabbitMQ、Kafka 等专业消息队列。总结来说，List 适合轻量级任务队列，但在可靠性要求高的场景中功能不足。
辰风沐阳 阅读 100 2026-07-11
RabbitMQ 消息队列【第24讲：延迟队列实现方案】
本文介绍了延迟队列的三种实现方案及其适用场景。延迟队列用于管理未来某个时间点执行的任务，如订单超时取消、会议提醒等。经典方案是 RabbitMQ 的TTL+DLX 组合，适合固定时长的延迟需求；RabbitMQ 官方延迟插件更灵活但需额外安装；Redis 方案则适合已有 Redis 的项目，但需自行实现定时任务。作者建议根据项目现状选择最简单可行的方案，多数情况下 TTL+DLX 已能满足需求，避免为简单需求引入复杂方案。
辰风沐阳 阅读 87 2026-07-11
