Redis on Snow

数据库全景指南：从 SQLite 到 MongoDB，一文搞懂选型与差异

Tue, 07 Jul 2026 21:04:00 +0800

数据库全景指南：从 SQLite 到 MongoDB，一文搞懂选型与差异

MySQL、PostgreSQL、MongoDB、Redis、Cassandra、Neo4j、Elasticsearch…… 数据库多到让人眼花。本文从分类、原理、模型、选型、组合五个维度，带你看清它们各自的边界与适用场景。

一、为什么会有这么多数据库？

先抛一个真实的尴尬场景：

新人入职第一天，被安排设计一个博客系统。他下意识打开 Navicat，建了一张 articles 表，写到第三天发现：文章正文要存富文本，字数可能上万；评论数据要嵌套在文章里；标签数量不固定；还要做全文搜索。继续用 MySQL 越写越别扭，最后只能上 ES 做搜索、MongoDB 存正文、MySQL 存元数据。

这不是个例。没有一种数据库能赢下所有场景，根本原因是存储需求里同时存在四组矛盾：

结构化 vs 灵活：业务模型固定还是多变
一致性 vs 可用性：要数据绝对正确，还是允许短暂数据不一致换可用性
规模 vs 性能：单机极致性能还是分布式海量吞吐
读写均衡 vs 海量写入：典型 Web 应用还是 IoT 流式写入

围绕这些矛盾，业界演化出了关系型、键值、文档、列族、图、搜索、时序、列存分析等 八大分支。每解决一组矛盾，就诞生一类新数据库。

二、数据库分类全景图

上图把主流数据库按"数据模型 + 适用场景"分成了 8 类。下面我们逐类展开，但在分类之前，必须先理解三个底层概念：ACID、CAP、BASE。它们决定了数据库的"性格"。

三、ACID vs BASE：两种一致性哲学

ACID：关系型数据库的承诺

ACID 是事务的四大保证，是关系型数据库压箱底的能力：

字母	含义	通俗解释
A Atomicity 原子性	事务要么全成功，要么全回滚	转账扣款和加款必须同时发生
C Consistency 一致性	事务前后满足所有约束	主键、外键、CHECK 不能被破坏
I Isolation 隔离性	并发事务互不干扰	MVCC + 锁机制保证
D Durability 持久性	提交后即使宕机也不丢	通过 WAL / redo log 实现

为 ACID 付出的代价：锁竞争、跨节点协调延迟、水平扩展难。这也是为什么单机 MySQL 通常撑到几千 QPS 就开始考虑读写分离。

BASE：分布式系统的妥协

当系统走向分布式，强一致性的代价过高，业界提出 BASE 作为 AP 系统的设计哲学：

BA Basically Available 基本可用：允许响应变慢、允许功能降级
S Soft State 软状态：允许存在中间状态
E Eventually Consistent 最终一致：不保证任意时刻一致，但保证最终收敛

关键认知：ACID 中的 C 是事务一致性（约束不被破坏），CAP 中的 C 是副本一致性（多节点数据相同），两者不是一回事。

四、CAP 定理：分布式系统的三角抉择

CAP 定理由 Eric Brewer 在 2000 年提出，断言：一个分布式系统最多只能同时满足 Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错）三者中的两个。

三个关键认知

① P 不可避免

真实分布式系统必然存在网络分区（交换机抖动、机房断连、节点宕机）。所以工程师实际上只能在 C 和 A 之间做选择：

分区时拒绝写入 → CP，保证数据正确，但牺牲可用性
分区时仍可读写 → AP，保证可用性，但允许数据短暂不一致

② 三种组合的典型代表

组合	牺牲项	典型数据库	典型场景
CA	分区容错	MySQL 单机、PostgreSQL 单机	传统单机业务
CP	可用性	HBase、MongoDB、Redis 集群	强一致优先的金融、配置
AP	一致性	Cassandra、DynamoDB、Eureka	高可用的社交、推荐

③ 同一业务可灵活切换

注册中心是个经典例子：ZooKeeper 是 CP，选举期间不可用；Eureka 是 AP，节点之间不强制同步。Netflix 选 Eureka，因为它能容忍注册信息短暂不一致，但不能容忍服务发现挂掉。

五、关系型数据库：稳如泰山的基石

关系型数据库以 二维表 + SQL + ACID 事务 为核心，是 90% 业务系统的默认选择。

5.1 五大主流 RDBMS 对比

数据库	厂商 / 协议	强项	适用场景
MySQL	开源（GPL/商业双协议）	生态成熟、运维资料最多	Web 应用、电商、CMS
PostgreSQL	开源（BSD）	复杂查询、JSON、PostGIS、扩展性强	复杂业务、地理数据、数据分析
SQLite	开源（公有领域）	嵌入式、零配置、单文件	移动端、嵌入式、原型、测试
Oracle	商业	企业级功能、稳定性、技术支持	银行、电信、政府核心系统
SQL Server	商业（微软）	与 .NET 生态深度集成	企业内部系统、Windows 环境

5.2 选型经验

个人项目 / 小工具：SQLite，单文件零配置
Web 应用首选：MySQL（运维生态好）或 PostgreSQL（功能强、复杂查询爽）
企业核心系统有预算：Oracle 或 SQL Server，看团队技术栈
要不要选 PostgreSQL 而不是 MySQL？ 如果业务里有复杂分析、地理数据、强约束、JSON 字段，PG 更合适；如果只是 CRUD + 简单关联，MySQL 更省心

5.3 关系型的硬伤

水平扩展难：分库分表后跨库 JOIN、事务都成噩梦，需要引入 ShardingSphere、Vitess 之类的中间件
Schema 变更贵：上亿行表加索引可能锁表几小时
高并发写入瓶颈：单机通常几千 QPS，靠缓存兜底

六、NoSQL 的崛起：四大家族

