企业官网建设流程全解析

难度等级：中级-高级
适合读者：有 Python 基础的开发者，准备面试的中高级工程师
前置知识：第 17 篇《ORM 最佳实践与数据库设计模式》、基本的键值存储概念

导读

Redis（Remote Dictionary Server）是当今最流行的内存数据结构存储系统。很多人将 Redis 简单地理解为"缓存"，但这远远低估了它的能力。Redis 是一个多模型数据结构服务器——它提供了 String、Hash、List、Set、Sorted Set 等丰富的数据结构，以及 HyperLogLog、Bitmap、Stream、GEO 等高级结构，能够优雅地解决计数器、排行榜、消息队列、分布式锁、地理位置查询等多种业务问题。

对于 Python 后端工程师来说，Redis 是面试的高频考点和日常开发的核心基础设施。“Redis 的五种数据结构及应用场景”、“缓存穿透/击穿/雪崩的区别与解决方案”、“Redis 的持久化机制”——这些问题在几乎每场后端面试中都会出现。

本文将从 Redis 的核心数据结构出发，系统性地讲解每种结构的底层实现、适用场景和最佳实践，然后深入持久化机制和缓存策略设计，最后展示 Python 与 Redis 的集成实战。

学习目标

读完本文后，你将能够：

1. 掌握 Redis 五大基础数据结构的底层实现和典型应用场景
2. 理解 HyperLogLog、Bitmap、Stream、GEO 四种高级数据结构的使用
3. 深入理解 RDB 和 AOF 两种持久化机制的原理和权衡
4. 掌握 Cache-Aside 等缓存策略，解决缓存穿透/击穿/雪崩问题
5. 使用 redis-py 进行连接池配置、Pipeline 批量操作和 Lua 脚本
6. 在面试中清晰地回答 Redis 相关的高频问题

一、五大基础数据结构深度解析

Redis 的五大基础数据结构不是简单的数据容器，每种结构都有精心设计的底层编码和丰富的命令集。理解"用什么结构解决什么问题"是 Redis 使用的核心能力。

1.1 String：最基础也最万能

String 是 Redis 最基本的数据类型，但它的底层并不总是简单的字符串——Redis 会根据值的内容自动选择编码方式：

典型应用场景：

1. 计数器（原子递增/递减）：

• 文章阅读量、API 调用次数、限流计数
• 利用INCR/INCRBY的原子性，天然线程安全

2. 分布式 Session：

• 将 Session 数据序列化后存入 Redis String
• 配合 TTL 实现自动过期
• 水平扩展的 Web 应用通过 Redis 共享 Session

3. 分布式锁（基础版）：

• SET key value NX EX timeout：原子性的"不存在则设置 + 设置过期时间"
• NX 保证互斥，EX 防止死锁

4. 缓存序列化对象：

• 将 Python 对象 JSON 序列化后存入
• 配合 TTL 实现自动缓存失效

1.2 Hash：对象存储的最佳选择

Hash 是字符串字段到字符串值的映射，非常适合存储对象的属性集合。底层编码在元素少且值小时使用ziplist（Redis 7.0+ 改为 listpack），元素多时转为hashtable。

Hash vs String 存储对象：

方案1: 一个 String 存整个 JSON SET user:1001 '{"name":"Alice","age":25,"city":"Beijing"}' 缺点：修改单个字段需要读取、反序列化、修改、序列化、写回 方案2: 每个字段一个 String SET user:1001:name "Alice" SET user:1001:age "25" SET user:1001:city "Beijing" 缺点：Key 太多，内存开销大（每个 key 有额外元数据开销） 方案3: Hash（推荐） HSET user:1001 name "Alice" age 25 city "Beijing" 优点：可以单独读写任意字段，内存紧凑，逻辑上是一个整体

典型应用场景：

1. 用户画像/配置信息：

• HSET user:1001 name "Alice" vip_level 3 balance 99.5
• 可以HINCRBY user:1001 balance -10原子性扣费

2. 购物车：

• Key:cart:{user_id}，Field: 商品 ID，Value: 数量
• HINCRBY cart:1001 sku_8899 2加2件商品

3. 对象缓存（部分字段热点访问）：

• 当只需要频繁读取对象的个别字段时，Hash 比 String + JSON 更高效

1.3 List：有序队列

List 是双向链表（Redis 3.2+ 底层使用quicklist，即 ziplist 链表），支持从两端 O(1) 推入和弹出。

典型应用场景：

1. 消息队列（简单版）：

