带你了解 Redis —— 基础知识总结

一、Redis 简介

Redis 是一款高性能开源内存键值数据库，核心优势是高速响应、灵活数据结构和高并发支持，常作为缓存、计数器等场景的首选。

二、核心特性

• 基于内存存储：数据优先驻留内存，读写操作避开磁盘 IO 瓶颈，响应速度达微秒级；

• 丰富数据结构：支持字符串（String）、哈希（Hash）、列表（List）、集合（Set）、有序集合（Sorted Set）、位图（Bitmap）、地理空间（GEO）等，适配多样化场景；

• 持久化机制：通过 RDB（快照）和 AOF（日志追加）两种方式，将内存数据异步写入磁盘，避免宕机数据丢失；

• 高并发高吞吐：单线程模型（避免多线程锁竞争）+ IO 多路复用，单机读写 QPS 可达 10 万 +，远超传统关系型数据库；

• 分布式支持：原生支持主从复制、哨兵（Sentinel）高可用、集群（Cluster）分片，可横向扩展；

• 多功能附加能力：支持过期键自动删除、发布订阅（Pub/Sub）、Lua 脚本、事务（弱事务，保证命令原子执行）、限流 / 计数器等。

三、核心优势

MySQL 是磁盘存储的关系型数据库，主打结构化数据、ACID 事务、复杂查询（联表、聚合），但在高并发、灵活数据结构、快速响应场景下存在明显短板。Redis 的优势集中在以下维度：

对比维度	Redis 优势体现	实际场景举例
读写速度	内存操作（微秒级）vs MySQL 磁盘 IO（毫秒级）	电商首页热点商品展示：用户访问量峰值达 10 万 QPS，Redis 缓存商品详情，直接返回；若用 MySQL，磁盘 IO 会导致响应延迟超 1 秒，甚至宕机。
数据结构灵活性	无需预定义表结构，支持非结构化 / 半结构化数据	短视频 APP 用户画像：用 Hash 存储用户昵称、年龄、偏好标签，新增标签无需修改 "表结构"；若用 MySQL，需 ALTER TABLE，影响性能。
高并发原子操作	内置 INCR/DECR、ZADD 等原子命令，避免并发冲突	直播平台点赞计数：10 万用户同时点赞，Redis INCR key 原子执行，无计数不准；若用 MySQL UPDATE SET count=count+1，需加锁，并发量超 1 万 QPS 即卡顿。
缓存减压	作为 MySQL 的 "前置缓存"，承接热点查询	秒杀活动商品库存查询：90% 的用户查询命中 Redis，仅 10% 未命中的请求穿透到 MySQL，MySQL 负载降低 90%，避免被高并发击垮。
轻量级场景适配	支持发布订阅、限流、分布式锁等，无需复杂配置	微服务接口限流：用 Redis INCR + EXPIRE 实现 "每分钟最多 100 次请求"，比 MySQL 用表记录请求次数更高效（无需事务和锁）。
分布式能力	集群分片支持海量数据存储，主从复制保证高可用	社交 APP 好友关系存储：Redis Cluster 将亿级用户好友关系分片到多个节点，主从复制确保单点故障不影响服务；MySQL 分库分表配置复杂，跨分片查询性能差。

四、持久化机制

Redis 是基于内存型的 NoSQL，和 MySQL 是不同的，使用内存进行数据保存。如果想实现数据的持久化，Redis 也也可支持将内存数据保存到硬盘文件中。

Redis支持两种数据持久化保存方法：RDB（Redis DataBase）和 AOF（AppendOnlyFile）

1、RDB 持久化

1.1、工作原理

RDB 是快照式持久化，是基于某个时间点的快照（RDB 只保留当前最新版本的一个快照）。通过 "触发条件" 生成内存数据的全量二进制快照（.rdb 文件），并异步写入磁盘。RDB 持久化功能所生成的 RDB 文件是一个经过压缩的二进制文件，通过该文件可以还原生成该 RDB 文件时数据库的状态。因为 RDB 文件是保存在磁盘中的，所以即便 Redis 服务进程甚至服务器宕机，只要磁盘中 RDB 文件存在，就能将数据恢复。

