🧱 Redis 基础与数据结构面试题

🧠 单线程的原因

• 简化并发控制，避免加锁带来的复杂度和开销。
• 主要瓶颈在网络和内存 IO，而不是 CPU 计算。

为什么快？

• 基于内存操作，数据结构简单。
• 使用 I/O 多路复用（epoll）。
• 高效的数据编码与紧凑存储。

📦 基础数据结构

• String：缓存单值、计数器。
• Hash：用户信息、配置对象。
• List：消息队列、时间线。
• Set：去重集合、标签。
• ZSet：有序排行榜、延时队列。

🧵 SDS（Simple Dynamic String）

• Redis 自定义的动态字符串结构，包含 len、alloc、buf 等字段。
• 避免了 C 字符串的缓冲区溢出和长度计算 O(n) 的问题。
• 支持预分配和惰性空间释放。

🧩 类似点

• 都可以存储多列字段（field-value）。

不同点

• Hash 完全在内存中，无类型约束、无索引。
• 适合作为对象缓存，不适合作为持久存储。

📮 基于 List 的队列

• 使用 LPUSH + RPOP 或 RPUSH + LPOP 实现队列。
• 可使用 BRPOP 等阻塞命令。

注意事项

• 不支持多消费者确认机制，难以保证“至少一次”或“仅一次”。
• 消息堆积时内存压力大。
• 复杂场景建议用专业 MQ（Kafka、RabbitMQ）。

🔗 Set vs ZSet

• Set：无序去重集合，只关心是否存在。
• ZSet：带 score 的有序集合，内部使用跳表 + 哈希表实现。

常见场景：排行榜、延时队列、时间线。

📐 特殊结构

• Bitmap：位图，适合海量布尔状态（签到、在线、打点）。
• HyperLogLog：基数统计，近似去重计数（UV 统计）。
• GEO：地理位置，附近的人/店搜索。

🔑 Key 设计

• 使用「业务前缀:模块:主键」格式，如 user:profile:1001。
• 避免过长的 key，影响内存占用与网络传输。
• 避免使用容易冲突的通用 key。

🏆 排行榜示例

# 增加分数
ZINCRBY rank:game 10 user:1001
ZINCRBY rank:game 5  user:1002

# 获取前 10 名
ZRANGE rank:game 0 9 WITHSCORES

# 获取某个用户的排名
ZREVRANK rank:game user:1001

⏰ 过期策略

• 惰性删除：访问 key 时发现过期才删除。
• 定期删除：定时随机抽样删除部分过期 key。

🧹 内存淘汰策略

• noeviction：写入时直接报错。
• allkeys-lru / volatile-lru。
• allkeys-random / volatile-random。
• volatile-ttl 等。

🚇 Pipeline

• 一次性发送多条命令，减少 RTT（网络往返）。
• 适合批量写入/读取，不关心中间响应顺序的场景。

🧾 Redis 事务

• 命令入队，EXEC 时按顺序执行，期间不会插入其他客户端的命令，具备原子性。
• 不支持回滚：某条命令执行失败，其他命令仍继续执行。

📘 经验模板

• 大 key / 热 key 导致的阻塞与解决方式。
• 滥用持久化导致 I/O 压力过大。
• 错误的 TTL 策略导致缓存雪崩。

✅ 建议结构

• 缓存：热点数据、会话、配置。
• 排行榜与计数：ZSet、HyperLogLog。
• 消息队列与限流：List、Stream、脚本。
• 分布式锁与选主：基于 SET NX EX 和 RedLock 思想。