• 生产者LPUSH queue:tasks "task_data"
• 消费者BRPOP queue:tasks 0（阻塞式弹出，0 表示无限等待）
• 局限：没有 ACK 机制，消费者崩溃会丢消息

2. 最新列表（Timeline）：

• LPUSH timeline:user1 "new_post_id"
• LTRIM timeline:user1 0 99（只保留最新 100 条）
• LRANGE timeline:user1 0 9（获取最新 10 条）

3. 限流窗口（滑动窗口）：

• 用 List 记录每次请求的时间戳
• 定期 LTRIM 清除窗口外的记录

1.4 Set：无序唯一集合

Set 是无序的唯一字符串集合，支持高效的成员判断（O(1)）和集合运算（交集、并集、差集）。底层在元素少且都是整数时使用intset，否则使用hashtable。

典型应用场景：

1. 标签系统：

• SADD article:1001:tags "python" "backend" "redis"
• 查找同时有 “python” 和 “redis” 标签的文章：SINTER tag:python tag:redis

2. 共同好友/共同关注：

• SADD user:1001:friends "user_1002" "user_1003" "user_1004"
• SINTER user:1001:friends user:1005:friends（共同好友）

3. 去重：

• 统计一篇文章的独立访客：SADD article:1001:visitors "user_xxx"
• SCARD article:1001:visitors（去重后的访客数）

4. 抽奖系统：

• SADD lottery:2024 "user1" "user2" "user3"...
• SRANDMEMBER lottery:2024 3（随机抽3人，不移除）
• SPOP lottery:2024 1（随机抽1人并移除，不可重复中奖）

1.5 Sorted Set：有序唯一集合

Sorted Set（ZSet）是 Redis 最强大的数据结构之一。每个成员关联一个 score（浮点数），集合按 score 排序。底层使用跳表（skiplist）+ hashtable实现（小数据量时用 ziplist/listpack）。

跳表为什么被 Redis 选中（面试常问）：

相比平衡树（如红黑树），跳表的优势：

1. 实现简单：代码量小，容易调试和维护
2. 范围查询更友好：跳表天然有序，范围查询只需沿着底层链表遍历
3. 并发友好：插入/删除只需修改局部指针，锁粒度更小
4. 内存局部性：链表节点可能在连续内存中（配合 jemalloc）

典型应用场景：

1. 排行榜：

• ZADD leaderboard 9500 "player_A" 8800 "player_B" 9200 "player_C"
• ZREVRANGE leaderboard 0 9 WITHSCORES（Top 10，按分数降序）
• ZRANK leaderboard "player_B"（获取排名，O(log N)）
• ZINCRBY leaderboard 100 "player_B"（加分）

2. 延迟队列/定时任务：

• Score 设为任务的执行时间戳
• ZADD delay_queue 1713600000 "task_data"
• 消费者轮询：ZRANGEBYSCORE delay_queue 0 {current_timestamp} LIMIT 0 10

3. 滑动窗口限流：

• Score 设为请求时间戳，Member 设为请求唯一标识
• 删除窗口外的记录：ZREMRANGEBYSCORE rate:user1 0 {window_start}
• 统计窗口内数量：ZCARD rate:user1

二、高级数据结构

2.1 HyperLogLog：基数统计

HyperLogLog（HLL）是一种概率数据结构，用于统计集合中不同元素的数量（基数），使用极小的内存（每个 HLL 固定 12KB）即可统计 2^64 个不同元素，标准误差约 0.81%。

原理简述：利用哈希值中前导零的最大长度来估算基数。直觉上，如果你扔硬币，看到连续 5 次正面的概率是 1/32——所以如果你观察到连续 5 次正面，可以推测你大概扔了 32 次。

应用场景：

• 统计网站日 UV（独立访客数）
• 统计搜索词的去重数量
• 统计直播间的累计观看人数

PFADD uv:20240315 "user_1001" "user_1002" "user_1003" PFADD uv:20240315 "user_1001" -- 重复添加不影响 PFCOUNT uv:20240315 -- 返回约 3（可能有 0.81% 误差） -- 合并多天的 UV PFMERGE uv:week uv:20240315 uv:20240316 uv:20240317 PFCOUNT uv:week -- 一周的去重 UV

HyperLogLog vs Set 对比：

2.2 Bitmap：位运算

Bitmap 本质上是 String 类型，但提供了位级别的操作命令。每个 bit 只占 1 位内存，适合表示二值状态（是/否）。

应用场景：

1. 签到系统：