NoSQL（Not Only SQL）的核心动机：通过放松某个约束（一致性 / Schema / 关系），换取扩展性、性能或灵活性。

6.1 SQL vs NoSQL 数据模型对比

左图是关系型的方式：范式化拆表 + 外键关联，查 Alice 的订单要 JOIN 两张表。右图是文档型的方式：聚合存储 + 内嵌文档，Alice 的订单直接嵌在她的文档里，一次读取拿全。

两种模型各有利弊：

维度	关系型（SQL）	文档型（NoSQL）
Schema	严格固定	灵活可变
关联查询	JOIN 强	弱（要靠应用层）
数据冗余	低（范式化）	高（反范式）
事务	强 ACID	弱（多文档 4.0+ 才支持）
扩展性	垂直为主	易水平分片
适合	关系复杂、强一致	模型多变、读多写少

6.2 键值型：Redis

Redis 是最被低估的"瑞士军刀"。它表面上是个缓存，实际上能做：

缓存：最常见，热点数据加速
会话存储：分布式 Session
排行榜：ZSet 天生支持
消息队列：List / Stream
限流器：INCR + EXPIRE
分布式锁：SETNX / Redlock

选型提醒：Redis 是 CP 系统（集群模式下）—— 主节点挂掉会触发故障转移，期间集群不可用。不是所有 Redis 都"高可用"。

6.3 文档型：MongoDB

MongoDB 用 BSON（二进制 JSON）存储，每个文档自包含。它的甜点场景：

内容管理：文章、评论、附件，结构天然嵌套
IoT 设备元数据：不同设备字段不同，灵活 Schema 太香
快速迭代业务：需求变就加字段，不用 ALTER TABLE
日志聚合：MongoDB 的聚合管道 + 副本集很合用

坑点：MongoDB 4.0 才支持多文档事务，复杂事务场景慎用。索引设计不当会让查询慢到怀疑人生。

6.4 列族型：Cassandra / HBase

列族型数据库把"行"打散成"列族"，同一列的数据连续存储，对"按列聚合 + 海量写入"特别友好。

Cassandra：AWS Dynamo 论文的开源实现，无主架构，写入性能极强。Netflix、Instagram、Apple 都在用
HBase：基于 HDFS，强一致，适合离线大数据
ScyllaDB：用 C++ 重写的 Cassandra，性能高一个数量级

典型场景：时序数据、推荐特征存储、消息历史归档。Cassandra 在写入 QPS 上能轻松甩开 MySQL 一个数量级。

6.5 图型：Neo4j

如果业务核心是关系（不是表关联，而是多跳关系遍历），用图数据库比 SQL 递归查询快几个数量级。

// Neo4j 查询：找到 Alice 三度人脉里喜欢 Go 语言的人
MATCH (a:User {name:'Alice'})-[:KNOWS*1..3]-(friend:User)
WHERE friend.language = 'Go'
RETURN friend

典型场景：社交网络（好友推荐）、反欺诈（团伙识别）、知识图谱、IT 资产拓扑。

用 MySQL 写"找三度人脉"要用 4 层自连接，性能爆炸；Neo4j 用邻接表存储，时间复杂度近似 O(1)。

七、专用场景数据库：搜索 / 时序 / 列存

通用数据库做不到极致，专用数据库在特定领域把性能压榨到极限。

7.1 搜索引擎：Elasticsearch

ES 用 倒排索引 实现秒级全文检索，是 ELK（Elasticsearch + Logstash + Kibana）的核心。

商品搜索：分词、同义词、纠错、相关性排序
日志分析：海量日志聚合，按时间维度切片
可观测性：APM、链路追踪数据存储

重要认知：ES 不是数据库替代品。它写入延迟较高（近实时，1 秒刷新），不适合做强一致主存储。通常 MySQL 是真相源，ES 是搜索副本，通过 Canal/Debezium 同步。

7.2 时序数据库：InfluxDB / TimescaleDB

时序数据有显著特征：写多读少、按时间顺序、自动降采样、旧数据可丢弃。专用 TSDB 的写入性能比 MySQL 高 1-2 个数量级。

InfluxDB：Go 写的，单机性能强，TSM 存储引擎
TimescaleDB：PostgreSQL 扩展，能用 SQL，事务保证更好
Prometheus：监控专用，pull 模型
TDengine：国产，物联网场景优化

典型场景：服务器监控、IoT 传感器、金融行情、用户行为埋点。

7.3 列存分析：ClickHouse

OLAP 场景的核心诉求：扫描 TB 级数据，做 GROUP BY 聚合，秒级返回。行存数据库（MySQL）做这种扫描会读大量无关列，列存数据库只读需要的列，性能差几十倍。

-- ClickHouse 典型查询：秒级扫描 10 亿行
SELECT
    toDate(event_time) AS day,
    city,
    count() AS pv,
    uniq(user_id) AS uv
FROM events
WHERE event_time >= today() - 30
GROUP BY day, city
ORDER BY day DESC, pv DESC

对比：同样的查询，MySQL 要几十分钟，ClickHouse 通常 1 秒内。

八、数据库选型决策树

讲了这么多，实战怎么选？下图给出一份决策路径：

三条选型铁律

① 先 SQL，后 NoSQL

绝大多数项目从 MySQL / PostgreSQL 起步就够了。遇到具体瓶颈（缓存、搜索、海量写入、复杂关系）再引入对应专用数据库。一开始就上"全家桶"是过度设计。

② 没有银弹，组合使用

工业界真实系统几乎都是多库组合：核心业务用 MySQL/PG，缓存用 Redis，搜索用 ES，日志用 MongoDB/ES，监控用 InfluxDB，分析用 ClickHouse。让每个数据库只做它最擅长的事。

③ 团队熟悉度优先

再先进的数据库，没人会运维也是灾难。Cassandra 写入性能强，但运维门槛极高，国内很多团队踩坑后还是换回了 MySQL 分库分表。选团队能掌控的，而不是最潮的。