1.2、触发方式

• 自动触发：满足配置的 "时间 + 修改次数" 阈值（如 5 分钟内改 10 次），Redis 后台 fork 子进程，由子进程完成快照写入（主进程继续处理请求，无阻塞）。

• 手动触发：执行 save（主进程阻塞，不推荐）或 bgsave（后台 fork 子进程，推荐）命令。

1.3、 核心配置参数

• save <seconds> <changes>：自动触发条件，可配置多个（如 save 300 10 表示 300 秒内有 10 次修改触发）。

• dbfilename dump.rdb：RDB 快照文件名，默认存在 Redis 安装目录。

• dir ./：RDB 文件存储路径，建议改为独立目录（如 /data/redis/）。

• stop-writes-on-bgsave-error yes：bgsave 失败时是否停止写入，默认开启（避免数据不一致），yes为出错后禁止写入，建议为no。

• rdbcompression yes：是否压缩 RDB 文件（节省空间，轻微消耗 CPU）。

1.4、优缺点

优点

• 恢复速度极快：加载二进制快照文件，无需解析日志，适合大规模数据恢复。

• 对性能影响小：仅 fork 子进程写入，主进程无 IO 操作。

• 文件体积小：二进制压缩格式，存储效率高。

缺点

• 数据丢失风险高：仅保留最后一次快照，若宕机在两次快照之间，期间修改的数据会丢失。

• fork 子进程开销：数据量极大时，fork 会阻塞主进程（毫秒级到秒级），影响高并发场景。

1.5、适用场景

• 能容忍少量数据丢失（如缓存场景，丢失后可从数据库重建）。

• 追求快速恢复（如灾备场景，需要快速重启服务）。

• 数据修改频率较低，或可接受快照间隔内的丢失（如非核心业务配置存储）。

2、AOF 持久化

2.1、工作原理

AOF 是日志式持久化，将每一条写命令（如 SET、INCR）以文本格式追加到 .aof 文件中。Redis 重启时，通过重新执行文件中的所有命令恢复数据。

2.2、核心机制

• 命令追加：写命令执行后，先写入内存缓冲区，再根据刷盘策略同步到磁盘。

• AOF 重写：长期追加会导致文件过大，Redis 会 fork 子进程，将当前内存数据转化为 "最小命令集"（如多次 INCR 合并为 SET key 最终值），覆盖旧 AOF 文件，减小体积。

2.3、核心配置参数

• appendonly yes：开启 AOF 持久化（默认关闭）。

• appendfilename appendonly.aof：AOF 日志文件名，存储路径同 RDB 的 dir 参数。

• appendfsync：刷盘策略（核心参数）：

  always：每执行一条命令刷盘，数据零丢失（性能最差）。

  everysec：每秒刷盘一次（默认，平衡安全性和性能，最多丢失 1 秒数据）。

  no：由操作系统决定刷盘时机（性能最好，数据丢失风险最高）。

• auto-aof-rewrite-percentage 100：AOF 文件体积比上次重写后增长 100% 时触发重写。

• auto-aof-rewrite-min-size 64mb：AOF 文件最小体积（默认 64MB），达到后才可能触发重写。

2.4、优缺点

优点

• 数据安全性高：支持秒级甚至零数据丢失，适配核心业务。

• 无数据丢失风险：只要刷盘策略合理，宕机仅丢失未刷盘的少量命令。

• 兼容性好：文本格式命令，可手动修改（如误操作后删除错误命令）。

缺点

• 恢复速度慢：需重新执行所有命令，数据量越大，恢复时间越长。

• 文件体积大：文本格式 + 重复命令，未重写时文件体积远超 RDB。

• 性能开销略高：每秒刷盘或每次刷盘会占用 IO 资源，高并发写场景下比 RDB 耗时。

2.5、适用场景

• 对数据一致性要求高（如金融交易、用户余额、订单状态等核心业务）。

• 无法容忍数据丢失，或仅能接受毫秒级 / 秒级数据丢失。

• 写命令频率适中，或可通过重写机制控制文件体积（如电商订单缓存）。

3、持久化方案选型方法

3.1、仅用 RDB

