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