九、真实项目中的数据库组合架构

光说不练假把式。下图是一个典型电商系统的多库协同架构：

数据流拆解

① 写路径：订单服务先写 MySQL（强一致保证），同时发 Kafka 事件，下游消费者异步更新 ES 搜索索引和推荐系统特征库。这是经典的 “先写主库，再异步同步” 模式。

② 读路径：

请求类型	走的数据库	理由
商品详情	Redis 缓存 → MongoDB	缓存挡 95% 流量，回源用文档库装多变 SKU
商品搜索	Elasticsearch	倒排索引秒级响应
好友推荐	Neo4j	多跳关系遍历
个人订单	MySQL	强一致，按用户分库
监控大盘	InfluxDB	时序聚合，秒级出图

③ 监控旁路：所有服务通过 SDK 把指标推送到 InfluxDB，不参与业务主链路，监控挂掉不影响交易。这是旁路系统的设计铁律。

为什么要拆？

如果不拆，全塞进 MySQL 会发生什么？

商品搜索做 LIKE ‘%关键词%’ → 全表扫描，慢到超时
监控指标每秒几十万条写入 → MySQL 单机扛不住
好友推荐用 4 层自连接 → 几秒出不来结果
商品 SKU 字段每类目都不同 → ALTER TABLE 改到吐血

每个专用数据库的存在，都是为了 解决某一类 MySQL 不擅长的问题。

十、核心差异对照表

最后用一张表把主流数据库的关键指标摊开对比：

数据库	类型	一致性	Schema	事务	水平扩展	典型 QPS	适合场景
MySQL	关系	ACID	严格	强	难（需中间件）	几千	Web 主流
PostgreSQL	关系	ACID	严格	强	难	几千	复杂业务
SQLite	关系	ACID	严格	强	不可	单线程	嵌入式
Redis	KV	CP	无	弱	集群分片	10万+	缓存
MongoDB	文档	CP（可调）	灵活	4.0+ 多文档	易分片	几万	内容管理
Cassandra	列族	AP（可调）	灵活	弱	极易	10万+ 写入	海量写入
Neo4j	图	ACID	半结构	强	难	几千	关系网络
Elasticsearch	搜索	近实时	动态映射	弱	易分片	几万	全文搜索
InfluxDB	时序	CP	标签+字段	弱	集群版收费	10万+ 写入	监控指标
ClickHouse	列存	CP	严格	弱	易分片	100万+ 写入	大数据分析

总结

回到最初的问题：SQLite、MySQL、MongoDB 有什么区别？ 它们不是"谁更好"的关系，而是"为不同问题而生"的不同工具。

回顾本文核心要点：

没有银弹：每种数据库都是某组矛盾的产物，关系型解决一致性、NoSQL 解决扩展性、专用库解决极端场景
理论先行：理解 ACID / BASE / CAP，是看懂所有数据库设计意图的钥匙
SQL 不死：关系型依然是 90% 业务系统的默认选择，NoSQL 是补充而非替代
组合才是常态：工业界真实系统几乎都是多库协同，让每个数据库只做它最擅长的事
选型三铁律：先 SQL 后 NoSQL、没有银弹要组合、团队熟悉度优先

下一步行动建议：

审视你当前的项目：是不是把所有数据都塞在 MySQL 里了？哪些场景其实更适合专用数据库？
挑一个不熟的数据库试一试：Redis / MongoDB / ES 任选一个，跑一遍官方 Quick Start
关注 NewSQL：TiDB、CockroachDB、YugabyteDB 这些"既有 ACID 又能水平扩展"的下一代数据库正在崛起

记住：好的架构师不在于会多少种数据库，而在于知道每种数据库的边界在哪。

本文涉及的所有数据库选型都基于公开文档与工程实践，具体落地还需结合团队技术栈、运维能力、预算综合判断。

Redis面试八股文（持续更新）

Wed, 25 Mar 2026 22:08:57 +0800

本文档整理了后端开发面试中关于 Redis 最常被问到的高频面试题和深度解析，重点聚焦于底层原理、高并发场景下的缓存设计及高可用架构。

一、核心基础与数据结构

1. Redis 为什么这么快？

官方测试 Redis 的 QPS 可以达到 10万+，主要原因有：

完全基于内存：绝大部分请求是纯内存操作，速度极快。
高效的数据结构：Redis 专门设计了如 SDS（简单动态字符串）、跳表（SkipList）、压缩列表（ZipList）等高效的数据结构。
单线程模型：Redis 的网络 IO 和键值对读写是由一个线程来完成的，避免了不必要的上下文切换和竞争条件，不存在加锁解锁操作造成的性能损耗。（注：Redis 6.0 引入了多线程，但也只是用于网络 I/O 阶段，命令执行依然是单线程）。
I/O 多路复用模型：采用 epoll 作为 I/O 多路复用技术的实现，非阻塞 I/O，可以同时监听多个 Socket。

2. Redis 的五种基本数据类型及其底层数据结构？

面试不仅会问应用场景，一定会深挖底层结构：

数据类型	应用场景	底层数据结构（Redis 3.2+ / 7.0+ 有所演进）
String	缓存、计数器、分布式锁、Session（会话）	SDS (简单动态字符串)。比 C 字符串更安全、获取长度 O(1)、防止缓冲区溢出。
List	消息队列、文章列表、粉丝列表	QuickList (快速列表，双向链表 + 压缩列表的组合)。
Hash	存储对象、购物车	ZipList (压缩列表，数据少时) / HashTable (哈希表/字典，数据多时)。注：Redis 7.0 后 ZipList 替换为 ListPack。
Set	共同好友、点赞、抽奖	IntSet (整数集合，元素全为整数且较少时) / HashTable (字典)。
ZSet (Sorted Set)	排行榜、延时队列	ZipList (数据少时) / SkipList + HashTable (跳跃表+字典)。跳表保证范围查询效率 O(logN)，字典保证单点查询 O(1)。