• 适用场景：纯缓存场景（如热点商品缓存、接口结果缓存），数据可从 MySQL 等数据源快速重建，优先追求性能和恢复速度。

• 注意：需合理配置 save 阈值（如高并发场景可设 save 60 1000，减少 fork 次数）。

3.2、仅用 AOF

• 适用场景：核心业务数据存储（如用户会话、分布式锁），无法容忍大量数据丢失，优先保障数据安全性。

• 注意：配置appendfsync everysec平衡性能，定期监控 AOF 文件体积，避免重写不及时导致文件过大。

3.3、混合模式（RDB+AOF）

• 工作逻辑：用 RDB 做 "全量备份"（快速恢复），用 AOF 记录两次 RDB 之间的增量命令（减少数据丢失）。

• 适用场景：绝大多数生产环境（如电商、支付、社交 APP），既需要快速恢复，又要降低数据丢失风险。

• 优势：兼顾 RDB 的 "快速恢复" 和 AOF 的 "高安全性"，宕机后先加载 RDB 全量数据，再执行 AOF 增量命令，数据丢失量极小。

五、Redis 主从复制

Redis 主从复制是数据同步与读写分离的基础。其核心是 "主库写、从库读"，从库通过复制主库数据实现数据一致性，支持一主多从，可横向扩展读能力。

1、核心目的

• 数据冗余：从库作为主库备份，避免单节点数据丢失。

• 读写分离：主库承接写操作，从库承接查询操作，减轻主库压力。

• 故障转移：主库故障时，从库可升级为主库，保障服务连续性。

2、全量同步

全量同步是从库首次连接主库 或断线重连后数据差异过大时触发的完整数据同步，流程如下：

1. 从库发送 SYNC 命令（Redis 2.8+ 用 PSYNC 优化，支持部分重同步），请求同步。

2. 主库收到命令后，执行 bgsave 生成 RDB 快照文件，同时将期间的写命令存入复制缓冲区。

3. 主库完成 RDB 生成后，将 RDB 文件发送给从库。

4. 从库接收 RDB 文件，清空本地数据，加载 RDB 恢复全量数据。

5. 主库将复制缓冲区中的增量写命令发送给从库，从库执行命令，最终与主库数据一致。

3、增量同步

增量同步是从库已完成全量同步后，主库实时向从库推送写命令的同步方式，流程如下：

1. 主库每执行一条写命令，都会记录到复制偏移量（主库自身偏移量）和复制缓冲区。

2. 从库执行完同步命令后，会向主库反馈自己的复制偏移量，表明已同步到哪个位置。

3. 主库对比自身偏移量和从库反馈的偏移量，将差值对应的写命令（复制缓冲区中未同步的命令）推送给从库。

4. 从库执行接收的命令，更新本地数据和自身偏移量，保持与主库实时同步。

关键依赖：复制偏移量（记录同步进度）、复制缓冲区（缓存未同步命令）、运行 ID（主库唯一标识，从库通过 ID 确认主库身份）。

六、Sentinel 哨兵机制

Sentinel 是 Redis 官方提供的高可用解决方案，由一组（至少 3 个）哨兵节点组成，不存储数据，仅负责监控主从集群、检测故障并自动执行故障转移。Sentinel 与主从复制二者协同实现 "数据不丢失、服务不中断"。

1、核心功能

• 集群监控：实时监控主库、从库和其他哨兵节点的健康状态。

• 故障检测：判断主库是否 "下线"，分为主观下线和客观下线。

• 自动故障转移：主库故障时，自动将最优从库升级为主库，并重定向其他从库和客户端。

• 配置通知：将故障转移后的新主库信息通知给所有从库和客户端，确保后续请求指向新主库。

2、故障检测流程

故障检测的核心是 "先主观判断，再客观确认"，避免误判：

1. 主观下线（SDOWN）：单个哨兵节点每隔 1 秒向主库、从库发送 PING 命令，若超时（默认 30 秒）未收到有效响应，该哨兵会标记该主库为 "主观下线"（仅自身认为故障）。