-- 用户1001在2024年3月第15天签到 SETBIT sign:1001:202403 14 1 -- offset从0开始，第15天=offset 14 -- 统计3月签到天数 BITCOUNT sign:1001:202403 -- 返回 1 的个数 -- 检查某天是否签到 GETBIT sign:1001:202403 14 -- 返回 1 或 0

内存：一个月只需 4 字节（31 bit），一年只需 46 字节。

2. 在线状态：

SETBIT online:users 1001 1 -- 用户1001上线 SETBIT online:users 1001 0 -- 用户1001下线 GETBIT online:users 1001 -- 检查是否在线 BITCOUNT online:users -- 总在线人数

3. 布隆过滤器的基础：Bitmap 是布隆过滤器的底层数据结构（Redis 的 RedisBloom 模块提供了完整实现）。

2.3 Stream：可靠消息队列

Redis Stream 是 5.0 版本引入的数据结构，专门为消息队列场景设计。它解决了 List 做消息队列的核心问题：没有 ACK 机制和消费者组。

Stream vs List 作为消息队列：

基本使用：

-- 生产者 XADD mystream * action "login" user_id "1001" -- * 表示自动生成 ID（如 1713600000000-0） -- 消费者组 XGROUP CREATE mystream mygroup $ MKSTREAM -- 消费者读取 XREADGROUP GROUP mygroup consumer1 COUNT 10 BLOCK 2000 STREAMS mystream > -- 确认消费 XACK mystream mygroup 1713600000000-0

2.4 GEO：地理位置

Redis GEO 底层基于 Sorted Set 实现（将经纬度通过 Geohash 编码为 score），提供地理位置存储和查询能力。

应用场景：

• 附近的人/附近的店铺
• 配送范围计算
• 打车距离估算

-- 添加位置 GEOADD shops 116.397128 39.916527 "shop_A" GEOADD shops 116.405285 39.904989 "shop_B" GEOADD shops 116.410050 39.920000 "shop_C" -- 计算两点距离 GEODIST shops shop_A shop_B km -- 返回距离（公里） -- 搜索附近 5km 的店铺 GEOSEARCH shops FROMMEMBER shop_A BYRADIUS 5 km ASC COUNT 10 -- Redis 6.2+ 使用 GEOSEARCH 替代 GEORADIUS

三、持久化机制

Redis 是内存数据库，持久化机制决定了数据的安全性和恢复能力。

3.1 RDB 快照

RDB（Redis Database）通过在某个时间点对内存数据做完整快照，生成一个二进制的.rdb文件。

工作原理：

1. Redis 调用fork()创建子进程
2. 子进程将内存数据写入临时 RDB 文件
3. 写入完成后替换旧的 RDB 文件
4. 父进程继续处理请求（利用 COW —— Copy-On-Write 机制，修改的页才会复制）

触发方式：

# redis.conf save 900 1 # 900秒内至少1次写操作 save 300 10 # 300秒内至少10次写操作 save 60 10000 # 60秒内至少10000次写操作 # 手动触发 BGSAVE # 后台异步保存（推荐） SAVE # 阻塞式保存（生产环境不用）

优缺点：

3.2 AOF 日志

AOF（Append Only File）记录所有写命令，以 Redis 协议格式追加到文件末尾。恢复时重放所有命令即可恢复数据。

写入策略（appendfsync）：

AOF 重写（Rewrite）：

AOF 文件会不断增长（记录了所有历史命令），重写机制将当前数据状态压缩为最小命令集：

原始 AOF： SET counter 0 INCR counter -- counter = 1 INCR counter -- counter = 2 INCR counter -- counter = 3 DEL counter SET counter 100 INCR counter -- counter = 101 重写后 AOF： SET counter 101 （7条命令压缩为1条）

重写过程也是 fork 子进程完成的，父进程继续处理请求。新请求同时写入旧 AOF 和重写缓冲区，确保重写期间的数据不丢失。

3.3 RDB + AOF 混合持久化

Redis 4.0+ 支持混合持久化：AOF 重写时，生成的文件前半部分是 RDB 格式（快速加载），后半部分是 AOF 格式（增量命令）。

开启混合持久化： aof-use-rdb-preamble yes 文件结构： ┌─────────────────────────────────┐ │ RDB 格式数据（重写时间点快照） │ ← 加载快 ├─────────────────────────────────┤ │ AOF 格式命令（重写后的增量） │ ← 数据完整 └─────────────────────────────────┘

优势：兼顾了 RDB 的快速加载和 AOF 的数据完整性，是生产环境的推荐配置。