3. ZSet 为什么使用跳表（SkipList）而不是红黑树或 B+ 树？

查询时，以查找 30 为例：

从最高层的最左侧开始。
如果当前节点的下一个节点比 30 小，就向右跳。
如果当前节点的下一个节点比 30 大或者已经是末尾，就向下掉一层。
重复此过程，直到在某一层找到 30，或者在底层确定该元素不存在。

跳表通过随机层数机制，平均每层节点数是下一层的 1/2 或 1/4，查询效率 O(logN)。插入和删除时只需要修改相邻节点的指针，维护成本较低。

对比红黑树：跳表实现更简单；在进行范围查找（如排行榜获取前 10 名）时，跳表只需要找到起点然后顺着底层链表遍历即可，而红黑树需要中序遍历，跳表效率更高；跳表的插入/删除只需修改相邻节点的指针，不需要像红黑树那样做复杂的旋转。

对比 B+ 树：B+ 树是为了最大限度减少磁盘 I/O 而设计的，树的高度较矮。但 Redis 是内存数据库，不需要考虑磁盘 I/O，跳表作为内存数据结构，其随机层数机制和简单的节点维护成本更低。

二、持久化机制

4. Redis 的持久化是怎么实现的？

Redis 提供了两种持久化机制：

RDB (Redis DataBase)：快照机制，定期将内存中的数据以二进制文件（dump.rdb）保存到磁盘。可以通过 save（阻塞）或 bgsave（异步，fork 子进程）命令触发，也可以配置自动触发条件。恢复时直接加载 RDB 文件到内存，速度快，但可能丢失两次快照之间的数据。
AOF (Append Only File)：日志机制，记录服务器执行的所有写操作命令（appendonly.aof）。可以配置不同的同步策略（always、everysec、no）。恢复时需要重新执行 AOF 文件中的命令，速度较慢，但数据安全性高（最多丢一秒的数据）。

5. RDB 和 AOF 持久化的区别？

特性	RDB (Redis DataBase)	AOF (Append Only File)
原理	快照：将某个时间点的所有内存数据以二进制文件（dump.rdb）保存。	日志：记录服务器执行的所有写操作命令（appendonly.aof）。
触发方式	save (阻塞), bgsave (异步，fork 子进程), 自动触发配置	always (每次写), everysec (每秒，默认), no (交由操作系统)
文件大小	较小（二进制压缩格式）	较大（文本格式记录了所有写命令）
恢复速度	快（直接把数据读入内存即可）	慢（需要把所有命令重新执行一遍）
数据安全性	容易丢数据（两次快照之间的数据会丢失）	安全性高（最多丢一秒的数据）

6. 什么是 AOF 重写（AOF Rewrite）？

随着命令不断写入，AOF 文件会越来越大。AOF 重写机制就是用来压缩 AOF 文件的。

原理：Redis 会 fork 出一个 bgrewriteaof 子进程，它会扫描当前内存中的数据，为每一个键值对生成一条对应的插入命令，写入到新的 AOF 文件中。比如以前对一个 key 进行了 100 次自增，重写后只会变成一条 SET key 100 的命令，大大减小了体积。
混合持久化：Redis 4.0 引入，AOF 重写时，将当前内存数据以 RDB 格式写入新 AOF 文件的开头，之后的新写入命令继续以 AOF 格式追加。结合了 RDB 恢复快和 AOF 数据不丢失的优点。

三、内存淘汰与过期策略

7. Redis 的过期键删除策略是什么？

Redis 使用了 惰性删除 + 定期删除 的配合策略：

惰性删除：平时不主动管，只有当客户端试图访问某个 key 时，Redis 才去检查它是否过期，如果过期了就删除并返回空。优点是省 CPU，缺点是如果过期 key 一直不被访问，会造成内存泄漏。
定期删除：Redis 默认每秒执行 10 次清理操作，随机抽取一部分设置了过期时间的 key，检查并删除已过期的。这种机制可以防止内存被大量无人访问的过期 key 占满。

8. Redis 的内存淘汰策略有哪些？（当内存满了怎么办）

当 Redis 内存使用达到 max memory 限制时，会触发淘汰策略：

noeviction（默认）：不淘汰数据，如果有写请求直接报错 (OOM)。
allkeys-lru：在所有 key 中，淘汰最近最少使用的 key（最常用）。
volatile-lru：在设置了过期时间的 key 中，淘汰最近最少使用的。
allkeys-random / volatile-random：随机淘汰。
volatile-ttl：淘汰即将过期的 key。
allkeys-lfu / volatile-lfu（Redis 4.0+ 引入）：淘汰使用频率最少的 key（Least Frequently Used）。解决了 LRU 无法应对偶发性冷数据全表扫描的问题。

四、缓存高并发经典问题（穿透、击穿、雪崩）

9. 什么是缓存穿透？如何解决？

定义：查询一个根本不存在的数据，缓存中肯定查不到（不命中），导致请求每次都要去数据库查，如果有人恶意疯狂请求这个不存在的 key，数据库可能会瞬间崩掉。
解决方案：
1. 缓存空对象/默认值：当数据库查不到时，依然把这个空结果（如 null）存入缓存，设置一个较短的过期时间。
2. 布隆过滤器 (Bloom Filter)：在请求到达缓存之前，先经过布隆过滤器判断该 key 是否存在。如果布隆过滤器说不存在，那一定不存在，直接返回；如果说存在（有极小误判率），再去查缓存和 DB。
补充：布隆过滤器是一个空间效率极高的概率型数据结构，可以判断一个元素是否在一个集合中。它使用多个哈希函数将元素映射到一个位数组上，查询时同样通过哈希函数检查对应位是否为 1。虽然存在误判（可能会误判某个不存在的元素为存在），但绝不会漏判（真正存在的元素一定会被识别）。因此非常适合用来做缓存穿透的第一道防线。