2. 客观下线（ODOWN）：标记主库为 "主观下线" 的哨兵，会向集群中其他哨兵发送请求，询问是否也认为该主库故障。若超过半数（配置的 quorum 参数，如 3 个哨兵需 2 个同意）的哨兵反馈 "主库故障"，则该主库被标记为 "客观下线"（集群确认故障），触发故障转移。

3、故障转移流程

客观下线后，哨兵集群会自动执行故障转移，步骤如下：

1. 选举领头哨兵：哨兵集群通过投票机制选举出一个 "领头哨兵"，由其负责执行后续故障转移操作（避免多哨兵重复操作）。

2. 选择新主库 ：领头哨兵从所有健康的从库中，按优先级筛选最优从库作为新主库，筛选规则：

   优先选择配置了 slave-priority（从库优先级）数值最小的从库（默认 100，数值越小优先级越高）。

   优先级相同，选择复制偏移量最大的从库（数据最完整）。

   偏移量相同，选择运行 ID 最小的从库（随机兜底）。

3. 执行故障转移 ：

   领头哨兵向选中的新主库发送 SLAVEOF NO ONE 命令，使其升级为主库。

   向其他从库发送 SLAVEOF 新主库IP:端口 命令，让它们同步新主库的数据。

   标记原故障主库为 "从库"，待其恢复后，自动同步新主库数据（作为备用从库）。

4. 通知客户端：哨兵通过发布订阅（Pub/Sub）机制，向客户端推送新主库的地址信息，客户端更新连接配置，后续请求直接指向新主库。

主从复制通过 "全量 + 增量同步" 保障数据一致性，支撑读写分离；Sentinel 通过 "监控 + 故障检测 + 自动转移" 解决主库单点故障问题，二者结合构成 Redis 高可用基础架构。生产环境中，主从集群需搭配至少 3 个哨兵节点（避免脑裂），主从库部署在不同服务器，确保极端情况下的服务可用性。

七、Cluster 集群模式

Redis Cluster 是 Redis 官方提供的分布式分片集群方案，核心解决 "海量数据存储" 和 "高并发读写" 的横向扩展问题，相比主从复制 + Sentinel 架构更适合大规模场景。

Redis Custer 需要至少 3 个 Master 节点才能实现，Slave 节点数量不限。Master节点必须要超过半数以上可用，否则集群将不可用，即数据访问和选举将无法实现。因此 Master 节点的数据一般为奇数。当然一般每个 Master 都至少对应的有一个 Slave 节点。如果有三个主节点采用哈希槽 hash slot 的方式来分配16384个槽位，则会平均分配给所有主节点。

1、数据分片规则

Redis Cluster 采用 "哈希槽分片"（hash slot） 替代传统一致性哈希，实现数据均匀分布和灵活迁移，核心逻辑如下：

• 哈希槽总量：集群预设 16384 个固定哈希槽（0-16383），所有数据均通过 "键 - 槽位" 映射存储。

• 分片算法：对键执行 CRC16(key) % 16384 计算，得到对应的哈希槽，数据存储到负责该槽位的主节点。

• 槽位分配：集群初始化时，16384 个槽位会平均分配给所有主节点（如 3 个主节点各负责～5461 个槽）。

• 特殊键处理：支持 "键标签"（如 {user:100}:name），哈希计算仅基于 {} 内的内容，确保相关键（如同一用户的信息）映射到同一槽位，避免跨节点查询。

• 主从关联：每个主节点可挂载多个从节点，从节点仅同步对应主节点的槽位数据，不参与槽位分配（仅作为备份和故障转移备用）。

2、节点通信方式

Redis Cluster 是去中心化架构，无中心节点，节点间通过 Gossip 协议同步集群状态，核心机制如下：

通信基础：每个节点开放两个端口 ------ 客户端通信端口（如 6379）和集群总线端口（6379+10000=16379），节点间通过集群总线进行二进制协议通信。

通信内容：节点定期（默认每秒）向随机选择的 3 个节点发送 Gossip 消息，包含自身状态（角色、健康状态）、槽位分配信息、集群节点列表等。

通信特点：

• 去中心化：无需中心节点协调，节点自主同步信息，集群稳定性更高。

• 最终一致性：信息同步存在毫秒级延迟，但不影响核心读写（客户端会缓存槽位映射，缺失时通过 MOVED 指令重定向）。

