【Redis】Redis 特性

---

1. Redis 作为内存数据库（核心特性）​​

​​（1）为什么内存存储快？​​

• ​​内存 vs 硬盘​​：
  • 内存的访问速度是 ​​纳秒级（ns）​​，而 SSD 是 ​​微秒级（μs）​​，HDD 是 ​​毫秒级（ms）​​。
  • ​​举例​​：Redis 读取 1KB 数据约 ​​0.1ms​​，MySQL（硬盘存储）约 ​​1~10ms​​。
• ​​优化手段​​：
  • ​​ziplist（压缩列表）​​：对小数据（如 Hash、List）进行压缩存储，减少内存占用。
  • ​​intset（整数集合）​​：如果 Set 只包含整数，Redis 会用更紧凑的方式存储。

​​（2）单线程模型为什么高效？​​

• ​​核心原因​​：
  • ​​无锁竞争​​：单线程避免了多线程的锁开销，减少上下文切换。
  • ​​I/O 多路复用（epoll）​​：一个线程管理多个连接，适用于高并发场景。
• ​​6.0 之后的多线程​​：
  • ​​仅用于网络 I/O​​（解析请求、发送响应），核心数据操作仍是单线程。

---

​​2. 可编程性（Lua 脚本 & 批处理）​​

​​（1）Lua 脚本的原子性​​

• ​​示例​​：用 Lua 实现 ​​分布式锁 + 自动续期​​

  -- KEYS[1] = 锁名称, ARGV[1] = 超时时间, ARGV[2] = 线程ID
  if redis.call("EXISTS", KEYS[1]) == 0 thenredis.call("SET", KEYS[1], ARGV[2], "PX", ARGV[1])return 1 -- 加锁成功
  elseif redis.call("GET", KEYS[1]) == ARGV[2] thenredis.call("EXPIRE", KEYS[1], ARGV[1]) -- 续期return 1
  elsereturn 0 -- 锁被占用
  end

• ​​限制​​：
  • 脚本执行时间过长会阻塞 Redis（默认 5 秒超时）。

​​（2）批处理（Pipeline）​​

• ​​适用场景​​：需要执行大量命令（如批量写入 10 万条数据）。
• ​​示例​​（Python）：

  pipe = redis.pipeline()
  for i in range(100000):pipe.set(f"key_{i}", f"value_{i}")
  pipe.execute()  # 一次性发送所有命令

• ​​对比事务（MULTI/EXEC）​​：
  • Pipeline 只是减少网络往返，不保证原子性。
  • 事务保证原子性，但失败不会回滚（继续执行）。

---

​​3. 持久化（RDB & AOF）​​

​​（1）RDB（快照）​​

• ​​触发方式​​：
  • 手动执行 SAVE（阻塞）或 BGSAVE（后台异步）。
  • 配置文件 save 60 10000（60 秒内 10000 次修改触发）。
• ​​优点​​：
  • 恢复速度快（直接加载二进制文件）。
• ​​缺点​​：
  • 可能丢失最后一次快照后的数据。

​​（2）AOF（日志追加）​​

• ​​写策略​​：
  • appendfsync always（每条命令刷盘，最安全但最慢）。
  • appendfsync everysec（折中方案，默认推荐）。
• ​​AOF 重写​​：
  • 避免日志过大，Redis 会生成新的 AOF 文件（只保留最终状态）。

​​（3）混合持久化（Redis 4.0+）​​

• ​​恢复流程​​：
  1. 先加载 RDB 快照（快速恢复大部分数据）。
  2. 再重放 AOF 日志（恢复最新修改）。

---

​​4. 高可用（主从、哨兵、集群）​​

​​（1）主从复制​​

• ​​同步方式​​：
  • ​​全量同步（SYNC）​​：从节点首次连接时，主节点发送完整数据。
  • ​​增量同步（PSYNC）​​：断线重连后，只同步缺失部分。
• ​​读写分离​​：
  • 主节点写，从节点读（通过 READONLY 命令配置）。

​​（2）哨兵（Sentinel）​​

• ​​功能​​：
  • 监控主节点健康状态。
  • 自动故障转移（主节点宕机时，提升从节点为主）。
• ​​脑裂问题​​：
  • 解决方案：min-slaves-to-write 1（至少 1 个从节点同步成功才接受写）。

​​（3）Cluster 集群​​

• ​​数据分片​​：
  • 16384 个哈希槽（CRC16(key) % 16384 计算槽位）。
  • 每个节点负责一部分槽位。
• ​​跨槽操作​​：
  • 使用 {hash_tag} 确保相关 key 落在同一节点（如 user:{123}:profile）。

---

​​5. 适用场景 vs 不适用场景​​

​​（1）适用场景​​

场景	解决方案	示例
​​会话存储​​	SETEX session:123 3600 "{user_data}"	分布式登录态管理
​​实时排行榜​​	ZADD leaderboard 100 "user1"	游戏积分榜
​​消息队列​​	LPUSH task_queue "data" + BRPOP task_queue 30	异步任务处理

​会话存储

在 ​​单机架构​​ 中，用户的 Session 存储在当前服务器的内存里，请求携带的 SessionID 可以直接匹配，不会出现会话丢失问题。

但在 ​​分布式架构​​ 下：

1. 用户请求先经过 ​​负载均衡器​​（如 Nginx）。
2. 负载均衡器采用 ​​轮询策略​​，可能把请求分发到不同的服务器（Server 1、Server 2...）。
3. 如果 Session 只存储在 ​​某台服务器内存​​ 里，其他服务器无法读取，导致用户 ​​“明明登录了，却找不到 Session”​​。

​​2. 解决方案​​

​​（1）会话绑定（Sticky Session）​​

• ​​原理​​：让同一个用户的请求 ​​始终访问同一台服务器​​（不采用轮询）。
• ​​实现方式​​：
  • 负载均衡器基于 SessionID 或 IP 做 ​​哈希路由​​。
• ​​缺点​​：
  • ​​服务器宕机时，会话丢失​​（无高可用）。
  • ​​扩容/缩容困难​​（哈希分布会变化）。

​​2）集中式 Session 存储（Redis）​​（推荐）​

• ​​原理​​：将会话数据统一存储在 ​​Redis​​，所有服务器共享访问。
• ​​架构​​：

  用户 → 负载均衡器 → 任意应用服务器 → Redis（存储 Session）

• ​​优点​​：
  • ​​高可用​​：即使某台服务器宕机，会话仍在 Redis 中。
  • ​​可扩展​​：新增服务器无需迁移 Session。
  • ​​自动过期​​：Redis 支持 EXPIRE 自动清理过期会话。

（2）不适用场景​​

• ​​海量数据存储​​（如 10TB）：内存成本过高，建议用 MySQL + Redis 缓存。
• ​​复杂事务​​：Redis 事务不支持回滚，不适合金融级一致性要求。