10. 什么是缓存击穿？如何解决？

定义：一个极度热点的数据（比如秒杀商品），在缓存过期的瞬间，有极其庞大的并发请求过来。因为缓存失效了，这几万个请求会同时去穿透到数据库，导致数据库瞬间崩溃。
解决方案：
1. 互斥锁 (Mutex Lock)：在缓存失效去数据库查询重建缓存的这个步骤加上分布式锁（如 Redis 的 SETNX）。保证只有一个请求能打到 DB 并更新缓存，其他请求拿不到锁就休眠重试。
2. 逻辑过期 (热点数据永不过期)：物理上不设置 TTL，而是在 value 内部维护一个逻辑过期时间字段。发现逻辑过期时，异步开启一个线程去更新缓存，当前请求先返回旧数据。
补充：分布式锁是分布式系统中用来保证多个进程或线程之间互斥访问共享资源的机制。它的实现细节非常重要，必须保证“谁加的锁只有谁能解”，防止误删别人的锁。通常会在加锁时设置一个唯一的随机值（如 UUID），解锁时通过 Lua 脚本比对这个值，只有匹配成功才删除锁。

11. 什么是缓存雪崩？如何解决？

定义：大量的热点 key 在同一时间集中过期，或者 Redis 服务宕机。导致海量请求直接打到数据库，引发数据库宕机乃至整个系统雪崩。
解决方案：
1. 打散过期时间：在设置 TTL 时，给基础时间加上一个随机值（如 1-5 分钟），避免大量 key 在同一秒过期。
2. 服务高可用：搭建 Redis 哨兵 (Sentinel) 或集群 (Cluster) 架构，防止 Redis 单点故障。
3. 限流降级：在应用层（如使用 Sentinel/Hystrix）做好限流熔断，保护底层数据库。

五、分布式锁与双写一致性

12. 如何用 Redis 实现分布式锁？

基础版本：使用 SET resource_name my_random_value NX PX 30000。
- NX：表示 Not eXists，只有 key 不存在时才设置成功（保证互斥性）。
- PX 30000：设置过期时间为 30 秒（防止宕机死锁）。
- my_random_value：必须是客户端唯一的随机 ID，解锁时通过 Lua 脚本比对这个值，保证“谁加的锁只有谁能解”，防止误删别人的锁。
进阶版本 (Redisson)：基础版本的锁如果业务执行时间太长，锁提前过期了怎么办？Redisson 框架提供了 看门狗 (Watch Dog) 机制。加锁成功后，会开启一个后台线程，每隔 10 秒（默认超时时间 30s 的 1/3）检查一下业务是否还在执行，如果还在执行就将锁的过期时间续期回 30s。

13. Redis 和 MySQL 如何保证双写一致性？

这是面试高频必杀题。标准的处理模式是 Cache Aside Pattern（旁路缓存模式）。

标准操作：先更新数据库，再删除缓存。
为什么不能先更新缓存再更新 DB？ 如果 DB 更新失败，缓存就是脏数据。
为什么不能先删缓存再更新 DB？ 在并发环境下，线程 A 删了缓存还没更新 DB，线程 B 进来查缓存没命中，去 DB 读到了旧数据并写入缓存。然后 A 更新了 DB。导致缓存里永远是旧数据。
先更新 DB 再删缓存，有没有可能出问题？ 有。A 查 DB 读到旧数据（还未写缓存），B 更新 DB 并删缓存，A 将刚才的旧数据写入缓存。但这种情况概率极低（要求写操作比读操作还快）。
为什么是删除缓存而不是更新缓存？ 因为更新缓存需要保证原子性（更新 DB 和更新缓存必须是一个原子操作），而 Redis 没有提供这样的事务机制。删除缓存后，下一次读请求会去 DB 读到最新数据并写入缓存。
解决方案：
1. 加分布式锁：在更新 DB 和删除缓存的过程中加锁，保证同一时间只有一个线程能操作这个 key。缺点是性能较差，增加了复杂度。
2. 逻辑过期：不设置物理过期时间，而是在 value 内部维护一个逻辑过期时间字段。更新 DB 后，直接更新缓存并重置逻辑过期时间。读请求发现逻辑过期时，异步开启一个线程去更新缓存，当前请求先返回旧数据。缺点是可能会有短暂的脏数据窗口。
终极保障方案（延迟双删 / 消息队列）：
1. 延迟双删：先删缓存 -> 更新 DB -> 睡眠（如 500ms） -> 再次删缓存。确保把读请求可能产生的脏缓存删掉。
2. 基于 Canal + 消息队列（推荐）：业务代码只管更新数据库。通过 Canal 伪装成 MySQL 从节点监听 binlog，提取出修改的数据后扔到 MQ 中，消费者订阅 MQ 去异步且可靠地删除 Redis 缓存。

六、高可用与集群架构

14. 主从复制的原理是什么？

全量同步：当从节点第一次连接主节点时。主节点执行 bgsave 生成 RDB 文件发送给从节点，从节点加载。期间主节点的新写命令会存入 replication buffer，RDB 发送完后再把 buffer 里的命令发给从节点。
增量同步：网络断开重连后，主节点根据从节点上报的 offset，从 repl_backlog_buffer（环形缓冲区）中把断开期间的命令发给从节点，无需重新全量同步。

15. 什么是哨兵模式 (Sentinel)？

主从复制无法自动故障转移。哨兵就是用来监控主从节点的：

监控：不断向主从节点发送 PING 检查是否在线（主观下线、客观下线）。
故障转移 (Failover)：主节点挂了，哨兵集群会通过 Raft 算法选举出一个 Leader 哨兵，由它在从节点中选出一个新的主节点（根据优先级、复制偏移量 offset、RunID 选举）。
通知：将新的主节点信息通知给客户端和其他从节点。

