最新发布
Redis 修炼之路【第16讲：缓存击穿和热点 Key】
缓存击穿指热点 key 突然过期，导致大量请求直接冲击 MySQL。解决方案包括： 互斥锁：仅允许一个请求查询数据库，其他请求等待，可能影响用户体验； 逻辑过期：value 中存储逻辑过期时间，先返回旧数据并异步更新，平衡一致性与性能； 热点 Key 防护：提前缓存、延长过期时间或使用本地缓存（如Caffeine）。与缓存穿透（查询不存在的key）不同，缓存击穿针对热点 key 失效场景，需结合业务选择合适策略。
辰风沐阳 阅读 30 2026-07-19
RabbitMQ 消息队列【第31讲：镜像队列是什么】
本文介绍了 RabbitMQ 镜像队列的工作原理和特点。镜像队列通过将队列数据复制到多个节点实现高可用，包含一个主节点（负责读写）和多个镜像节点（负责备份）。当主节点故障时，系统会自动选择镜像节点接替。配置通过 Policy 实现，可选择全部或部分节点进行镜像。然而镜像队列存在性能开销大、主节点瓶颈、故障转移可靠性不足以及集群状态不一致风险等问题。正因如此，RabbitMQ 3.8 版本推出了 Quorum Queue 作为其替代方案。
辰风沐阳 阅读 24 2026-07-19
RabbitMQ 消息队列【第30讲：普通集群模式】
本文介绍了 RabbitMQ 普通集群的特点和局限性。普通集群通过多节点共享元数据实现连接分散，减轻单机压力，但队列数据仅存储在声明节点上，不具备数据冗余能力。当队列所在节点宕机时，该队列将不可用。因此普通集群只能解决连接分散问题，无法实现真正的高可用。文章通过具体场景说明这个容易被误解的特性，并指出要实现高可用需要使用镜像队列（将在下篇文章介绍）。关键结论：普通集群是"能用"而非"高可用"的解决方案。
辰风沐阳 阅读 36 2026-07-18
Redis 修炼之路【第15讲：缓存穿透到底怎么解决】
本文介绍了缓存穿透问题及其解决方案。当恶意请求大量不存在的数据时，请求会绕过缓存直接访问数据库，导致数据库过载。解决方案包括：1. 缓存空值，但会占用内存；2. 使用布隆过滤器预先过滤无效请求；3. 在接口层进行参数校验。三种方法结合使用可有效防止缓存穿透问题。
辰风沐阳 阅读 23 2026-07-18
Redis 修炼之路【第14讲：GEO 附近的人】
Redis 的 GEO 类型能高效实现"附近的人/店/车"功能，底层基于 ZSet 和 GeoHash 编码。通过 geoadd 存储经纬度，geodist 计算距离，georadius 查询附近范围，精度约1米。适用于商家定位、打车软件等场景，百万级数据性能良好。使用时需注意经纬度范围限制，重复添加会更新坐标。GEO 功能简单易用，是处理地理位置数据的理想选择。
辰风沐阳 阅读 28 2026-07-17
RabbitMQ 消息队列【第29讲：为什么需要集群】
本文分析了 RabbitMQ 单机部署的三大风险：单点故障导致系统全停、单机性能容量瓶颈、无法应对流量洪峰。通过集群部署可以分散连接和存储压力，实现节点故障时系统仍可工作。但普通集群模式下，队列数据仍只存储在一个节点上，该节点故障时队列仍不可用。文章指出集群虽能提升可用性和扩展性，但普通集群方案存在局限性，无法彻底解决高可用问题，为后续讲解更完善的集群方案做铺垫。
辰风沐阳 阅读 30 2026-07-17
RabbitMQ 消息队列【第28讲：消息追踪与问题排查】
用户投诉下单后未收到短信通知，排查发现订单数据正常但消息丢失。RabbitMQ 消息流转涉及 Producer→Exchange→Queue→Consumer 多个环节，需逐层排查。建议优先通过 Producer/Consumer 日志、RabbitMQ 管理界面（检查Exchange/Queue状态）定位问题，常见问题包括路由错误、队列名不符、未ACK等。复杂场景可使用 Tracing 插件追踪消息轨迹，但多数问题通过常规工具即可解决。核心思路是沿消息流向有序排查，优先验证代码和配置而非中间件本身。
辰风沐阳 阅读 40 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统计的理想选择。
辰风沐阳 阅读 44 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即可记录用户状态，极大节省存储空间。
辰风沐阳 阅读 37 2026-07-15
Redis 修炼之路【第11讲：ZSet 怎么实现排行榜】
Redis 的 ZSet（有序集合）是排行榜功能的高效实现方案。它通过 score 分数自动排序，支持快速查询和更新排名。核心操作包括 ZADD 添加元素、ZINCRBY 加分、ZRANGE/ZREVRANGE 查询排名范围、ZREVRANK 查询具体排名。相比 MySQL 排序查询，ZSet 在数据量大时性能更优。其底层采用跳表+哈希表结构，兼顾排序和快速查找。除排行榜外，ZSet 还可用于延时队列和限流等场景。典型应用如文章热度排行，通过简单命令即可实现点赞计数和 TopN 查询。
辰风沐阳 阅读 78 2026-07-14
RabbitMQ 消息队列【第27讲：消费幂等性】
RabbitMQ 消息重复投递可能导致业务异常（如重复扣库存、加积分），解决核心在于实现幂等性——同一消息多次处理结果一致。提出三种方案：1. 唯一业务ID+去重表检查；2. 利用数据库唯一索引；3. 通过状态机流转判断。方案各有适用场景，可组合使用。强调幂等性是业务层责任，与MQ机制无关。最终实现重复消息不影响业务逻辑的目标。
辰风沐阳 阅读 77 2026-07-14
RabbitMQ 消息队列【第26讲：消息可靠性投递（下）】
本文讨论了 RabbitMQ 中消息重复的问题及其解决方案。消息重复的原因包括生产者重发、消费者 ACK 丢失、消费者重启以及重试机制。RabbitMQ 能通过配置（如Confirm、Return、持久化、ACK）保证消息不丢失，但无法天然避免消息重复消费。解决重复消费需要业务层实现幂等性，确保同一条消息无论处理多少次结果都一致。RabbitMQ 的职责是消息传递，而业务去重需由消费者自行处理。
辰风沐阳 阅读 79 2026-07-13