3.4 持久化策略选择

四、缓存策略设计

4.1 缓存模式

Cache-Aside（旁路缓存，最常用）：

应用程序同时与缓存和数据库交互，由应用层控制缓存的读写逻辑。

读流程： 1. 先查缓存 → 命中则直接返回 2. 缓存未命中 → 查数据库 3. 将数据库结果写入缓存（设置 TTL） 4. 返回数据 写流程： 1. 先更新数据库 2. 再删除缓存（而非更新缓存）

为什么写时"删除缓存"而非"更新缓存"：

• 更新缓存可能导致并发问题（两个线程同时更新，缓存值可能是旧的）
• 删除缓存让下次读取时自然回源，保证最终一致性
• 如果缓存值需要复杂计算，删除比重新计算更简单

Read/Write Through（读写穿透）：

应用层只与缓存交互，由缓存层负责与数据库的同步。

读流程：应用 → 缓存（未命中时缓存自动加载数据库）→ 返回 写流程：应用 → 缓存 → 缓存同步写入数据库 → 返回 特点：对应用透明，但缓存层需要支持数据库交互能力

Write Behind（异步写入）：

写操作只更新缓存，由缓存异步批量写入数据库。

写流程：应用 → 缓存 → 返回（立即返回） 后台：缓存定期/批量将脏数据刷入数据库 优点：写入性能极高（不等数据库） 缺点：缓存宕机可能丢数据；一致性最弱 适用：写密集但允许少量丢失的场景（如计数器、浏览量）

4.2 缓存穿透、击穿、雪崩

这三个问题是面试的必考题，核心在于"缓存层失去保护作用，大量请求打到数据库"。

缓存穿透：请求的数据在缓存和数据库中都不存在，每次都穿透到数据库。

布隆过滤器原理：用多个哈希函数将所有合法 key 映射到 Bitmap 中。查询时，如果 Bitmap 对应位置不全为 1，则该 key 一定不存在（可能有假阳性，但没有假阴性）。

缓存击穿：某个热点 key过期的瞬间，大量并发请求同时查询该 key，缓存未命中后全部打到数据库。

缓存雪崩：大量 key同时过期或 Redis 宕机，导致大量请求同时打到数据库。

4.3 缓存与数据库一致性

在分布式环境下，缓存和数据库的一致性是一个经典难题。没有银弹，只有不同程度的权衡。

常见的不一致场景（Cache-Aside 模式）：

线程A更新数据库 → 线程A删除缓存 ↗ 在这个微小时间窗口内 线程B读取数据 → 缓存未命中 → 读数据库（可能读到旧值）→ 写入缓存

保障一致性的策略（由弱到强）：

1. 设置合理的 TTL：即使出现不一致，TTL 到期后自动恢复。适合大多数场景。

2. 延迟双删：更新数据库后，先删缓存，等待短暂时间（如 500ms），再删一次缓存。

   • 覆盖了"先读后写"并发场景中的不一致窗口
   • 缺点：引入了延迟，实现复杂

3. 基于 Binlog 的异步更新：通过订阅 MySQL Binlog（如 Canal），异步删除或更新缓存。

   • 最终一致性保证
   • 解耦了业务代码和缓存操作
   • 是大厂最常用的方案

4. 强一致性方案：使用分布式事务（如 2PC）或读写锁。

   • 性能代价大，通常不推荐

面试建议回答：“在大多数业务场景下，Cache-Aside + TTL + 延迟双删/Binlog 订阅 就能满足需求。缓存和数据库的强一致性在分布式环境下代价太大，通常只需要保证最终一致性。核心思路是：以数据库为准，缓存是数据库的’加速副本’，允许短暂不一致但保证最终收敛。”

五、Python + Redis 实战

5.1 redis-py 连接池配置

importredis# 生产环境推荐配置pool=redis.ConnectionPool(host="localhost",port=6379,db=0,password="your_password",max_connections=50,# 最大连接数socket_timeout=5,# 读写超时（秒）socket_connect_timeout=2,# 连接超时retry_on_timeout=True,# 超时后重试decode_responses=True,# 自动解码为字符串（而非bytes）health_check_interval=30,# 每30秒检查连接健康)r=redis.Redis(connection_pool=pool)# 基本操作r.set("key","value",ex=3600)# 设置，1小时过期r.get("key")# 获取r.delete("key")# 删除r.incr("counter")# 原子递增

5.2 异步 Redis 客户端