16. Redis Cluster 集群的原理？什么是哈希槽 (Hash Slot)？

哨兵模式解决了高可用，但无法解决单机内存上限和写并发能力瓶颈。Redis Cluster 提供了**分布式（分片）**方案。

哈希槽：Redis 集群没有使用一致性 Hash，而是引入了 16384 个哈希槽。集群的每个主节点负责一部分槽。
寻址过程：当客户端发送命令时，对 key 使用 CRC16 算法取模 16384，计算出该 key 属于哪个槽。
去中心化：集群中没有中心节点，节点之间通过 Gossip 协议交换彼此的状态和槽信息。如果客户端请求打到了错误的节点，节点会返回 MOVED 重定向指令，让客户端去正确的节点操作。

Redis基础学习文档

Tue, 24 Mar 2026 17:05:27 +0800

Redis基础学习文档

基础篇

Redis数据结构介绍

Redis是一个key-value的数据库，key一般是String类型，value的类型多种多样：我们可以在官网（https://redis.io/commands）查看不同的命令用法。同时我们也可以在命令行通过help指令来查找命令。

Redis的通用命令

通用命令是部分数据类型的，都可以使用的命令，常见的有：

KEYS：查看符合模板的所有key。模糊查询的效率不高，又因为Redis是单线程的，所以不建议在生产环境设备上使用
DEL：删除一个或多个指定的key
EXISTS：检查一个或多个key是否存在
EXPIRE：为一个key设置有效期（过期时间），单位为秒，有效期到期时，key会被自动删除
TTL：查看一个key的剩余有效期，单位为秒注意：当一个key设置了过期时间后，如果在过期时间到期之前再次设置了过期时间，那么原来的过期时间会被覆盖掉，新的过期时间会重新计算。并且过期后TTL命令会返回-2，表示key不存在了；如果一个key没有设置过期时间，那么TTL命令会返回-1，表示这个key是永久有效的。

String类型

String类型是Redis中最基本的数据类型，key和value都是字符串类型。不过根据字符串的格式不同，String类型又可以分为以下几种：

普通字符串：普通的字符串类型，可以存储任何文本数据，最大长度为512MB。
数字字符串：可以存储整数或浮点数，可以进行数学运算和自增操作。
二进制字符串：可以存储二进制数据，如图片、音频等非文本数据。
JSON字符串：可以存储JSON格式的数据，可以方便地进行数据交换和存储复杂的数据结构。

不管是哪种格式，底层都是字节数组形式存储，只不过是编码方式不同。字符串类型的最大空间不能超过512MB，如果超过了这个限制，Redis会返回错误。

String类型的常用命令有：

SET：设置一个key的值，如果key已经存在，则覆盖原来的值
GET：获取一个key的值，如果key不存在，则返回nil
MSET：同时设置多个key的值
MGET：同时获取多个key的值
INCR：将一个key的值加1，如果key不存在，则先将其设置
INCRBY：将一个key的值加上指定的整数，如果key不存在，则先将其设置。也可以实现自减的效果。
INCRBYFLOAT：将一个key的值加上指定的浮点数，如果key不存在，则先将其设置
DECR：将一个key的值减1，如果key不存在，则先将其设置
DECRBY：将一个key的值减去指定的整数，如果key不存在，则先将其设置
SETNX：只有当key不存在时才设置key的值，如果key已经存在，则不做任何操作
SETEX：设置一个key的值，并为key设置过期时间，单位为秒
PSETEX：设置一个key的值，并为key设置过期时间，单位为毫秒

KEY的层级结构

Redis的key是一个字符串，可以包含任何字符，包括空格和特殊字符。为了方便管理和组织key，Redis没有提供真正的层级结构，但我们可以通过在key中使用分隔符（如冒号:）来模拟层级结构。例如，我们有一个项目叫heima，有user和product两种不同类型的数据，我们可以这样定义key：

user相关的key：heima:user:1、heima:user:2、heima:user:3等
product相关的key：heima:product:1、heima:product:2、heima:product:3等

如果value是一个对象，例如一个user对象，我们可以将其序列化成JSON字符串存储在Redis中，这样就可以方便地进行数据交换和存储复杂的数据结构。

Hash类型

Hash类型，也叫散列，其value是一个无序字典，类似于C++中的unordered_map。Hash类型的key是一个字符串，而value是一个包含多个field和value的字典。每个field都是一个字符串，每个value也是一个字符串。主要特征有：

Hash类型的元素是无序的，不能通过索引访问
Hash类型的元素是唯一的，不能重复
Hash类型的元素可以在字典中添加或删除
查询速度快，适合于需要频繁查询的场景，例如用户信息、商品信息等。

Hash类型的常用命令有：

HSET key field value：设置hash表key中field的值为value，如果key不存在，则创建一个新的hash表；如果field已经存在，则覆盖原来的值
HGET key field：获取hash表key中field的值，如果key不存在或field不存在，则返回nil
HMSET key field1 value1 field2 value2 ...：同时设置hash表key中多个field的值，如果key不存在，则创建一个新的hash表；如果field已经存在，则覆盖原来的值
HMGET key field1 field2 ...：同时获取hash表key中多个field的值，如果key不存在或field不存在，则返回nil
HGETALL key：获取hash表key中所有field和value的值，如果key不存在，则返回nil
HKEYS key：获取hash表key中所有field的值，如果key不存在，则返回nil
HVALS key：获取hash表key中所有value的值，如果key不存在，则返回nil
HDEL key field1 field2 ...：删除hash表key中指定的field，如果key不存在或field不存在，则不做任何操作
HLEN key：获取hash表key中field的数量，如果key不存在，则返回0
HEXISTS key field：检查hash表key中是否存在field，如果key不存在或field不存在，则返回0；如果存在，则返回1
HINCRBY key field increment：将hash表key中field的值加上指定的整数increment，如果key不存在，则先创建一个新的hash表；如果field不存在，则先将其设置为0；如果field的值不是一个整数，则返回错误
HSETNX key field value：只有当hash表key中field不存在时才设置field的值为value，如果key不存在，则先创建一个新的hash表；如果field已经存在，则不做任何操作