• 低开销：仅同步增量信息，避免全量广播，支持大规模节点（建议最多 1000 个节点）。

3、扩容与缩容的核心逻辑

Redis Cluster 支持 "在线扩容 / 缩容"，核心是槽位迁移（数据随槽位移动），全程不中断服务。

3.1、扩容核心逻辑（新增主从节点）

1. 新增节点（主节点 A + 从节点 A1），通过 cluster meet 命令将其加入现有集群。

2. 现有主节点将部分槽位（及其对应数据）迁移到新主节点 A，迁移过程：

   源主节点标记槽位为 "迁移中"，暂停该槽位的写操作（毫秒级）。

   源主节点将槽位数据分批复制到新主节点 A。

   数据复制完成后，源主节点向集群广播 "槽位归属变更"，所有节点更新槽位映射。

3. 新主节点 A 正式接管迁移的槽位，从节点 A1 同步其数据，完成扩容。

3.2、缩容核心逻辑（移除主从节点）

1. 先将待移除主节点 B 的所有槽位，迁移到集群内其他健康主节点（流程同扩容的槽位迁移）。

2. 槽位迁移完成后，待移除节点 B 变为 "无槽位主节点"，通过 cluster forget 命令将其从集群中剔除。

3. 对应的从节点 B1 自动脱离集群，完成缩容。

4、Redis Cluster 与 主从 + Sentinel 对比

对比维度	主从 + Sentinel 架构	Redis Cluster 架构
存储扩容能力	仅支持垂直扩容（升级硬件），无横向扩容能力	支持横向扩容（新增节点分摊槽位），存储容量无上限
数据分布方式	所有节点存储全量数据，浪费磁盘资源	数据按槽位分片存储，主节点仅存部分数据，资源利用率高
架构复杂度	依赖哨兵集群（中心化监控），需额外维护	去中心化架构，无需哨兵，节点自管理，运维成本低
故障转移效率	主库故障时，全集群等待哨兵选举新主库（秒级）	单个主库故障时，其从库直接升级为主库（毫秒级），仅影响该主库的槽位
高并发支持	单主节点承受所有写操作，存在性能瓶颈	写操作分散到多个主节点，并发能力随节点数量线性提升
适用数据量	适合中小规模数据（单主节点内存可承载）	适合大规模数据（TB 级），支持海量存储

八、Redis 慢查询

1、定义

慢查询是 Redis 中执行时间超过预设阈值（slowlog-log-slower-than） 的命令记录，仅统计命令 "执行阶段" 的耗时（不包含网络传输、排队等待时间），本质是命令在 Redis 主线程中的执行耗时。

2、触发条件

• 核心触发阈值：命令执行时间 > slowlog-log-slower-than 配置值（单位：微秒，1 秒 = 1000000 微秒）。

• 默认阈值：10000 微秒（10 毫秒），即执行时间超过 10 毫秒的命令会被记录。

• 特殊情况：slowlog-log-slower-than = 0 时，记录所有命令；slowlog-log-slower-than < 0 时，关闭慢查询日志。

3、核心配置参数

• slowlog-log-slower-than 5000 ：单位为us，指定超过 5000us（5毫秒） 即为慢的指令，默认值为10000us，10ms。

• slowlog-max-len 1024 ：指定只保存最近的1024条慢记录，默认值为128。

4、配置方法

4.1、动态配置

通过 redis-cli 执行命令，即时生效

# 设置阈值为 5000 微秒（5 毫秒）
127.0.0.1:6379> config set slowlog-log-slower-than 5000
# 设置日志最大存储 1000 条
127.0.0.1:6379> config set slowlog-max-len 1000
# 保存配置到 redis.conf（避免重启失效，需开启持久化配置）
127.0.0.1:6379> config rewrite

4.2、静态配置

编辑 Redis 配置文件 redis.conf ，重启后永久生效

# 慢查询阈值（5 毫秒）
slowlog-log-slower-than 5000
# 日志最大存储 1000 条
slowlog-max-len 1000

5、运维场景

