Redis 修炼之路【第15讲：缓存穿透到底怎么解决】
本文介绍了缓存穿透问题及其解决方案。当恶意请求大量不存在的数据时，请求会绕过缓存直接访问数据库，导致数据库过载。解决方案包括：1. 缓存空值，但会占用内存；2. 使用布隆过滤器预先过滤无效请求；3. 在接口层进行参数校验。三种方法结合使用可有效防止缓存穿透问题。
辰风沐阳 阅读 178 2026-07-18
Redis 修炼之路【第14讲：GEO 附近的人】
Redis 的 GEO 类型能高效实现"附近的人/店/车"功能，底层基于 ZSet 和 GeoHash 编码。通过 geoadd 存储经纬度，geodist 计算距离，georadius 查询附近范围，精度约1米。适用于商家定位、打车软件等场景，百万级数据性能良好。使用时需注意经纬度范围限制，重复添加会更新坐标。GEO 功能简单易用，是处理地理位置数据的理想选择。
辰风沐阳 阅读 178 2026-07-17
Redis 修炼之路【第13讲：HyperLogLog 统计 UV】
本文介绍了使用 Redis 的 HyperLogLog 数据结构进行 UV（独立访客）统计的方法。相比传统 Set 集合，HyperLogLog 只需12KB固定内存即可统计2^64个元素，误差率仅0.81%，但不存储具体元素。基本操作包括 pfadd 添加元素、pfcount 统计数量和 pfmerge 合并多个集合。适用于大规模UV统计场景，如全站月度UV合并计算。当需要精确统计、小数据量或获取具体用户列表时，仍建议使用Set集合。HyperLogLog 通过哈希值前导零的统计实现概率估算，是高性能UV统计的理想选择。
辰风沐阳 阅读 177 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即可记录用户状态，极大节省存储空间。
辰风沐阳 阅读 169 2026-07-15
Redis 修炼之路【第11讲：ZSet 怎么实现排行榜】
Redis 的 ZSet（有序集合）是排行榜功能的高效实现方案。它通过 score 分数自动排序，支持快速查询和更新排名。核心操作包括 ZADD 添加元素、ZINCRBY 加分、ZRANGE/ZREVRANGE 查询排名范围、ZREVRANK 查询具体排名。相比 MySQL 排序查询，ZSet 在数据量大时性能更优。其底层采用跳表+哈希表结构，兼顾排序和快速查找。除排行榜外，ZSet 还可用于延时队列和限流等场景。典型应用如文章热度排行，通过简单命令即可实现点赞计数和 TopN 查询。
辰风沐阳 阅读 170 2026-07-14
Redis 修炼之路【第10讲：Set 怎么做共同好友】
Redis 的 Set 数据结构具有无序、不重复的特性，支持高效的集合运算（交集、并集、差集），适用于多种场景。例如： 共同关注/好友：通过 sinter 快速获取交集，避免遍历数据库。 抽奖系统：利用 spop 实现不重复中奖，或用 srandmember 随机查看。 标签系统：存储文章标签，通过交集分析内容相似性。 UV 统计：sadd 自动去重，scard 统计独立访客，但大数据量时建议改用 HyperLogLog。 Set 底层根据数据特点选择 intset 或 hashtable 存储，兼顾性能与内存效率。
辰风沐阳 阅读 180 2026-07-12
Redis 修炼之路【第9讲：List 能当消息队列吗】
Redis 的 List 结构可以实现简单的消息队列功能，通过 LPUSH 和 RPOP 命令实现先进先出队列，BRPOP 支持阻塞式消费，避免了空队列轮询的 CPU 浪费。但 List 作为消息队列存在明显局限：缺乏消息确认机制，不支持多消费者和消息回溯。它适用于最新消息展示、操作日志记录等简单场景，但对于需要 ACK 确认、发布订阅或历史消息回溯的复杂场景，应选择 RabbitMQ、Kafka 等专业消息队列。总结来说，List 适合轻量级任务队列，但在可靠性要求高的场景中功能不足。
辰风沐阳 阅读 214 2026-07-11
Redis 修炼之路【第8讲：Hash 适合存对象吗】
本文介绍了 Redis 中 Hash 类型的特点和应用场景。Hash 支持在单个 key 下存储多个字段，可独立读写字段值，避免了 String 类型存 JSON 时整体读写的弊端。底层采用 ziplist（字段少时）或 hashtable（字段多时）两种编码结构。与 String 存 JSON 相比，Hash 适合字段多、频繁修改单个字段的场景，如用户信息、商品详情等，并以购物车为例展示了具体操作命令。String 则更适合字段少、整体读写的场景。Hash 提供了更灵活高效的对象存储方案。
辰风沐阳 阅读 175 2026-07-10
Redis 修炼之路【第7讲：String 为什么是万能结构】
Redis 的 String 结构底层采用 SDS（Simple Dynamic String），相比C原生字符串具有 O(1) 获取长度和二进制安全的优势。String 支持三种编码（int、embstr、raw），根据数据自动选择以优化内存和性能。其应用场景广泛： 缓存：存储高频查询结果，减轻数据库压力； 计数器：原子操作incr实现阅读量、点赞统计； 分布式锁：基础版通过 set nx ex 实现； 验证码：设置过期时间自动清理； 分布式 Session：解决多服务器 Session 共享问题。
辰风沐阳 阅读 153 2026-07-09
Redis 修炼之路【第6讲：Redis 为什么是单线程】
Redis 的单线程设计解析：6.0版本后网络IO多线程化，但命令执行仍保持单线程。单线程优势在于避免锁竞争和上下文切换，内存操作速度极快（纳秒级），性能瓶颈主要在网络IO。6.0引入多线程处理网络请求（配置4-8个线程），但核心逻辑保持单线程以保证简单高效。需警惕大key和慢命令（如keys*/hgetall等）造成的阻塞风险，建议使用scan系列命令替代。该设计平衡了性能与复杂度，网络吞吐成为主要优化方向。
辰风沐阳 阅读 186 2026-07-08