List类型

Redis的List类型与C++中的std::list类似，是一个双向链表。List类型的key是一个字符串，而value是一个包含多个元素的列表，每个元素都是一个字符串。特征也与std::list类似：

List类型的元素是有序的，可以通过索引访问
List类型的元素可以重复
List类型的元素可以在头部或尾部添加或删除
查询速度一般，适合于需要频繁插入和删除的场景，例如消息队列、任务列表等。常用来存储一个有序数据，例如朋友圈点赞列表、微博评论列表等。

List类型的常用命令有：

LRANGE key start stop：获取列表key中指定范围内的元素，start和stop都是索引，索引从0开始，负数表示从列表尾部开始计算，例如-1表示最后一个元素，-2表示倒数第二个元素，以此类推。如果key不存在，则返回nil；如果start或stop超出范围，则返回空列表
LPUSH key value1 value2 ...：将一个或多个值插入到列表key的头部，如果key不存在，则创建一个新的列表；如果key存在但不是列表类型，则返回错误
LPOP key：移除并返回列表key的头部元素，如果key不存在或列表为空，则返回nil
RPUSH key value1 value2 ...：将一个或多个值插入到列表key的尾部，如果key不存在，则创建一个新的列表；如果key存在但不是列表类型，则返回错误
RPOP key：移除并返回列表key的尾部元素，如果key不存在或列表为空，则返回nil
LLEN key：获取列表key中元素的数量，如果key不存在，则返回0
LINDEX key index：获取列表key中指定索引位置的元素，如果key不存在或索引超出范围，则返回nil
LSET key index value：设置列表key中指定索引位置的元素为value，如果key不存在或索引超出范围，则返回错误
BLPOP key [key ...] timeout：移除并返回一个或多个列表key的头部元素，如果key不存在或列表为空，则返回nil；如果timeout为0，表示永远等待；如果timeout为正整数，表示等待指定的秒数，如果在等待期间有元素被添加到列表中，则立即返回；如果在等待期间没有元素被添加到列表中，则返回nil
BRPOP key [key ...] timeout：移除并返回一个或多个列表key的尾部元素，如果key不存在或列表为空，则返回nil；如果timeout为0，表示永远等待；如果timeout为正整数，表示等待指定的秒数，如果在等待期间有元素被添加到列表中，则立即返回；如果在等待期间没有元素被添加到列表中，则返回nil BLPOP和BRPOP命令常用于实现消息队列的功能，例如生产者将消息推送到列表中，消费者从列表中弹出消息进行处理。如果消费者在等待期间没有收到消息，可以设置一个超时时间来避免无限等待。

Set类型

Redis的Set类型是一种无序集合，类似于C++中的std::unordered_set，可以看作是一个value为null的Hash类型。因为也是一个hash表，所以具备与Hash类型相似的特征：

Set类型的元素是无序的，不能通过索引访问
Set类型的元素是唯一的，不能重复
Set类型的元素可以在集合中添加或删除
查询速度快，适合于需要频繁查询的场景，例如标签系统、好友关系等。

Set类型的常用命令有：

SADD key member1 member2 ...：将一个或多个成员添加到集合key中，如果key不存在，则创建一个新的集合；如果key存在但不是集合类型，则返回错误
SREM key member1 member2 ...：从集合key中移除一个或多个成员，如果key不存在或成员不存在，则不做任何操作
SCARD key：获取集合key中成员的数量，如果key不存在，则返回0
SISMEMBER key member：检查集合key中是否存在成员，如果key不存在或成员不存在，则返回0；如果存在，则返回1
SMEMBERS key：获取集合key中所有成员的值，如果key不存在，则返回nil
SINTER key1 key2 ...：获取一个或多个集合key的交集，如果key不存在，则返回nil；如果key存在但不是集合类型，则返回错误
SUNION key1 key2 ...：获取一个或多个集合key的并集，如果key不存在，则返回nil；如果key存在但不是集合类型，则返回错误
SDIFF key1 key2 ...：获取一个或多个集合key的差集，如果key不存在，则返回nil；如果key存在但不是集合类型，则返回错误

Sorted Set类型

Redis的SortedSet类型是一个可排序的set几何，与C++中的std::set类似，但底层数据结构却差别很大。SortedSet中的每一个元素都带有一个分数（score），Redis会根据分数来对元素进行排序。底层实现是一个跳表（skip list），跳表是一种基于链表的数据结构，通过增加多级索引来提高查询效率。SortedSet具备以下特性：

SortedSet类型的元素是有序的，可以通过索引访问
SortedSet类型的元素是唯一的，不能重复
SortedSet类型的元素可以在集合中添加或删除
查询速度快，适合于需要频繁查询的场景，例如排行榜、社交网络等。因为SortedSet的可排序特性，经常被用来实现排行榜这样的功能。

SortedSet类型的常用命令有：