慢查询日志本身不影响 Redis 性能（日志存储在内存，循环覆盖），核心是通过日志找到 "拖慢主线程" 的命令，按 "查看 → 分析 → 优化" 三步解决。

5.1、查看慢查询日志

通过 slowlog 命令获取日志，支持查看指定条数

# 查看所有慢查询日志（按时间倒序，最新的在前）
127.0.0.1:6379> slowlog get
# 查看最近 10 条慢查询日志
127.0.0.1:6379> slowlog get 10

日志字段说明（示例解析）

1) 123  # 慢查询日志 ID（自增，不重复）
2) 1680000000  # 命令执行时间戳（秒级）
3) 8000  # 命令执行耗时（微秒，8 毫秒）
4) 1) "KEYS" 2) "*"  # 执行的命令及参数（此处是 KEYS *，全量遍历键）
5) "127.0.0.1:56789"  # 客户端 IP:端口
6) ""  # 客户端名称（未设置则为空）

5.2、分析日志核心维度

运维中重点关注 3 个维度，快速定位瓶颈：

• 命令类型：是否存在 KEYS、HGETALL、LRANGE 0 -1、SORT 等天然耗时的命令。

• 执行频率：同一慢命令是否频繁出现（如每秒多次 KEYS *，会持续阻塞主线程）。

• 数据量：命令操作的键是否存储了海量数据（如 HGETALL 操作百万字段的 Hash 键）。

5.3、常见性能问题与优化方案

1）高频执行 KEYS * / KEYS prefix*

问题：KEYS 命令会全量遍历所有键，时间复杂度 O (N)，数据量越大耗时越长，且阻塞主线程。

优化方案：

用 SCAN 命令替代（分批遍历，非阻塞，支持游标分页）：SCAN 0 MATCH prefix* COUNT 100。

提前规划键名规范，用 Hash 结构归类相关键（如 user:100、user:101 归类为 user Hash，避免遍历）。

2）大数据量全量查询（如 HGETALL、LRANGE 0 -1）

**问题：**HGETALL 会返回 Hash 所有字段和值，LRANGE 0 -1 会返回 List 所有元素，数据量超 10 万条时耗时显著。

优化方案：

Hash 键：用 HMGET 按需获取字段，或 HSCAN 分批遍历。

List 键：用 LRANGE 指定范围（如 LRANGE list 0 99 分页获取），避免全量查询。

拆分大数据键：将百万级 List 拆分为多个小 List（如 list:1、list:2），按业务分批访问。

3）复杂命令（如 SORT、ZUNIONSTORE 多集合操作）

**问题：**SORT 命令需排序 + 遍历，ZUNIONSTORE 多集合合并时计算量大，时间复杂度 O (N log N)。

优化方案：

避免高频使用：将排序、合并逻辑迁移到业务层（如先获取数据，在应用端排序）。

预计算结果：用定时任务（如 Redis Lua 脚本、业务 cron）提前计算复杂结果，存入新键，查询直接取预存值。

4）慢查询阈值不合理导致漏报 / 误报

**问题：**阈值设为 10 毫秒（默认），但高并发场景下，5 毫秒的命令已影响吞吐量；或阈值设为 1 毫秒，导致大量正常命令被误报。

优化方案：

结合业务 QPS 调整阈值：高并发场景（QPS 10 万 +）设为 2-5 毫秒，普通场景设为 5-10 毫秒。

限制日志条数：slowlog-max-len 设为 1000-5000 条，避免日志过多占用内存，同时保留足够分析样本。

九、核心数据类型

1、String（字符串）

1.1、核心特点

• 二进制安全：可存储字符串、数字、二进制数据（如图片 Base64），最大容量 512MB。

• 单值存储：键值一一对应，支持原子操作和过期时间。

1.2、底层实现

• 基础实现为简单动态字符串（SDS），相比 C 语言字符串，支持动态扩容、二进制安全，且记录长度（避免遍历计算）。

1.3、典型应用场景

• 缓存：存储商品详情、用户会话（SessionID 对应用户信息）。

• 计数器：点赞数、播放量、接口访问次数。

• 分布式锁：利用SET key value NX EX实现。

• 限流：结合INCR+EXPIRE实现接口分钟级限流。