importredis.asyncioasaioredisasyncdefget_async_client():"""异步Redis客户端（适配FastAPI）"""pool=aioredis.ConnectionPool.from_url("redis://localhost:6379/0",max_connections=50,decode_responses=True,)returnaioredis.Redis(connection_pool=pool)asyncdefcache_user(user_id:int,user_data:dict):client=awaitget_async_client()awaitclient.hset(f"user:{user_id}",mapping=user_data)awaitclient.expire(f"user:{user_id}",3600)asyncdefget_cached_user(user_id:int)->dict:client=awaitget_async_client()data=awaitclient.hgetall(f"user:{user_id}")returndataifdataelseNone

5.3 Pipeline 批量操作

Pipeline 将多条命令打包发送，减少网络 RTT（Round-Trip Time）。如果不使用 Pipeline，N 条命令需要 N 次网络往返；使用后只需 1 次。

defbatch_set_users(users:list):"""Pipeline批量操作：性能提升 5-10x"""pipe=r.pipeline(transaction=False)# 非事务Pipelineforuserinusers:pipe.hset(f"user:{user['id']}",mapping=user)pipe.expire(f"user:{user['id']}",3600)results=pipe.execute()# 一次性发送所有命令returnresults# 事务Pipeline（MULTI/EXEC，保证原子性）deftransfer(from_id:int,to_id:int,amount:float):"""原子性转账"""pipe=r.pipeline(transaction=True)# 事务模式pipe.hincrbyfloat(f"user:{from_id}","balance",-amount)pipe.hincrbyfloat(f"user:{to_id}","balance",amount)pipe.execute()# MULTI + 两条命令 + EXEC

Pipeline 性能对比：

5.4 Lua 脚本

当需要保证多条 Redis 命令的原子性（但又不想用事务），可以使用 Lua 脚本。Redis 执行 Lua 脚本时是单线程原子的——不会被其他命令插入。

# 经典场景：限流器（滑动窗口，原子操作）RATE_LIMIT_SCRIPT=""" local key = KEYS[1] local limit = tonumber(ARGV[1]) local window = tonumber(ARGV[2]) local now = tonumber(ARGV[3]) -- 移除窗口外的记录 redis.call('ZREMRANGEBYSCORE', key, 0, now - window) -- 当前窗口内的请求数 local current = redis.call('ZCARD', key) if current < limit then -- 未超限，记录本次请求 redis.call('ZADD', key, now, now .. math.random()) redis.call('EXPIRE', key, window) return 1 -- 允许 else return 0 -- 拒绝 end """defis_rate_limited(user_id:str,limit:int=100,window:int=60)->bool:"""滑动窗口限流：每 window 秒最多 limit 次请求"""importtime key=f"rate:{user_id}"now=int(time.time()*1000)# 毫秒级时间戳result=r.eval(RATE_LIMIT_SCRIPT,1,key,limit,window*1000,now)returnresult==0# 0=被限流, 1=允许

Lua 脚本 vs Pipeline+MULTI 事务：

六、面试高频题汇总

Q1：Redis 的五种数据结构及其应用场景？

A：

选型要点：

• 需要排序/排名 → Sorted Set
• 需要集合运算（交/并/差）→ Set
• 需要两端进出的队列 → List
• 需要存储对象的多个字段 → Hash
• 简单的键值对/计数器 → String

Q2：缓存穿透、击穿、雪崩分别是什么？如何解决？

A：三者的共同本质是"缓存层失去保护，请求大量到达数据库"。

缓存穿透：查询根本不存在的数据（缓存和 DB 都没有），恶意攻击常用手段。

• 解决：布隆过滤器（前置拦截）+ 缓存空值（短 TTL）

缓存击穿：热点 key 过期瞬间，大量并发请求同时打到 DB。

• 解决：互斥锁（只允许一个线程回源）+ 逻辑过期（不设真实 TTL）

缓存雪崩：大量 key 同时过期或 Redis 宕机，请求洪峰打到 DB。

• 解决：TTL 加随机偏移 + 多级缓存 + Redis 高可用 + 限流降级

面试加分：这三个问题可以形成一套完整的缓存防护体系：

• 接口层：参数校验 + 布隆过滤器（防穿透）
• 缓存层：随机 TTL + 热点 key 永不过期（防雪崩/击穿）
• 回源层：互斥锁 + 限流（防击穿/雪崩压垮 DB）

Q3：Redis 的持久化机制有哪些？各自的优缺点？

A：Redis 有两种基本持久化机制，以及混合模式：

RDB（快照）：