ZADD key score1 member1 [score2 member2 ...]：将一个或多个成员添加到有序集合key中，并为每个成员设置分数，如果key不存在，则创建一个新的有序集合；如果key存在但不是有序集合类型，则返回错误；如果成员已经存在，则更新其分数
ZREM key member1 member2 ...：从有序集合key中移除一个或多个成员，如果key不存在或成员不存在，则不做任何操作
ZSCORE key member：获取有序集合key中成员的分数，如果key不存在或成员不存在，则返回nil
ZRANK key member：获取有序集合key中成员的排名，排名从0开始，如果key不存在或成员不存在，则返回nil
ZREVRANK key member：获取有序集合key中成员的反向排名，排名从0开始，如果key不存在或成员不存在，则返回nil
ZCARD key：获取有序集合key中成员的数量，如果key不存在，则返回0
ZCOUNT key min max：获取有序集合key中分数在min和max之间的成员数量，如果key不存在，则返回0；如果key存在但不是有序集合类型，则返回错误
ZINCRBY key increment member：将有序集合key中成员的分数增加increment，如果key不存在，则先创建一个新的有序集合；如果成员不存在，则先将其设置为0；如果成员的分数不是一个数字，则返回错误
ZRANGE key start stop [WITHSCORES]：获取有序集合key中指定范围内的成员，start和stop都是索引，索引从0开始，负数表示从集合尾部开始计算，例如-1表示最后一个成员，-2表示倒数第二个成员，以此类推。如果key不存在，则返回nil；如果start或stop超出范围，则返回空列表；如果指定了WITHSCORES选项，则返回成员和分数的列表
ZREVRANGE key start stop [WITHSCORES]：获取有序集合key中指定范围内的成员，start和stop都是索引，索引从0开始，负数表示从集合尾部开始计算，例如-1表示最后一个成员，-2表示倒数第二个成员，以此类推。如果key不存在，则返回nil；如果start或stop超出范围，则返回空列表；如果指定了WITHSCORES选项，则返回成员和分数的列表
ZRANGEBYSCORE key min max [WITHSCORES]：获取有序集合key中分数在min和max之间的成员，如果key不存在，则返回nil；如果key存在但不是有序集合类型，则返回错误；如果指定了WITHSCORES选项，则返回成员和分数的列表
ZINTER key numkeys key1 key2 ...：获取一个或多个有序集合key的交集，如果key不存在，则返回nil；如果key存在但不是有序集合类型，则返回错误；如果指定了WITHSCORES选项，则返回成员和分数的列表
ZUNION key numkeys key1 key2 ...：获取一个或多个有序集合key的并集，如果key不存在，则返回nil；如果key存在但不是有序集合类型，则返回错误；如果指定了WITHSCORES选项，则返回成员和分数的列表
ZDIFF key numkeys key1 key2 ...：获取一个或多个有序集合key的差集，如果key不存在，则返回nil；如果key存在但不是有序集合类型，则返回错误；如果指定了WITHSCORES选项，则返回成员和分数的列表
ZINTERSTORE destination numkeys key1 key2 ...：计算一个或多个有序集合key的交集，并将结果存储在destination中，如果destination已经存在，则覆盖原来的值；如果key不存在，则返回nil；如果key存在但不是有序集合类型，则返回错误
ZUNIONSTORE destination numkeys key1 key2 ...：计算一个或多个有序集合key的并集，并将结果存储在destination中，如果destination已经存在，则覆盖原来的值；如果key不存在，则返回nil；如果key存在但不是有序集合类型，则返回错误
ZDIFFSTORE destination numkeys key1 key2 ...：计算一个或多个有序集合key的差集，并将结果存储在destination中，如果destination已经存在，则覆盖原来的值；如果key不存在，则返回nil；如果key存在但不是有序集合类型，则返回错误

Redis on Snow

数据库全景指南：从 SQLite 到 MongoDB，一文搞懂选型与差异

数据库全景指南：从 SQLite 到 MongoDB，一文搞懂选型与差异

一、为什么会有这么多数据库？

二、数据库分类全景图

三、ACID vs BASE：两种一致性哲学

ACID：关系型数据库的承诺

BASE：分布式系统的妥协

四、CAP 定理：分布式系统的三角抉择

三个关键认知

五、关系型数据库：稳如泰山的基石

5.1 五大主流 RDBMS 对比

5.2 选型经验

5.3 关系型的硬伤

六、NoSQL 的崛起：四大家族

6.1 SQL vs NoSQL 数据模型对比

6.2 键值型：Redis

6.3 文档型：MongoDB

6.4 列族型：Cassandra / HBase

6.5 图型：Neo4j

七、专用场景数据库：搜索 / 时序 / 列存

7.1 搜索引擎：Elasticsearch

7.2 时序数据库：InfluxDB / TimescaleDB

7.3 列存分析：ClickHouse

八、数据库选型决策树

三条选型铁律

九、真实项目中的数据库组合架构

数据流拆解

为什么要拆？

十、核心差异对照表

总结

Redis面试八股文（持续更新）

一、 核心基础与数据结构

1. Redis 为什么这么快？

2. Redis 的五种基本数据类型及其底层数据结构？

3. ZSet 为什么使用跳表（SkipList）而不是红黑树或 B+ 树？

二、 持久化机制

4. Redis 的持久化是怎么实现的？

5. RDB 和 AOF 持久化的区别？

6. 什么是 AOF 重写（AOF Rewrite）？

三、 内存淘汰与过期策略

7. Redis 的过期键删除策略是什么？

8. Redis 的内存淘汰策略有哪些？（当内存满了怎么办）

四、 缓存高并发经典问题（穿透、击穿、雪崩）

9. 什么是缓存穿透？如何解决？

10. 什么是缓存击穿？如何解决？

11. 什么是缓存雪崩？如何解决？

五、 分布式锁与双写一致性

12. 如何用 Redis 实现分布式锁？

13. Redis 和 MySQL 如何保证双写一致性？

六、 高可用与集群架构

14. 主从复制的原理是什么？

15. 什么是哨兵模式 (Sentinel)？

16. Redis Cluster 集群的原理？什么是哈希槽 (Hash Slot)？

Redis基础学习文档

Redis基础学习文档

基础篇

Redis数据结构介绍

Redis的通用命令

String类型

KEY的层级结构

Hash类型

List类型

Set类型

Sorted Set类型

一、核心基础与数据结构

二、持久化机制

三、内存淘汰与过期策略

四、缓存高并发经典问题（穿透、击穿、雪崩）

五、分布式锁与双写一致性

六、高可用与集群架构