Redis技术文章
-
本文从热点 Key 过期导致数据库 QPS 飙升的现场出发，排查 Redis 缓存击穿原因，并用互斥锁、旧值兜底和缓存重建流程修复。235 收藏 -
String类型在LRU驱逐场景下内存效率低，因其每个key和value均独立占用redisObject+SDS结构，导致对象头冗余高、驱逐粒度粗；而Hash等结构共享key对象头、支持ziplist压缩，内存利用率高40%~60%。233 收藏 -
应立即将maxmemory-policy从allkeys-lru切回volatile-lru，但需先停写、确认内存未满，再执行CONFIGSET与REWRITE，并配合RDB恢复关键数据，否则残留无TTLkey将持续引发淘汰。232 收藏 -
Redis的String类型加剧内存碎片是因为频繁SET/GET/APPEND导致jemalloc中大小不一的内存块反复分配释放，旧块无法复用而残留为碎片，表现为mem_fragmentation_ratio>1.5且used_memory_rss远大于used_memory。230 收藏 -
缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略：空值需设短过期并避免null值；布隆过滤器须预估容量、全局单例且配合写库更新；业务层应优先校验参数合法性。229 收藏 -
RedisLua脚本需用原子“读-判-写”实现状态变迁，推荐HASH结构存储多字段（如status、updated_at、version），通过HGETALL/HSET原子操作，结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转，返回结构化结果便于业务判断。224 收藏 -
Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli--latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。221 收藏 -
RedisHash最适合存购物车，因其天然支持按商品ID（field）原子增减、查询、删除；HINCRBY可安全±数量并自动初始化为0，但需应用层校验负数；key为cart:{user_id}，value仅存整数数量，过期用EXPIRE设置。221 收藏 -
直接用DEL释放锁会误删其他客户端的锁，因判断持有锁与删除非原子操作；Lua脚本通过原子执行“GET校验+DEL”解决，需传入key和client_id，返回1成功、0失败。216 收藏 -
活动报名、接口去重、用户访问统计里经常会用 Redis Set。本文从“页面显示人数不对”的现场开始，逐步验证 SADD 返回值、SCARD 数量、Key 粒度和过期策略，整理一套更稳的 Set 去重写法。194 收藏 -
INFOkeyspace无法反映淘汰情况，因其仅统计存活key数量，不区分已过期未删除或已被淘汰的key，且不记录evicted_keys等关键淘汰指标。191 收藏 -
数据库 · Redis | 2个月前 | Redis · 消息队列 · Stream · 消费组 · redis 消息队列 Redis Stream 消费组 XREADGROUP XACK XPENDING XAUTOCLAIM
用订单异步处理场景讲清楚 Redis Stream 的实用队列模型：生产者写入消息，消费组分配任务，Worker 处理成功后 ACK，失败或超时的消息进入待确认列表，再通过 XPENDING 和 XAUTOCLAIM 做重投。187 收藏 -
ZADD的score不能用时间戳，因同分排序不稳定且时间戳递增违背“分数越高名次越靠前”逻辑；应使用业务分数（如积分）并利用ZADD覆盖更新、ZINCRBY原子累加、ZREM安全删除。183 收藏 -
RedisPub/Sub不适合异步任务处理，因其无确认机制、无持久化、不支持消费者组与积压缓冲；应选用LPUSH+BRPOP或XADD+XREADGROUP(Stream)实现可靠任务队列。183 收藏 -
线上 Redis 里堆积了过期业务前缀或历史缓存时，不能直接用 KEYS 和 DEL 硬删。用 SCAN 分批遍历、先记录样本、按速率提交 UNLINK，并保留停止开关和统计结果，能把清理风险压到可控范围。183 收藏