• 原理：fork 子进程，将完整内存数据写入二进制 .rdb 文件
• 优点：文件紧凑恢复快，适合备份和灾恢
• 缺点：可能丢失最后一次快照后的数据；fork 时大内存实例有延迟

AOF（追加日志）：

• 原理：记录所有写命令，恢复时重放
• 优点：数据安全性高（everysec 最多丢 1 秒）
• 缺点：文件体积大，恢复慢（需要重放所有命令）

混合持久化（Redis 4.0+，推荐）：

• 原理：AOF 重写时前半部分用 RDB 格式，后半部分用 AOF 格式
• 优点：兼顾快速恢复和数据完整性
• 缺点：文件格式兼容性（不能被老版本读取）

生产建议：开启混合持久化（aof-use-rdb-preamble yes），同时定期做 RDB 备份到远端存储。

Q4：如何保证缓存与数据库的一致性？

A：核心原则——以数据库为准，缓存是数据库的加速副本。

Cache-Aside 模式（最常用）：

• 读：先读缓存，Miss 则读 DB 并回填缓存
• 写：先更新 DB，再删除缓存（不是更新缓存）

为什么"先更新 DB，再删缓存"：

• “先删缓存再更新 DB”：在删缓存和更新 DB 之间，另一个请求可能读到旧值并回填缓存，导致持久不一致
• “先更新 DB 再删缓存”：不一致窗口极短（只有 DB 更新成功到缓存删除成功之间）

增强一致性的手段：

1. 设置合理 TTL（兜底，即使不一致也能自动恢复）
2. 延迟双删（应对极端并发场景）
3. 基于 Binlog 的异步删除（Canal 订阅 MySQL Binlog → 删除对应缓存 key）
4. 消息队列保证删除操作的可靠性（删除失败时重试）

面试结论：在分布式环境下追求强一致性代价过大，通常只需保证最终一致性。核心思路是"以 DB 为准 + 合理 TTL 兜底 + 异步补偿"。

本章总结

本文系统性地讲解了 Redis 的核心数据结构、持久化机制和缓存策略：

1. 五大基础结构：String 万能基础（计数器、锁、Session）、Hash 存对象（字段级读写）、List 做队列（FIFO/最新列表）、Set 做集合运算（标签、去重、共同好友）、Sorted Set 做排行/延迟队列（跳表实现，O(logN) 排名）。

2. 高级结构：HyperLogLog 用 12KB 统计亿级 UV；Bitmap 用位操作实现签到/在线状态；Stream 是 Redis 原生的可靠消息队列（消费者组 + ACK）；GEO 基于 Geohash 实现附近搜索。

3. 持久化：RDB 快照恢复快但可能丢数据；AOF 日志安全但恢复慢；混合持久化（4.0+）是生产环境最佳选择。关键参数：appendfsync everysec+aof-use-rdb-preamble yes。

4. 缓存策略：Cache-Aside 是最主流模式（先 DB 后删缓存）。穿透用布隆过滤器防，击穿用互斥锁防，雪崩用随机 TTL + 高可用防。一致性通过 TTL 兜底 + Binlog 异步补偿保证最终一致。

5. Python 实战：redis-py 连接池 + Pipeline 批量（减少 RTT）+ Lua 脚本（原子条件逻辑）。异步场景用redis.asyncio配合 FastAPI。

核心理念：Redis 不是"万能胶水"，每种数据结构都有其最适合的场景。用 String 存计数、用 Hash 存对象、用 Sorted Set 做排行榜、用 Stream 做消息队列——选对数据结构，问题就解决了一半。

下一篇预告

第 19 篇：Redis 高可用架构与分布式实践

下一篇文章将深入 Redis 的高可用和分布式场景。你将了解：

• Redis Sentinel 哨兵模式：故障检测、自动故障转移、客户端连接配置
• Redis Cluster 集群模式：哈希槽分片原理（16384 槽）、Gossip 协议、集群扩缩容
• 分布式锁：SET NX EX 基础锁、Redlock 算法、锁续期（看门狗机制）
• 消息队列方案：List/Pub-Sub/Stream 对比、与 RabbitMQ/Kafka 的选型
• 性能优化：大 Key 排查、热 Key 处理、内存优化、慢查询分析

从单机到集群，从简单锁到分布式锁，下一篇将展示 Redis 在分布式环境下的完整能力和最佳实践。

Python 后端开发技术博客专栏| 作者：耿雨飞
本文为专栏第 18 篇，共 25 篇。完整目录请参阅《Python技术博客专栏大纲》。