1.4、常用命令

• SET key value [EX seconds]：设置键值，可选过期时间。

• GET key：获取键值。

• INCR key：数值型值自增 1（原子操作）。

• EXPIRE key seconds：设置键过期时间。

• MSET key1 val1 key2 val2：批量设置键值。

2、Hash（哈希）

2.1、核心特点

• 键值对集合：一个 Hash 键包含多个 field-value 对，适合存储对象。

• 按需获取：可单独操作某个 field，无需获取整个对象，节省带宽。

2.2、底层实现

• 数据量小时用压缩列表（ziplist），数据量大时切换为哈希表（dict），平衡空间和性能。

2.3、典型应用场景

• 存储对象：用户信息（昵称、年龄、头像）、商品属性（价格、库存、分类）。

• 购物车：用户 ID 为 Hash 键，商品 ID 为 field，数量为 value。

2.4、常用命令

• HSET key field value：设置 Hash 的 field-value。

• HGET key field：获取指定 field 的值。

• HMSET key field1 val1 field2 val2：批量设置 field。

• HMGET key field1 field2：批量获取 field。

• HDEL key field：删除指定 field。

3、List（列表）

3.1、核心特点

• 有序可重复：元素按插入顺序排列，支持首尾操作，本质是双向链表。

• 范围操作：支持按索引、范围获取元素，适合分页和队列场景。

3.2、底层实现

• 元素少、值小时用压缩列表，元素多或值大时切换为双向链表（linkedlist），支持双向遍历。

3.3、典型应用场景

• 消息队列：LPUSH（入队）+RPOP（出队）实现简单生产者 - 消费者模型。

• 最新列表：新闻 APP 最新资讯、商品评论列表（LPUSH新增，LRANGE分页查询）。

• 栈 / 队列：LPUSH+LPOP（栈）、LPUSH+RPOP（队列）。

3.4、常用命令

• LPUSH key value1 value2：从列表左侧插入元素。

• RPOP key：从列表右侧弹出元素。

• LRANGE key start end：获取索引范围内的元素（0 -1获取所有）。

• LLEN key：获取列表长度。

• LREM key count value：删除指定数量的 value 元素。

4、Set（集合）

4.1、核心特点

• 无序不可重复：自动去重，元素无固定顺序。

• 集合操作：支持交集、并集、差集，适合关系计算。

4.2、底层实现

• 元素为整数且数量少时用整数集合（intset），否则用哈希表（dict），查询复杂度 O (1)。

4.3、典型应用场景

• 去重：用户标签去重、投票候选人去重（避免重复投票）。

• 关系计算：好友列表（SADD添加好友）、共同关注（SINTER求交集）、推荐好友（SDIFF求差集）。

• 抽奖：SRANDMEMBER key [count]随机获取元素。

4.4、常用命令

• SADD key member1 member2：向集合添加元素。

• SMEMBERS key：获取集合所有元素。

• SINTER key1 key2：求两个集合的交集。

• SISMEMBER key member：判断元素是否在集合中。

• SREM key member：删除集合中的元素。

5、ZSet（有序集合）

5.1、核心特点

• 有序不可重复：每个元素关联一个 "分数（score）"，按分数排序，元素唯一。

• 范围查询：支持按分数、排名查询，适合实时排序场景。

5.2、底层实现

• 数据量小时用压缩列表，否则用 "跳表（skiplist）+ 哈希表"：跳表保证有序和范围查询效率，哈希表快速映射元素与分数。

5.3、典型应用场景

• 实时排行榜：游戏积分榜、直播礼物贡献榜、电商销量 TOP10（ZADD更新分数，ZRANGE查询排名）。

• 带权重的消息队列：按优先级（score）处理任务。

• 范围统计：查询分数在 [100, 200] 之间的用户。

5.4、常用命令

• ZADD key score1 member1 score2 member2：添加元素并设置分数。

• ZRANGE key start end [WITHSCORES]：按排名升序获取元素，可选显示分数。

• ZSCORE key member：获取元素的分数。

• ZINCRBY key increment member：增加元素的分数（原子操作）。

• ZREM key member：删除集合中的元素。