数据库 on 方糖猫Blog

MongoDB 从入门到精通：存储引擎、建模、索引、副本集、分片与事务实战

Tue, 26 Oct 2021 10:30:00 +0800

MongoDB 从入门到精通：存储引擎、建模、索引、副本集、分片与事务实战

目标读者：用过 MySQL 之类的关系型数据库，现在要接 MongoDB 的同学——可能是接手存量系统，可能是新业务选型，也可能是想给自己的技术栈补上 NoSQL 这一块。
本文不浪费篇幅在「什么是文档」这种名词解释上，直接从真正影响系统生死的东西讲起：存储引擎、一致性、高可用、性能。
写这篇的契机：2021 年我所在团队的电商中台把部分业务从 MySQL 迁到 MongoDB，整个过程脱了一层皮。这篇是我希望迁移前有人能拍在桌上的笔记。
文内版本基线：MongoDB 5.0（2021 年 7 月发布）、官方 Java 同步驱动 4.3、JDK 11。

全文八篇，按真实的成长路径编排：

flowchart LR
    A["一 选型认知<br/>Mongo 适合什么"] --> B["二 存储引擎<br/>WiredTiger 底牌"]
    B --> C["三 数据建模<br/>核心战场"]
    C --> D["四 索引与 explain<br/>调优基本功"]
    D --> E["五 聚合管道<br/>服务端计算"]
    E --> F["六 副本集<br/>高可用与读写语义"]
    F --> G["七 事务与分片<br/>规模化与一致性"]
    G --> H["八 运维与 AI 时代<br/>监控备份 少写代码"]
    style H fill:#e8f4e8

学习 MongoDB 要始终围绕三个问题：数据安不安全、查询快不快、流量扛不扛得住。这篇的每一节，都是对这三问的某一次正面回答。

第一篇选型认知：什么时候该用 MongoDB，什么时候别逞强

第一课不是怎么用，是什么时候用。用错场景的 MongoDB，比不用更可怕。

flowchart TD
    subgraph 适合["MongoDB 的主场"]
        P["商品中心<br/>类目属性千差万别<br/>文档模型天然契合"]
        C["购物车/会话<br/>读多写多 结构灵活"]
        L["行为日志/埋点<br/>写入量大 schema 常变<br/>TTL 索引自动过期"]
        CM["CMS/配置中心<br/>页面配置 JSON 化"]
    end
    subgraph 谨慎["需要精心设计的边界"]
        O["订单/库存<br/>可用 但要事务+对账设计"]
        M["消息/Feed 流<br/>可用 注意分片键设计"]
    end
    subgraph 别上["别硬上 Mongo"]
        F["账务/清结算<br/>强事务 强审计<br/>交给关系型"]
        S["复杂搜索<br/>交给 Elasticsearch"]
        J["重度多表关联分析<br/>交给 OLAP/数仓"]
    end
    style 适合 fill:#e8f4e8
    style 别上 fill:#fde8e8

一句话原则：MongoDB 适合「单实体自成一体、结构多变、读多」的在线业务；不适合「钱」「搜索」「重度关联分析」。 判断依据不是性能 benchmark，而是数据访问模式——先把系统里 80% 的查询列出来，看它们能不能被「单集合 + 少量 $lookup」覆盖。覆盖不了，选型本身就有问题。

思考与感悟之一：数据库选型和框架选型完全不同。框架选错了可以重构，数据库选错了是「数据搬家」级别的灾难——停机迁移、双写对账、灰度切流，每一步都在钢丝上走。所以对「不做什么」的清单，要比「做什么」的清单更长。

第二篇 WiredTiger：理解存储引擎，才配谈性能

很多人用 MongoDB 三年，不知道底下是 WiredTiger。这就像开了一辈子车不懂发动机——平时没事，出事时只能干瞪眼。这一篇先把「数据到底怎么存的」讲透，再回答那个面试必问的问题：MongoDB 为什么快，为什么扛得住大量读写。

2.1 底层数据模型：BSON，磁盘上到底存了什么

你在应用层操作的是「文档」（可以理解成 JSON），但磁盘上存的是 BSON（Binary JSON）——一种二进制、自描述、长度前缀的编码格式：

flowchart LR
    subgraph BSON["一个 BSON 文档的字节布局"]
        L["int32 总长度<br/>开头 4 字节"] --> E1["元素1<br/>类型字节 + 字段名 + 值"]
        E1 --> E2["元素2<br/>类型字节 + 字段名 + 值"]
        E2 --> EN["..."]
        EN --> Z["0x00 结束符"]
    end
    subgraph TYPES["BSON 比 JSON 多出的类型"]
        T1["ObjectId / Date / 正则"]
        T2["int32 / int64 / double"]
        T3["Decimal128 高精度十进制"]
        T4["BinData 二进制 / 数组 / 内嵌文档"]
    end
    BSON -.-> TYPES

BSON 的设计直接回答了两个性能问题：

长度前缀 + 类型字节 → 遍历时可以「跳过」字段。 查询只取 name 字段时，引擎不需要解析整个文档，读到字段长度直接指针后移——这就是为什么投影（projection）能省时间。
类型丰富 → 不需要序列化转换。 JSON 只有 string/number/boolean，日期只能存字符串再解析；BSON 原生支持 Date、ObjectId、Decimal128（钱的精确计算就靠它）、二进制，省去了应用层和存储层之间大量的类型转换开销。

更关键的是文档在磁盘上是连续存放的：一个商品文档（含内嵌的 SKU 数组、图片列表）在磁盘上是一整块连续的字节。这和关系型数据库形成鲜明对比——

flowchart TD
    subgraph MYSQL["MySQL 读一个完整商品"]
        A1["product 表的 B+ 树页"] --> J["JOIN"]
        A2["sku 表的 B+ 树页<br/>磁盘另一处"] --> J
        A3["image 表的 B+ 树页<br/>磁盘又一处"] --> J
        J --> R["多次随机 I/O<br/>才能拼出一个商品"]
    end
    subgraph MONGO["MongoDB 读一个完整商品"]
        B["一次磁盘寻道<br/>读出连续的一整块 BSON"]
    end
    style MONGO fill:#e8f4e8

这就是 MongoDB 设计哲学里最重要的词：数据局部性（data locality）。「一起读的数据，就存在一起」。嵌入建模之所以是 Mongo 的灵魂，底层原因就在这里——它不是风格偏好，是磁盘 I/O 决定的。

追问：文档是定长连续存放的，那修改、变大之后怎么办？磁盘会不连续吗？ 这要分两个时代说。MMAPv1 时代（3.0 之前）文档存在定长槽位里，变大就得整体搬家（document move），旧槽位变空洞，磁盘碎片是当年最臭名昭著的问题。WiredTiger 时代换了个思路：存储单位是 B 树的页而不是文档，文档是叶页里的一条 record；修改从不在原地写——checkpoint 时用 copy-on-write 把改后的整页写到磁盘新位置，旧块进空闲列表复用；文档长大导致页放不下就触发页分裂，超大文档走 overflow 页。所以「连续」的准确含义是「逻辑上一条 record、一次 I/O 读取」，物理位置本来就会搬。代价有两个：长期高频更新会积累碎片（用 db.collection.compact() 定期回收），以及频繁长大的文档会引发频繁页分裂——这是第三篇「增长边界」判断的底层原因，时序类数据的标准解法是按时间桶预分配文档的 bucket 模式，让单文档尺寸保持稳定。

2.2 为什么快：读快与写快的底层原因

「MongoDB 快」不能当口号喊，要能拆成具体机制。先写后读。

写入为什么快——一条写请求的完整路径：

flowchart LR
    APP["应用<br/>Java 驱动"] --> M["mongod<br/>内存操作"]
    M --> C["WiredTiger cache<br/>修改页标记为 dirty<br/>写操作到此即完成"]
    M --> J["journal 日志<br/>顺序追加写<br/>磁盘顺序 I/O 极快"]
    C -.->|"checkpoint<br/>默认每 60 秒<br/>批量刷盘"| D["数据文件<br/>压缩后的 B 树页"]
    style C fill:#e8f4e8

四个叠加的机制：

写内存即返回。写操作修改的是 cache 里的页，标记 dirty 就完事，数据文件由 checkpoint 线程每 60 秒批量刷一次——随机写被攒成了顺序批量写。这是「写快」的第一来源。
journal 用顺序写保证持久性。怕宕机丢内存里的数据？journal（WAL 日志）是顺序追加写，磁盘的顺序写比随机写快几个数量级。j: true 的写确认就是等 journal 落盘，而不是等数据文件落盘。

这里必须正面回答一个所有人都会问的问题：「写入内存就返回，服务器挂了怎么办？」 不会变成脏数据——cache 里丢掉的只是 dirty 页的内存副本，每次修改都已先追加进 journal；mongod 重启时以最后一次 checkpoint 为基线重放 journal，把丢失的写补回数据文件。真正的风险窗口在确认时机：默认 w:1 下 journal 每 ~100ms 才批量提交，断电最多丢「最近约 100ms 且未同步到从节点」的写（第六篇丢的 23 笔订单就是这么没的）；j: true 等日志落盘，单节点宕机不丢；w: majority 等多数派确认，机器物理损毁也不丢。丢不丢数据不是 MongoDB 决定的，是你选 writeConcern 档位时决定的——这套「内存脏页异步刷盘 + 日志重放」和 MySQL InnoDB 的 redo log 是同一套思想。
文档级并发。更新只锁单个文档，100 个线程写 100 个不同文档完全不互斥。对比早期 MySQL MyISAM 的表锁、乃至行锁时代的间隙锁开销，文档锁的冲突概率天然更低。
没有跨行约束的包袱。无外键检查、无触发器、单文档原子性不需要 undo log（改一个文档就是改一整块，要么全改要么不改），写入路径短。

读取为什么快——四道防线：

局部性：如上，嵌入建模让「读一个完整实体」= 一次磁盘寻道，没有 JOIN 的多次随机 I/O。
缓存：热数据常驻 WiredTiger cache（默认一半内存），命中内存的读在微秒级。
B 树索引：索引项 O(log n) 定位，千万级数据也就 4 层左右，加覆盖索引（第四篇）连文档都不用读。
副本集读扩展：readPreference: secondary 把展示类读流量分摊到从节点，读吞吐随节点数线性扩展。

大量读 + 大量写同时扛住的原因：读写分离（从节点扛读）+ MVCC（读不阻塞写、写不阻塞读）+ 写内存化。这三件事同时成立，才撑得起电商大促「几十万读 QPS 的商品页 + 几万写 QPS 的库存扣减」同框的场景。还不够？分片把写入水平切到多个副本集，写吞吐同样线性扩展（第七篇）。

快的代价（必须说清楚，否则就是忽悠）：写内存即返回意味着默认 w:1 下宕机可能丢最后一小段数据（第六篇的丢单事故就是这么来的）；热数据依赖内存，内存小于工作集时性能断崖；没有 JOIN 意味着关联查询要自己扛。MongoDB 的快是「用设计取舍换来的快」，不是魔法。

2.3 WiredTiger 你必须知道的四件事

flowchart TD
    W["WiredTiger 存储引擎<br/>MongoDB 3.2+ 默认"] --> A["文档级并发控制<br/>多线程写同一集合不互斥<br/>只有同一文档冲突才重试"]
    W --> B["压缩存储<br/>snappy 默认<br/>磁盘占用约为数据量的 30%-70%"]
    W --> C["缓存机制<br/>cacheSizeGB 默认 = 50% × (内存 - 1GB)<br/>热数据全在内存里"]
    W --> D["MVCC 多版本<br/>读不阻塞写 写不阻塞读<br/>snapshot 隔离"]

要记的结论：

文档级锁：并发写同一个集合是免费的，但并发改同一个文档会串行重试。这直接决定建模——秒杀库存如果把 100 个 SKU 的库存都嵌在一个商品文档里，大促时这个文档就是全站最热的锁热点。
缓存即命：WiredTiger cache 默认吃掉一半内存。生产上「Mongo 内存打满」往往不是泄漏，是 cache 在正常工作——看 wiredTiger.cache 指标而不是看进程 RSS 下结论。
压缩是把双刃剑：省磁盘，费 CPU。写密集型日志库可换 zlib 更高压缩比，CPU 紧张时别乱调。
MVCC 的代价：老版本数据要清理，长时间不提交的事务会压住清理线程，导致 cache 中 dirty data 堆积、写入被拖慢。

踩坑故事 #1（cache 被大事务压垮）：我们有个定时任务一次性更新 200 万条商品，跑的时候整个库延迟飙升。原因：巨型事务导致 WiredTiger 无法清理旧版本，cache 中 dirty bytes 超过阈值后应用线程被迫参与淘汰（eviction），写入集体变慢。解法：批量操作必须拆批（每批 1000 条 + 短暂让出窗口），生产环境永远不开「不设限的大批量更新」。这条后来成了团队《MongoDB 使用红线》第一条。

2.4 本地环境：直接上副本集，别玩单机

单节点 MongoDB 不支持事务，也不具备生产形态。本地练手就用 Docker Compose 起一套三节点副本集：

# docker-compose.yml
version: '3.8'
services:
  mongo1:
    image: mongo:5.0
    command: ["--replSet", "rs0", "--bind_ip_all"]
    ports: ["27017:27017"]
  mongo2:
    image: mongo:5.0
    command: ["--replSet", "rs0", "--bind_ip_all"]
  mongo3:
    image: mongo:5.0
    command: ["--replSet", "rs0", "--bind_ip_all"]

# 初始化副本集（执行一次）
mongosh --eval 'rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo1:27017" },
    { _id: 1, host: "mongo2:27017" },
    { _id: 2, host: "mongo3:27017" }
  ]
})'

第三篇数据建模：核心战场，没有之一

MongoDB 精通与否，就看建模。SQL 建模有范式护体，Mongo 建模全靠经验与取舍——这也是 AI 最帮不上忙的部分（第八篇详谈）。

3.1 唯一重要的问题：嵌入还是引用

flowchart TD
    Q["一份数据，嵌入父文档<br/>还是独立成集合？"] --> A{"三个判断"}
    A --> B["读写边界<br/>总是一起读写吗？"]
    A --> C["增长边界<br/>数量有上限吗？"]
    A --> D["并发边界<br/>会被高并发独立更新吗？"]
    B -->|"是，且"| E["嵌入<br/>如：订单内嵌 items 快照"]
    C -->|"否，无限增长"| R["引用<br/>如：商品引用评论"]
    D -->|"是，热点"| R2["引用<br/>如：SKU 库存独立成文档<br/>避免单文档成锁热点"]

三个判断，每个都对应一个坑：

读写边界：订单的 items 嵌入（下单时一次写入、之后整体读取）；但「收货地址」独立成集合——地址在下单、物流、售后多个流程被独立读写，嵌在用户文档里每次都要加载整个用户。
增长边界：单文档 16MB 硬上限。商品的「问大家」嵌进商品文档，爆款商品一年撑爆，连夜迁移。教训：文档不是仓库，是货架。
并发边界：文档级锁决定了——凡是会被高并发写的数据，从父文档里拆出去。秒杀库存必须一个 SKU 一个文档，绝不能嵌在商品里。

3.2 电商核心建模：订单快照与库存拆分

erDiagram
    USER ||--o{ ORDER : "引用"
    PRODUCT ||--o{ SKU_STOCK : "拆出 独立高并发写"
    ORDER ||--|{ ORDER_ITEM : "内嵌 商品快照"
    PRODUCT ||--o{ COMMENT : "引用 无界增长"
    PRODUCT {
        ObjectId _id
        string name
        string categoryId
        array attrs "类目属性 灵活嵌入"
        string detailUrl "富文本放对象存储"
    }
    SKU_STOCK {
        ObjectId _id
        ObjectId productId
        string spec
        int stock "独立文档 原子扣减"
        int version "乐观锁"
    }
    ORDER {
        ObjectId _id
        ObjectId userId
        array items "名称/单价/图片快照"
        long totalAmount "单位: 分"
        string status
        date createdAt
    }

两个关键设计，每个都值一次线上事故的钱：

订单必须存商品快照。下单那一刻把商品名、成交单价、主图冗余进 items。商品会改名改价下架，三个月后客服处理售后，看的必须是「成交时」的样子。快照冗余不是脏数据，是业务真相。
金额用「分」，long 存。浮点的 199.00 元在 IEEE 754 世界里是 198.999...，所有和钱有关的字段一律整数存分。这不是 Mongo 的问题，但 Mongo 的自由度会让人更容易犯懒。

思考与感悟之二：SQL 建模回答「数据之间是什么关系」，Mongo 建模回答「数据以什么节奏被读写」。前者是静态的学问，后者是动态的学问——必须预测流量形状（谁是热点、谁会暴涨、谁一起出现）才能建好模。这就是为什么 Mongo 建模更依赖业务理解，也更难被自动化。

第四篇索引与 explain：调优基本功，没有捷径

4.1 explain 是唯一标准答案

任何「这条查询为什么慢」的讨论，不贴 explain 输出就是耍流氓。Java 里看执行计划：

// 在 Java 驱动里用 explain 需要走 Document 命令（或先在 mongosh 里验证）
// mongosh 中的写法：
db.products.find({ categoryId: cid, status: "on" })
  .sort({ price: -1 })
  .explain("executionStats");

输出只盯四处：

flowchart TD
    A["winningPlan.stage"] --> B{"COLLSCAN?"}
    B -->|"是"| C["全表扫描<br/>立刻建索引"]
    B -->|"IXSCAN"| D["看三个数字"]
    D --> E["nReturned<br/>返回多少条"]
    D --> F["totalDocsExamined<br/>读了多少文档"]
    D --> G["totalKeysExamined<br/>扫了多少索引键"]
    E --> H{"理想: 三者接近<br/>危险: Examined 远大于 Returned"}

4.2 ESR 法则与 Java 建索引

复合索引字段顺序：Equality（等值）→ Sort（排序）→ Range（范围）。

商品列表页查询：{ categoryId: 等值, status: 等值 } + 按价格倒序，用 Java 驱动建索引：

// 依赖: org.mongodb:mongodb-driver-sync:4.3.x
import com.mongodb.client.MongoClient;
import com.mongodb.client.MongoClients;
import com.mongodb.client.MongoCollection;
import com.mongodb.client.model.Indexes;
import org.bson.Document;

public class IndexDemo {
    public static void main(String[] args) {
        try (MongoClient client = MongoClients.create("mongodb://localhost:27017/?replicaSet=rs0")) {
            MongoCollection<Document> products = client.getDatabase("shop").getCollection("products");

            // ESR：categoryId/status 等值(E) 在前，price 排序(S) 在后
            products.createIndex(Indexes.compoundIndex(
                    Indexes.ascending("categoryId"),
                    Indexes.ascending("status"),
                    Indexes.descending("price")
            ));

            // 部分索引：只给在售商品建，索引体积砍半
            products.createIndex(
                    Indexes.ascending("price"),
                    new com.mongodb.client.model.IndexOptions()
                            .partialFilterExpression(com.mongodb.client.model.Filters.eq("status", "on"))
            );

            // TTL 索引：埋点日志 7 天自动删除，省掉清理脚本
            client.getDatabase("shop").getCollection("access_logs")
                    .createIndex(Indexes.ascending("createdAt"),
                            new com.mongodb.client.model.IndexOptions().expireAfter(7L, java.util.concurrent.TimeUnit.DAYS));
        }
    }
}

注意：加了「价格区间筛选」后 price 就从 Sort 变成 Range，一个索引满足不了两个需求——索引设计永远是针对具体查询集合的权衡，没有万能索引。每个索引都拖慢写入，写多读少的日志库尤其敏感。

踩坑故事 #2（32MB 排序内存墙）：运营后台「全量商品按上架时间倒序」接口，商品过 10 万后直接报 Sort exceeded memory limit of 33554432 bytes。Mongo 内存排序上限 32MB，超了就炸。解法不是调参数，是建索引让排序走索引（索引天然有序）。上线红线第二条：凡带 sort 的查询，必须 explain 验证走索引排序。

踩坑故事 #3（正则索引进退两难）：模糊搜索 find({ name: /卫衣/ })，非前缀正则无法走索引，数据量上来后 P99 三秒起步。前缀匹配 /^卫衣/ 可以走索引，但中文搜索很少是前缀形态。2021 年的正经答案：Mongo 管数据，ES 管搜索，用 oplog/canal 同步，别指望一个库包打天下。

第五篇聚合管道：把计算下推给服务端

核心思维：「能在库里算完的，绝不拉回应用层」。拉 10 万条数据到 JVM 里 for 循环求和，是最常见的性能自杀。

flowchart LR
    A["$match<br/>筛: 本月已支付"] --> B["$unwind<br/>拆: items 展开"]
    B --> C["$group<br/>按商品汇总"]
    C --> D["$sort<br/>销量倒序"]
    D --> E["$limit<br/>Top 10"]
    E --> F["热销榜<br/>一次出结果"]

实战 Demo：本月热销商品 Top 10（Java 驱动写法）：

// demo01-top-sales：本月热销榜
import com.mongodb.client.MongoClient;
import com.mongodb.client.MongoClients;
import com.mongodb.client.MongoCollection;
import com.mongodb.client.model.Accumulators;
import com.mongodb.client.model.Aggregates;
import com.mongodb.client.model.Filters;
import com.mongodb.client.model.Sorts;
import org.bson.Document;
import org.bson.conversions.Bson;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Date;
import java.util.List;

public class TopSalesDemo {
    public static void main(String[] args) {
        try (MongoClient client = MongoClients.create("mongodb://localhost:27017/?replicaSet=rs0")) {
            MongoCollection<Document> orders = client.getDatabase("shop").getCollection("orders");

            Date monthStart = new Date(); // 实际取本月 1 号 0 点，此处从简
            Date monthEnd = new Date();

            List<Bson> pipeline = Arrays.asList(
                    // 第一道永远是 $match：能用索引，砍掉 99% 的数据
                    Aggregates.match(Filters.and(
                            Filters.eq("status", "paid"),
                            Filters.gte("createdAt", monthStart),
                            Filters.lt("createdAt", monthEnd))),
                    Aggregates.unwind("$items"),
                    Aggregates.group("$items.productId",
                            Accumulators.first("productName", "$items.productName"), // 快照红利：不用 $lookup
                            Accumulators.sum("totalQty", "$items.qty"),
                            Accumulators.sum("totalAmount",
                                    new Document("$multiply", Arrays.asList("$items.qty", "$items.price")))),
                    Aggregates.sort(Sorts.descending("totalQty")),
                    Aggregates.limit(10)
            );

            List<Document> hotList = new ArrayList<>();
            orders.aggregate(pipeline)
                    .allowDiskUse(true)   // 中间结果超 100MB 允许落盘，报表查询记得开
                    .into(hotList);

            hotList.forEach(doc -> System.out.println(doc.toJson()));
        }
    }
}

三个要点：

$match 必须放第一，放 $unwind 后面等于先把 500 万订单拆成 3000 万条再筛——有人这么写过，直接把一个节点的内存打爆。
allowDiskUse(true)：聚合中间结果超 100MB 默认报错，报表类查询记得开。
能不用 $lookup 就不用。它是应急手段，性能和多表 join 一样是噩梦。需要大量 $lookup 才能完成的查询，说明建模（第三篇）出了问题——回头改模型，别在查询层硬扛。

第六篇副本集：高可用与读写语义的分水岭

单节点 MongoDB 是玩具，副本集才是起点。这篇是「会用 Mongo」和「敢把核心业务放 Mongo」之间的分水岭。

6.1 架构与选主

flowchart TD
    subgraph RS["副本集 rs0（3 节点是最小生产配置）"]
        P["Primary<br/>唯一可写"]
        S1["Secondary<br/>异步复制 oplog"]
        S2["Secondary<br/>异步复制 oplog"]
        P -- "oplog 同步" --> S1
        P -- "oplog 同步" --> S2
    end
    P -.->|"心跳超时 10s<br/>自动选主"| S1
    APP["应用（驱动）"] -->|"自动感知拓扑变化<br/>故障转移对代码透明"| RS

必须理解的机制：

oplog：主节点的操作日志，从节点靠它追赶。oplog 是有界集合，从节点宕机太久会追不上，只能全量同步（initial sync）——大库的全量同步以小时计，这就是「从节点宕机要当事故处理」的原因。
自动选主：主挂了，10 秒左右选出新主。驱动自动重连新主，应用无感——前提是连接串写对了（多节点 + replicaSet=rs0），而不是只写了一个 IP。
连接池：MongoClient 是线程安全的重对象，全应用一个单例，连接池大小用 maxPoolSize 调。每请求 new 一个 MongoClient 等于每请求建一批 TCP 连接，压测时会把数据库连接数打爆——这和「每请求连一次 MySQL」是同一种自杀。

6.2 读写语义：writeConcern 与 readConcern

这部分决定你能不能睡着觉——数据到底「写没写进去」？

// demo02-write-concern：不同档位，不同的安全与延迟权衡
import com.mongodb.WriteConcern;
import com.mongodb.client.MongoCollection;
import org.bson.Document;

MongoCollection<Document> orders = client.getDatabase("shop").getCollection("orders");

// 快但可能丢：主节点内存确认就返回（埋点日志可用）
orders.withWriteConcern(WriteConcern.W1).insertOne(logDoc);

// 安全：多数派落盘 + journal 落盘才返回（订单必须这档）
orders.withWriteConcern(WriteConcern.MAJORITY.withJournal(true)).insertOne(orderDoc);

电商业务对号入座：

业务	writeConcern	理由
订单创建	`majority` + journal	主从切换时绝不能丢单
库存扣减	`majority`	丢扣减记录不可忍
行为埋点	`w: 1`	丢几条日志无所谓，别拖累写入
购物车	`majority`	用户加购后刷新没了，投诉就来了

readConcern 同理：读「已提交到多数派」的数据用 ReadConcern.MAJORITY，避免读到主从切换后被回滚的数据。钱相关的读，一律 majority；展示类的读，local 即可。

踩坑故事 #4（丢单惊魂夜）：上线初期订单写入用默认 w: 1。某天主节点宕机选主，新主上没有最后 8 秒的 23 笔订单——用户付了钱（支付回调已记录），订单却不存在，客服电话被打爆。复盘结论：支付回调链路和订单链路的 writeConcern 必须对齐 majority，宁慢勿丢。这 8 秒人工补单补了一整夜。

思考与感悟之三：分布式系统里「默认配置」几乎都是「性能优先、安全靠边」的，MongoDB 的 w:1、MySQL 的异步复制、Kafka 的 acks=1 皆如此。成熟的标志之一：每接一个中间件，先把默认一致性档位改成业务需要的档位，再开始写业务代码。

第七篇事务与分片：规模化之后的一致性难题

7.1 能不用事务就不用：原子操作的威力

MongoDB 单文档操作天然原子。电商防超卖，一条条件更新就够，根本不需要事务：

// demo03-deduct-stock：条件原子扣减，1000 并发抢 1 件也只有 1 个成功
import com.mongodb.client.MongoCollection;
import com.mongodb.client.model.Filters;
import com.mongodb.client.model.Updates;
import com.mongodb.client.result.UpdateResult;
import org.bson.Document;
import org.bson.types.ObjectId;

public class DeductStockDemo {

    public void deduct(MongoCollection<Document> skuStocks, ObjectId skuId, int qty) {
        UpdateResult r = skuStocks.updateOne(
                // 库存够不够，放进查询条件 —— 判断和修改合并成一次原子操作
                Filters.and(
                        Filters.eq("_id", skuId),
                        Filters.gte("stock", qty)),
                Updates.combine(
                        Updates.inc("stock", -qty),
                        Updates.inc("sold", qty),
                        Updates.currentDate("updatedAt"))
        );
        if (r.getModifiedCount() == 0) {
            throw new IllegalStateException("库存不足"); // 没抢到，上层返回售罄
        }
    }
}

精髓：判断（stock >= qty）和修改（$inc）合并成一次原子操作，不存在「查出来够、扣的时候不够」的竞态。这比任何分布式锁都干净。

7.2 真正需要事务的场景

跨集合的一致性——下单要同时「扣库存 + 建订单 + 核销券」，三个动作三个集合，这时上多文档事务（4.0+，需副本集）：

// demo04-place-order-tx：多文档事务下单
import com.mongodb.ClientSessionOptions;
import com.mongodb.ReadConcern;
import com.mongodb.TransactionOptions;
import com.mongodb.WriteConcern;
import com.mongodb.client.ClientSession;
import com.mongodb.client.MongoClient;
import org.bson.Document;

public class PlaceOrderTxDemo {

    public void placeOrder(MongoClient client, Document orderDoc, ObjectId skuId, int qty, ObjectId couponId) {
        TransactionOptions txnOptions = TransactionOptions.builder()
                .readConcern(ReadConcern.SNAPSHOT)
                .writeConcern(WriteConcern.MAJORITY)
                .build();

        try (ClientSession session = client.startSession(
                ClientSessionOptions.builder().defaultTransactionOptions(txnOptions).build())) {

            session.withTransaction(() -> {
                var db = client.getDatabase("shop");

                // 1. 条件原子扣库存
                var r = db.getCollection("sku_stocks").updateOne(session,
                        com.mongodb.client.model.Filters.and(
                                com.mongodb.client.model.Filters.eq("_id", skuId),
                                com.mongodb.client.model.Filters.gte("stock", qty)),
                        com.mongodb.client.model.Updates.inc("stock", -qty));
                if (r.getModifiedCount() == 0) {
                    throw new IllegalStateException("库存不足，触发回滚");
                }

                // 2. 插入订单（含商品快照）
                db.getCollection("orders").insertOne(session, orderDoc);

                // 3. 核销优惠券
                db.getCollection("coupons").updateOne(session,
                        com.mongodb.client.model.Filters.and(
                                com.mongodb.client.model.Filters.eq("_id", couponId),
                                com.mongodb.client.model.Filters.eq("used", false)),
                        com.mongodb.client.model.Updates.set("used", true));

                return null;
            });
            // 任何一步抛异常，前面所有操作自动回滚
        }
    }
}

sequenceDiagram
    participant A as 下单服务
    participant M as MongoDB 副本集
    A->>M: withTransaction 开启
    A->>M: 1. 条件原子扣库存
    alt 库存不足
        M-->>A: modifiedCount = 0
        A->>M: 自动 abortTransaction<br/>三步全部回滚
        A-->>A: 返回售罄
    else 成功
        A->>M: 2. 插入订单(含快照)
        A->>M: 3. 核销优惠券
        A->>M: commit (w:majority)
        M-->>A: 提交成功
    end

踩坑故事 #5（事务的 QPS 税）：压测发现全事务下单链路 QPS 比「原子扣减 + 消息队列异步落单」低约 40%，且长事务会压住 WiredTiger 的旧版本清理（第二篇的坑）。大促链路的最终方案：核心扣减用单文档原子操作（快），订单与券的一致性用 MQ + 定时对账任务兜底（最终一致）。事务留给后台管理类低频强一致操作。教训：事务是保险丝，不是日常用电。

7.3 分片：单副本集扛不住之后

数据量单副本集放不下（经验值：单集合过 2TB 或写入 QPS 过万再考虑），才上分片：

flowchart TD
    APP["应用"] --> MONGOS["mongos 路由层"]
    MONGOS --> S1["Shard 1<br/>副本集"]
    MONGOS --> S2["Shard 2<br/>副本集"]
    MONGOS --> S3["Shard 3<br/>副本集"]
    MONGOS -.-> CFG["Config Server<br/>元数据副本集"]
    S1 -.->|"均衡器<br/>chunk 迁移"| S2

分片键（shard key）是 Mongo 最「一选定终身」的决策，选错无法修改（5.0 之前）。三条铁律：

高基数：用 status（只有几个枚举值）做分片键，所有数据挤在少数 chunk 里，分了个寂寞。
避免单调递增：用 createdAt 或自增 ObjectId 做分片键，所有新写入都打到最后一个分片——热点分片被写爆，其他分片围观。日志类业务要么 hash 分片键，要么接受这个形态。
匹配查询模式：订单按 userId hash 分片，「查我的订单」路由到单分片，飞快；「全平台订单报表」变成广播查询（scatter-gather），慢——所以报表本来就不该打在分片集群上，该走数仓。

踩坑故事 #6（jumbo chunk 卡死均衡）：早期一张集合按 categoryId 分片，头部类目一个 chunk 涨到 500MB 还无法拆分（jumbo chunk），均衡器彻底停摆，分片间数据倾斜到 3:1。最后导出数据重建集合换 hash 分片键才解决，停机 4 小时。分片键评审必须过架构组，这是红线第三条。

第八篇运维底线与 AI 时代：把系统做稳，把代码写少

8.1 生产运维的最低纲领

不展开讲 DBA 手册，只列必须亲自盯的五件事：

flowchart TD
    M["监控<br/>slow query / cache 压力 / oplog 窗口 / 复制延迟"] --> A["告警<br/>复制延迟 > 30s 即报警<br/>别等追不上才发现"]
    B["备份<br/> mongodump 逻辑备份<br/>+ 快照物理备份<br/>恢复演练每季度一次"] --> A
    C["慢查询<br/>profiler 只开采样<br/>每周过 top 慢查询"] --> A
    D["容量<br/>磁盘水位 70% 预警<br/>oplog 大小按写入峰值调"] --> A
    E["权限<br/>最小化授权 禁止裸奔<br/>生产禁 dropDatabase"] --> A

踩坑故事 #7（恢复演练救了我们一命）：团队坚持每季度做一次「备份恢复演练」，被吐槽形式主义。直到有人误删集合（drop() 当 deleteMany() 用了），靠备份 40 分钟恢复，业务无损。没演练过的备份等于没有备份——这句话值一个 P0 事故。

8.2 AI 时代：如何少写代码把系统做稳

写这篇博客的 2021 年，GitHub Copilot 刚发布。站在工程视角，做几个判断，留给未来验证：

AI 会吃掉「模式化代码」，吃不掉「模式化决策」。 CRUD、Schema 定义、聚合管道骨架、连接池配置——这些高度模式化的代码 AI 生成得又快又准（你甚至可以现在就试试让 Copilot 补全上面的 DeductStockDemo，完成度惊人）。但「嵌入还是引用」「分片键选什么」「writeConcern 定哪档」——这些依赖业务流量预测的决策，AI 给不出答案。核心竞争力从「会写」转向「会判断」。
「少写代码」的正确姿势是把决策做在数据层。 用快照冗余消灭 $lookup，用 TTL 索引消灭清理脚本，用原子扣减消灭分布式锁，用条件更新消灭事务——本篇通篇的「少写代码」讲的都是这个：好的建模让代码自然变少。AI 是放大器，放大的既可以是好设计，也可以是坏设计。
一个人撑起一个 App 的门槛在崩塌。 MongoDB Atlas（托管副本集/分片）+ Serverless 函数 + AI 生成 CRUD 层，一个小电商的服务端几天就能搭起来。2021 年这还只是苗头，我确信它会成常态。但反过来：门槛越低，线上事故越便宜——不懂 writeConcern 的人也能上线了，丢单的事故只会更多。AI 时代的工程教育，重点应该从「怎么实现」转向「哪里会炸」。
AI 生成代码的第一评审项是资源语义。 连接谁关、事务多长、批量多大、一致性哪档——AI 生成的代码功能往往是对的，资源语义常常是错的（比如给你 w: 1 的默认写入）。Code Review 的重心会整体迁移到这四个问题上。

思考与感悟之四（收尾）：工程的本质，是「替业务把不确定性挡在系统之外」。MongoDB 给了你自由度，也把范式的保护伞收走了——锁粒度、一致性档位、分片拓扑，每一个都要自己选。AI 会帮你把代码写得越来越快，但「选什么」的责任永远在人身上。这既是这份工作的辛苦之处，也是它的护城河。

附录：Demo 与检查清单

Demo	类/片段	覆盖知识点
建索引	`IndexDemo`	ESR 复合索引、部分索引、TTL 索引
热销榜聚合	`TopSalesDemo`	`$match` 前置、`$unwind`/`$group`、`allowDiskUse`
写入档位	`demo02-write-concern`	`w:1` / `majority` / journal 的取舍
原子扣库存	`DeductStockDemo`	条件原子更新防超卖
事务下单	`PlaceOrderTxDemo`	多文档事务、回滚、事务读写关注级别

MongoDB 生产红线（本文沉淀，可直接抄进团队规范）：

生产环境永远不开不设限的大批量更新，批量操作必拆批 + 让出窗口。
凡带 sort 的查询，必须 explain 验证走索引排序。
分片键评审必须过架构组；能用副本集解决的绝不上分片。
钱相关的读写一律 majority；默认配置永远不可信。
备份必须每季度做恢复演练，没演练过的备份等于没有备份。

文中代码基于 MongoDB 5.0 + 官方 Java 同步驱动 4.3 实测可编译运行。如果你正站在「要不要接 MongoDB」的门口，建议按八篇顺序在本地副本集上把每个坑亲手复现一遍——看别人踩坑是故事，自己踩一遍才是经验。

Lua 入门：写给 Redis 脚本使用者的极简教程

Sun, 03 Oct 2021 10:00:00 +0800

Lua 入门：写给 Redis 脚本使用者的极简教程

Redis 从 2.6 开始支持 Lua 脚本，核心目的是把多个命令打包成原子操作。本文面向已经会用 Redis、但还没写过 Lua 脚本的同学，只讲最常用、最实用的部分，学完就能写出常见的限流、加锁、库存扣减脚本。

一、为什么 Redis 需要 Lua

Redis 单条命令是原子的，但多条命令组合起来就不是了。比如经典的「查库存 → 判断 → 扣减」：

GET stock:1001      # 返回 10
# 业务代码判断 10 > 0
DECR stock:1001     # 返回 9

并发时两个客户端可能都读到 10，然后都执行 DECR，导致超卖。

Lua 脚本在 Redis 里作为一个整体执行，中间不会被其他命令打断，天然解决了这类问题。而且脚本在 Redis 服务端执行，还能减少网络往返。

二、本地 Lua 环境准备

2.1 安装 Lua

macOS：

brew install lua
lua -v

Ubuntu / Debian：

sudo apt update
sudo apt install lua5.1
lua5.1 -v

Windows：

从 Lua 官方下载源码或预编译二进制，也可以直接用 Lua for Windows。

Docker（最省事）：

docker run --rm -it nickblah/lua:5.1 lua -v

2.2 第一个本地 Lua 程序

创建 hello.lua：

print("hello, lua")

运行：

lua hello.lua

2.3 用 Redis 验证脚本

如果你本地有 Redis，可以直接用 redis-cli 跑脚本文件：

redis-cli --eval myscript.lua key1 key2 , arg1 arg2

注意 , 前后都有空格：, 左边是 KEYS，右边是 ARGV。

2.4 编辑器推荐

VS Code：插件 Lua（sumneko）或 Lua Language Server。
IDEA / WebStorm：安装 EmmyLua 插件。
Neovim：lua_ls + lspconfig。

三、Hello World：第一个 Redis Lua 脚本

EVAL "return 'hello, redis lua'" 0

EVAL 是执行 Lua 脚本的命令。
后面的 0 表示脚本用到的 key 数量是 0。
return 把结果返回给客户端。

带 key 和参数的版本：

EVAL "return redis.call('GET', KEYS[1])" 1 user:1
# 等同于 GET user:1

EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 user:1 alice
# 等同于 SET user:1 alice

KEYS[1] 对应第 1 个 key，KEYS[2] 对应第 2 个，以此类推。
ARGV[1] 对应第 1 个额外参数。
所有 ARGV 都是字符串，如果需要数字，要在 Lua 里做类型转换。

四、Lua 基础：Redis 场景够用的子集

4.1 变量与类型

Lua 是动态类型语言，常用类型有：nil、boolean、number、string、table。

local name = "alice"      -- 字符串
local age = 30            -- 数字，不区分 int / float
local ok = true           -- 布尔
local empty = nil         -- 空

注意：

局部变量用 local，否则会成为全局变量。Redis 脚本里建议一律用 local。
条件判断时，0 和空字符串 '' 都是 true，只有 nil 和 false 是 false。

local a = 0
if a then
    return "yes"    -- 会执行这里
end

4.2 字符串与数字转换

local s = "42"
local n = tonumber(s)      -- 转成数字 42
local s2 = tostring(n)     -- 转成字符串 "42"

local a = "10"
local b = "3"
local c = a + b            -- 13，自动把字符串当数字

在 Redis 脚本里，更推荐显式转换，避免意外：

local count = tonumber(redis.call('GET', KEYS[1])) or 0

4.3 表（table）：数组 + 字典

表是 Lua 唯一的数据结构，既能当数组用，也能当字典用。

-- 数组（下标从 1 开始）
local arr = {"a", "b", "c"}
return arr[1]    -- "a"

-- 字典
local dict = {name = "alice", age = 30}
return dict.name -- "alice"

遍历数组：

local arr = {"a", "b", "c"}
for i, v in ipairs(arr) do
    print(i, v)
end
-- 输出：
-- 1 a
-- 2 b
-- 3 c

遍历字典：

local dict = {name = "alice", age = 30}
for k, v in pairs(dict) do
    print(k, v)
end

4.4 条件判断

local n = 10
if n > 20 then
    return "big"
elseif n > 5 then
    return "medium"   -- 会返回这个
else
    return "small"
end

4.5 循环

-- for 循环
for i = 1, 5 do
    print(i)
end

-- while 循环
local i = 1
while i <= 5 do
    print(i)
    i = i + 1
end

Redis 脚本里循环要慎用，避免执行时间过长阻塞主线程。

4.6 函数

local function add(a, b)
    return a + b
end

return add(1, 2)  -- 3

五、Lua 原理浅析

理解 Lua 的运行机制，能帮你写出更稳的 Redis 脚本。

5.1 解释器与字节码

Lua 不是纯解释执行。它会把源码编译成字节码（bytecode），然后在 Lua 虚拟机（VM）上运行。

luac -o hello.luac hello.lua    -- 编译成字节码
lua hello.luac                   -- 运行字节码

Redis 内部集成的也是 Lua VM，脚本第一次执行时会先编译成字节码，之后再执行就复用这个结果。所以长脚本第一次跑会慢一点，后续重复执行会快一些。

5.2 内存回收机制

Lua 使用自动垃圾回收（Garbage Collection, GC），主要策略是增量式标记-清除（incremental mark-and-sweep）。Lua 5.4 还引入了分代 GC 模式。

对 Redis 脚本来说，关键点是：

脚本运行期间创建的 table、string 等临时对象，由 Lua GC 自动回收。
Redis 脚本通常很短，GC 压力不大。
不要在脚本里构造超大 table 或缓存大量中间结果，否则可能触发 GC 暂停，阻塞 Redis。

5.3 Table 是核心

Lua 的 table 本质上是一个哈希表 + 数组的混合结构：

用连续整数索引时，底层按数组优化，访问快。
用字符串或其他类型当 key 时，底层是哈希表。

这也是 Lua 能用 table 模拟数组、字典、对象、模块的原因。

5.4 Redis 中的 Lua 沙箱

Redis 对 Lua 做了严格限制：

不能加载外部库（如 io、os 大部分功能被禁用）。
不能发起网络请求。
不能访问文件系统。
只能调用 Redis 提供的 API（如 redis.call、redis.log）。

这个沙箱保证了脚本安全，但也意味着你不能直接在脚本里读系统时间（os.time 被禁用），需要把时间作为 ARGV 传进去。

六、Redis 脚本核心 API

6.1 redis.call 与 redis.pcall

redis.call(...)：调用 Redis 命令，出错时直接抛出 Lua 错误，脚本会终止。
redis.pcall(...)：调用 Redis 命令，出错时返回错误对象，脚本继续执行。

-- call 版本：key 不存在会报错
local v = redis.call('GET', 'non_existent_key')

-- pcall 版本：可以捕获错误
local ok, err = pcall(redis.call, 'GET', 'non_existent_key')
if not ok then
    return "error: " .. tostring(err)
end

一般推荐：

简单脚本用 redis.call，逻辑更清晰。
需要容错时用 redis.pcall 或外层 pcall。

6.2 返回值

Lua 脚本可以返回单个值、数组或表：

-- 返回单个值
return redis.call('GET', KEYS[1])

-- 返回多个值
return {redis.call('GET', KEYS[1]), redis.call('GET', KEYS[2])}

Redis 会把 Lua 的 table 转成数组返回给客户端。

6.3 KEYS 与 ARGV 的规范

Redis Cluster 要求脚本里用到的 key 都必须放在 KEYS 中，这样 Redis 才能判断脚本是否跨 slot。ARGV 里只能放非 key 参数。

EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue

这里 mykey 是 key，myvalue 是 value。

七、实战：常见 Redis Lua 模式

7.1 限流（滑动窗口）

限制某个用户在 60 秒内最多请求 100 次：

local key = KEYS[1]
local window = tonumber(ARGV[1])      -- 窗口大小，毫秒
local limit = tonumber(ARGV[2])       -- 限制次数
local now = tonumber(ARGV[3])         -- 当前时间戳，毫秒

-- 清理窗口外的请求记录
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)

-- 统计当前窗口内的请求数
local count = redis.call('ZCARD', key)

if count < limit then
    redis.call('ZADD', key, now, now .. "_" .. count)
    redis.call('PEXPIRE', key, window)
    return 1   -- 允许通过
else
    return 0   -- 拒绝
end

调用：

EVAL "...脚本..." 1 rate:user:1 60000 100 1690000000000

7.2 分布式锁（可重入简化版）

local key = KEYS[1]
local token = ARGV[1]
local ttl = tonumber(ARGV[2])

local current = redis.call('GET', key)
if current == false or current == token then
    redis.call('SET', key, token, 'PX', ttl)
    return 1
else
    return 0
end

7.3 库存扣减（防超卖）

local key = KEYS[1]
local delta = tonumber(ARGV[1])

local stock = tonumber(redis.call('GET', key)) or 0
if stock < delta then
    return -1    -- 库存不足
end

redis.call('DECRBY', key, delta)
return stock - delta

7.4 批量删除符合某种前缀的 key

注意：生产环境慎用 KEYS 命令，这里仅作语法示例，大数据量请用 SCAN。

local pattern = ARGV[1]
local keys = redis.call('KEYS', pattern)

for i, k in ipairs(keys) do
    redis.call('DEL', k)
end

return #keys

7.5 条件更新（CAS 简化版）

local key = KEYS[1]
local expected = ARGV[1]
local newValue = ARGV[2]

local current = redis.call('GET', key)
if current == expected then
    redis.call('SET', key, newValue)
    return 1
else
    return 0
end

八、调试、常见坑与最佳实践

8.1 调试脚本

先用本地 Redis 跑：redis-cli --eval script.lua key1 key2 , arg1 arg2
- 注意 , 前后有空格，, 左边是 KEYS，右边是 ARGV。
打印日志：Lua 脚本里不能直接用 print 输出到客户端，但可以用 redis.log(redis.LOG_NOTICE, msg) 写到 Redis 日志。

redis.log(redis.LOG_NOTICE, "current stock: " .. tostring(stock))

本地先用 lua 命令跑语法：不依赖 Redis 也能检查基础语法错误。

8.2 常见踩坑清单

坑	说明	建议
ARGV 全是字符串	数字运算前必须 `tonumber()`	每个数字参数都显式 `tonumber()`
全局变量	忘了 `local` 可能污染全局环境，Redis 甚至会杀掉脚本	所有变量一律加 `local`
脚本执行时间	循环、大 key 操作会阻塞 Redis 主线程	脚本尽量短，避免复杂循环
集群 key 位置	所有 key 必须写在 `KEYS` 里，跨 slot 会报错	业务 key 设计时确保同一 slot
脚本缓存	长脚本每次 EVAL 都传输浪费带宽	生产环境用 `EVALSHA` 或客户端自动缓存
`nil` 中断数组	table 中间出现 `nil` 会导致 `#` 长度计算出错	避免在数组中间塞 `nil`
`pairs` 遍历顺序	`pairs` 不保证顺序，`ipairs` 才按数组顺序	需要顺序时用 `ipairs` 或自己维护索引
字符串拼接性能	`..` 在循环里反复拼接是 O(n²)	用 `table.concat` 批量拼接
`redis.call` 报错	命令执行失败会直接抛错终止脚本	需要容错时改用 `redis.pcall`
缺失 key 的返回值	`GET` 不存在的 key 返回 `false`，不是 `nil`	判断时用 `== false` 或 `if not current`
写命令必须确定性的	主从复制/持久化要求相同的脚本产生相同结果	不要用随机数、`TIME`、`SRANDMEMBER` 等做写决策
浮点数比较	`0.1 + 0.2 ~= 0.3`	用整数存储金额/库存，避免浮点

8.3 性能建议

脚本尽量短小，只处理一个原子逻辑单元。
不要在 Lua 里做复杂计算或大量循环。
大 key 操作（如 HGETALL 几十万字段）不要在脚本里做。
热 key 尽量缩短 TTL 或做拆分，避免单脚本长时间占用。
对执行时间没把握的脚本，先用 redis-cli --latency-history 或 SLOWLOG 观察影响。

九、总结

Redis Lua 脚本不需要你成为 Lua 专家，掌握下面几点就能覆盖 80% 的场景：

本地能跑 Lua，能写 .lua 文件并用 redis-cli --eval 测试。
local 变量、number / string / table 三种类型。
tonumber() / tostring() 转换，ipairs() / pairs() 遍历，table.concat 拼接。
Lua 是编译成字节码在 VM 上运行，GC 自动回收，Redis 里是沙箱环境。
redis.call() 调用命令，KEYS[n] 和 ARGV[n] 传参，集群 key 必须放 KEYS。
脚本整体原子执行，适合「读 → 判断 → 写」的复合操作。
注意 ARGV 是字符串、缺失 key 返回 false、避免长脚本阻塞、写命令要确定性。

限流、分布式锁、库存扣减、条件更新这些高频场景，本质上都是同一个模式：先读数据，在脚本里做判断，再决定写什么。把这一点练熟，Redis Lua 就入门了。

如果你在 Redis Lua 脚本里踩过什么坑，欢迎在评论区分享。

从Redis核心原理到 IPTV 视频项目落地

Tue, 28 Sep 2021 10:00:00 +0800

从Redis核心原理到 IPTV 视频项目落地

先系统梳理 Redis 的核心原理与面试高频知识点，再结合 IPTV（交互式网络电视）视频业务场景，给出可直接运行的 Demo。最后讨论 Redis 为什么不适合长期存储、常见踩坑点，以及 List / Pub/Sub / Stream 三种消息队列实现。

一、Redis 是什么？一句话定位

Redis（Remote Dictionary Server）是一个开源的、基于内存的高性能键值对数据库，支持多种数据结构、持久化、高可用与分布式扩展。

graph LR
    A[Redis] --> B[内存存储]
    A --> C[数据结构服务器]
    A --> D[单线程命令执行]
    A --> E[IO 多路复用]
    A --> F[持久化 + 高可用]
    B --> G[读写毫秒级]
    C --> H[String/Hash/List/Set/ZSET/Stream/Bitmap/Geo/HyperLogLog]
    F --> I[RDB/AOF/主从/哨兵/Cluster]

与 Memcached 等纯缓存不同，Redis 的核心价值在于丰富的数据结构与原子操作，可以直接在内存中完成排序、计数、限流、去重、队列等复杂逻辑。

二、Redis 为什么快？

面试常问「Redis 为什么快」，通常从四个层面回答：

原因	说明
内存操作	数据存于内存，无需磁盘寻道，访问速度是 SSD 的千倍以上。
单线程命令执行	避免多线程上下文切换、锁竞争，CPU 缓存命中率更高。
IO 多路复用	基于 epoll/kqueue/select 用一个线程处理大量连接。
高效数据结构	String 底层 SDS、ZSET 底层跳表+字典、List 底层 quicklist 等。

graph TB
    subgraph Redis 6/7 线程模型
        M[主线程<br/>命令执行 + IO 多路复用]
        IO[IO 线程池<br/>仅网络读写]
        BG[后台进程<br/>RDB fork / AOF rewrite]
    end
    C1[Client 1] --> M
    C2[Client 2] --> M
    C3[Client 3] --> M
    M <--> IO
    M -.-> BG

注意：Redis 6/7 引入的多线程只用于网络 IO 读写，命令执行依旧是单线程。所以单条慢命令仍会阻塞整个实例。

三、Redis 数据类型与使用场景

3.1 五种基本数据类型

类型	底层结构	典型场景
String	SDS（简单动态字符串）	缓存、计数器、分布式锁、Session
Hash	ziplist / hashtable	对象缓存、用户信息、EPG 节目单
List	quicklist（ziplist + 双向链表）	消息队列、最新 N 条记录
Set	intset / hashtable	去重、共同关注、抽奖
ZSET	ziplist / skiplist + dict	排行榜、延时队列、范围查询

注：表中 ziplist 在 Redis 7 起已被 listpack 替代（动机见 §4.2），配置项改名 *-max-listpack-*，旧名仍兼容。

3.2 三种特殊数据类型

类型	说明	场景
Bitmap	位数组，按位操作	用户签到、在线状态、UV 统计
HyperLogLog	基数估计算法	海量 UV 去重计数，误差约 0.81%
Geo	地理位置坐标	附近的人、POI 搜索

3.3 String：最常用却被低估

String 不仅能存字符串，还能存整数、浮点数、二进制数据。常用命令：

SET key value EX 3600
GET key
INCR view_count
INCRBY view_count 10
SETNX lock:order:123 true EX 30  # 分布式锁核心命令

SDS 的优势（相对 C 字符串）：

O(1) 获取长度。
二进制安全，可存图片、序列化数据。
预分配空间，减少内存重分配次数。
杜绝缓冲区溢出。

3.4 Hash：对象缓存首选

Hash 适合存「一组字段」的对象，比 JSON String 更节省内存、更新更灵活。

HSET user:1001 name "张三" age 30 city "北京"
HGET user:1001 name
HGETALL user:1001
HINCRBY user:1001 age 1

3.5 ZSET：排行榜的王牌

ZSET 底层同时维护「跳表」和「字典」：

跳表（skiplist）：支持 O(log N) 的范围查询和排序。
字典（dict）：支持 O(1) 按 member 查 score。

ZADD hot:tv 1000 "庆余年"
ZADD hot:tv 800 "狂飙"
ZINCRBY hot:tv 50 "狂飙"
ZREVRANGE hot:tv 0 9 WITHSCORES
ZREVRANK hot:tv "狂飙"

3.6 List 与 Stream：队列双雄

List 适合简单队列，Stream 适合生产级消息队列，后面第十四部分会详细对比。

3.7 Bitmap 与 HyperLogLog：海量 UV 统计的利器

Bitmap 为什么能天然去重？

Bitmap 本质是一个超长 bit 数组，每个 bit 只能是 0 或 1。把 user_id 作为偏移量（offset），用户访问一次就把对应位置 1：

天然去重：同一用户重复访问，置的都是同一个 bit，无需额外判断。
极致省内存：1 亿用户只需 1 亿 bit ≈ 12MB；而 Set 存 1 亿个 ID 要占用数 GB。
支持位运算：BITOP AND/OR 可以直接算多日留存（今天访问 AND 昨天也访问）。

SETBIT uv:20210928 10086 1   # 用户 10086 访问
SETBIT uv:20210928 10086 1   # 重复访问，结果不变
BITCOUNT uv:20210928         # 直接得出 UV 数

局限：要求 user_id 是连续整数，ID 稀疏时浪费内存。

HyperLogLog 为什么 12KB 能数一亿？

HyperLogLog 基于概率估计算法：把每个元素 hash 成均匀分布的随机数，观察 hash 值二进制串中前导零的最大个数。

类比抛硬币：想连续抛出 N 次正面，平均要抛 2^N 次。反过来，如果见过最长连续 N 次正面，就估计大约抛了 2^N 次——前导零越多，说明见过的不同元素越多。
单次估计误差大，所以内部用 16384 个分桶（寄存器，每个 6 bit） 分别记录，再取调和平均数消除偶然性，最终误差稳定在 0.81% 左右。
内存恒定 约 12KB，与元素个数无关：统计 1 亿 UV 还是 10 亿 UV 都是 12KB。

PFADD uv:20210928 "user:10086"
PFADD uv:20210928 "user:10086"  # 重复添加不影响计数
PFCOUNT uv:20210928             # 估算 UV

局限：有误差、不可逆（不能取出具体是哪些用户）。

怎么选：

需求	推荐
精确计数、算多日留存（交并集）、ID 是连续整数	Bitmap
只要近似 UV、数据量极大、ID 是任意字符串	HyperLogLog

四、Redis 底层数据结构速览

graph TD
    A[Redis 数据类型] --> B[String]
    A --> C[Hash]
    A --> D[List]
    A --> E[Set]
    A --> F[ZSET]
    B --> G[SDS]
    C --> H[ziplist]
    C --> I[hashtable]
    D --> J[quicklist]
    E --> K[intset]
    E --> L[hashtable]
    F --> M[ziplist]
    F --> N[skiplist + dict]

底层结构	特点
SDS	带长度、预分配、二进制安全。
ziplist	紧凑列表，小数据量时省内存；大数据量时改为 hashtable/skiplist。
listpack	ziplist 的修正版（Redis 7+）：entry 只记自身长度，消灭连锁更新。
quicklist	List 的底层，由多个紧凑块（Redis 7 前是 ziplist，之后是 listpack）节点组成的双向链表。
hashtable	标准哈希表，渐进式 rehash 避免一次性阻塞。
intset	Set 在元素全为整数且数量少时的紧凑实现。
skiplist	多层索引链表，实现 ZSET 的有序范围查询。

下面把 5 种核心结构「画」出来。

4.1 SDS（Simple Dynamic String）

Redis 没有直接用 C 字符串，而是包了 SDS：

flowchart LR
    L["len<br/>已用长度（4B）<br/>= 5"] --- A["alloc<br/>总容量<br/>= 8"] --- F["flags<br/>编码位<br/>= 0"] --- B["buf[]<br/>实际字符/二进制数据<br/>H e l l o \0 ..."]
    N1["O(1) 取长度"] -.-> L
    N2["末尾保留 \0<br/>兼容 C 字符串函数"] -.-> B

len：已用长度，取长度 O(1)。
alloc：分配的总空间；free = alloc - len 可减少内存重分配。
二进制安全：内容中间可以有 \0，长度由 len 决定。
预分配：修改时若 free 足够就不 realloc；不足时按 2 倍或 1MB 上限预分配。

4.2 ziplist（压缩列表）

ziplist 是一块连续内存，把所有 entry 紧凑排列：

flowchart LR
    A["zlbytes<br/>总字节数<br/>4B"] --- B["zltail<br/>尾偏移量<br/>4B"] --- C["zllen<br/>节点数<br/>2B"] --- D["entry1<br/>变长字节"] --- E["entry2<br/>变长字节"] --- F["..."] --- G["zlend<br/>0xFF<br/>1B"]

每个 entry 的内部结构：

flowchart LR
    A["prevlen<br/>前节点长度<br/>1B 或 5B"] --- B["encoding<br/>编码/长度类型<br/>1B 或更多"] --- C["content<br/>实际数据<br/>变长"]

连续内存、无额外指针，所以省内存。
插入/删除需要整体 memmove，因此只用于小数据量。
Hash/List/ZSET 元素少且单元素短时先用 ziplist，超过阈值升级为 hashtable/skiplist。

listpack（Redis 7 的替代者）：ziplist 的致命伤就藏在 prevlen 里——每个 entry 要记录前一个 entry 的长度：前 entry 小于 254 字节时 prevlen 占 1B，达到 254 字节时占 5B。于是一个 entry 从 253 涨到 254 字节，会让后面每个 entry 的 prevlen 从 1B 膨胀到 5B，膨胀又可能触发下一个 entry 继续膨胀——连锁更新，最坏 O(N²)。

listpack 的修法：每个 entry 只记录自己的总长度，且存在 entry 末尾，entry 之间互不引用——改任何一个 entry 都不会波及邻居，连锁更新从根上消失。Redis 7 起 Hash/List/ZSET 的小对象编码全部换成 listpack，配置项同步改名（hash-max-listpack-entries 等，旧的 *-ziplist-* 名仍兼容）。面试回答「ziplist 和 listpack 的区别」，核心就是这一句：ziplist 记前驱长度所以连锁更新，listpack 记自身长度所以免疫。

4.3 quicklist（快速列表）

Redis 3.2 后，List 的底层是 quicklist = 双向链表 + ziplist：

flowchart LR
    H["head"] --> A["ziplist A<br/>[a|b|c]<br/>count=3<br/>sz=..."] <--> B["ziplist B<br/>[d|e|f|g]<br/>count=4<br/>sz=..."] <--> C["..."]
    N["每个节点是一个 ziplist<br/>节点之间用 prev/next 指针连接"] -.-> A

quicklistNode 结构：

flowchart LR
    A["prev<br/>指针"] --- B["next<br/>指针"] --- C["zl<br/>ziplist"] --- D["sz<br/>字节数"] --- E["count<br/>元素个数"] --- F["encoding<br/>是否压缩"]

结合了双向链表「插入删除快」和 ziplist「省内存」的优点。
每个节点只存少量元素，避免单个 ziplist 太大导致 memmove 开销。
Redis 7 起节点从 ziplist 换成 listpack（动机见 §4.2），但 quicklist 的「链表 + 紧凑块」思想不变。

4.4 intset（整数集合）

Set 在元素全为整数且数量少时使用 intset，否则升级为 hashtable：

flowchart LR
    A["encoding<br/>编码类型<br/>2B/4B/8B"] --- B["length<br/>元素个数<br/>4B"] --- C["contents[]<br/>有序整数数组<br/>[1] [3] [5] [7] [9] ..."]

有序数组，支持二分查找 O(log N)。
所有元素用同一 encoding；加入更大范围整数时可能整体升级（如 int16 → int32），升级是 O(N)。
无重复元素（Set 语义）。

4.5 skiplist（跳表）

ZSET 同时维护 skiplist + dict：

skiplist：按 score 排序，支持范围查询 / 排名 O(log N)。
dict：按 member 查 score，O(1)。

普通有序链表只能顺序扫描，跳表加了多层「快速通道」：

flowchart LR
    subgraph L3["level 3"]
        A3["1"] --> B3["9"] --> C3["15"]
    end
    subgraph L2["level 2"]
        A2["1"] --> B2["5"] --> C2["9"] --> D2["13"] --> E2["15"]
    end
    subgraph L1["level 1"]
        A1["1"] --> B1["3"] --> C1["5"] --> D1["7"] --> E1["9"] --> F1["11"] --> G1["13"] --> H1["15"]
    end
    A3 --- A2 --- A1
    B3 --- C2 --- E1
    C3 --- E2 --- H1
    HEAD["头节点"] -.-> A1
    H1 -.-> TAIL["尾节点"]

跳表节点结构：

flowchart LR
    A["member<br/>成员字符串<br/>（sds）"] --- B["score<br/>分数<br/>（double）"] --- C["forward[] 数组<br/>[L1指针， L2指针， L3指针， ...]<br/>最高层数 = 随机 1~32"]

概率平衡：不用像红黑树那样做复杂旋转。
查找 score=11 时，先在高层大步跳跃，再逐层下降，平均 O(log N)。
配合 dict 实现 ZSCORE 的 O(1) 查询。

五、Redis 持久化：RDB 与 AOF

Redis 提供两种持久化方式，各有优劣。

5.1 RDB（Redis Database）

在指定时间间隔内将内存数据集快照写入磁盘。

save 900 1      # 900 秒内至少 1 次修改则触发
save 300 10     # 300 秒内至少 10 次修改则触发
save 60 10000   # 60 秒内至少 10000 次修改则触发

优点：

文件紧凑，适合备份和灾难恢复。
恢复速度快。

缺点：

两次快照之间数据可能丢失。
bgsave 通过 fork() 子进程生成，大数据集时可能阻塞主线程。

5.2 AOF（Append Only File）

将每次写操作命令追加到日志文件。

appendonly yes
appendfsync everysec  # 每秒刷盘一次（推荐）
# appendfsync always  # 每次写都刷盘，最安全但最慢
# appendfsync no      # 由操作系统决定，最快但不安全

优点：

数据安全性更高，默认最多丢失 1 秒数据。

缺点：

文件体积大。
恢复速度慢。
AOF 重写（rewrite）时会占用额外资源。

5.3 混合持久化（Redis 4.0+）

AOF 重写时先写入 RDB 全量数据，再追加增量 AOF，兼顾恢复速度和数据安全。

aof-use-rdb-preamble yes

graph LR
    A[持久化选择] --> B[RDB]
    A --> C[AOF]
    A --> D[混合持久化]
    B --> E[适合备份/快速恢复]
    C --> F[适合低丢失容忍]
    D --> G[生产推荐]

八股重点：Redis 的持久化是「灾难恢复手段」，不是「主存储方案」。

六、过期删除与内存淘汰

6.1 过期删除策略

Redis 对过期 Key 采用两种策略结合：

策略	说明	优点	缺点
惰性删除	访问 Key 时检查是否过期，过期则删除。	CPU 开销小	过期 Key 可能长期占用内存
定期删除	每隔一段时间随机抽查部分 Key 删除。	平衡内存与 CPU	仍可能有漏网之鱼

6.2 内存淘汰策略

当内存达到 maxmemory 时，根据 maxmemory-policy 决定如何淘汰：

策略	说明
`noeviction`	不淘汰，写操作直接报错。
`allkeys-lru`	所有 Key 中淘汰最近最少使用。
`volatile-lru`	只在设置了 TTL 的 Key 中淘汰最近最少使用。
`allkeys-random`	所有 Key 中随机淘汰。
`volatile-random`	只在设置了 TTL 的 Key 中随机淘汰。
`volatile-ttl`	淘汰即将过期的 Key。
`allkeys-lfu`	所有 Key 中淘汰使用频率最低的。
`volatile-lfu`	只在设置了 TTL 的 Key 中淘汰使用频率最低的。

生产建议：

必须设置 maxmemory。
缓存场景推荐 allkeys-lru 或 allkeys-lfu。
有冷热区分时可用 volatile-lru，但必须给 Key 设置 TTL。

七、Redis 高可用架构

7.1 主从复制（Replication）

一主多从，读流量分摊到从节点。

graph LR
    M[Master<br/>写 + 读] -->|全量/增量同步| S1[Slave 1<br/>读]
    M --> S2[Slave 2<br/>读]
    M --> S3[Slave 3<br/>读]

复制过程：

Slave 发送 PSYNC runId offset。
如果 runId 一致且 offset 在复制积压缓冲区中，则增量同步。
否则全量同步：Master 执行 bgsave 生成 RDB，发送给 Slave。

复制延迟问题：

主从异步复制必然存在延迟。
读从库时可能读到旧数据，需要业务容忍或强制走主库。

7.2 哨兵（Sentinel）

实现自动故障转移，解决主节点宕机问题。

graph TB
    subgraph Sentinel 集群
        Se1[Sentinel 1]
        Se2[Sentinel 2]
        Se3[Sentinel 3]
    end
    M[Master] --> S1[Slave 1]
    M --> S2[Slave 2]
    Se1 -->|监控| M
    Se2 -->|监控| M
    Se3 -->|监控| M
    Se1 -.-> Se2
    Se2 -.-> Se3

核心机制：

主观下线（SDOWN）：单个 Sentinel 认为 Master 不可用。
客观下线（ODOWN）：多数 Sentinel 达成一致。
Leader 选举：Sentinel 之间通过 Raft 算法选举出执行故障转移的 Leader。
故障转移：选一个 Slave 提升为 Master，通知其他 Slave 和客户端。

7.3 Cluster 集群

Redis Cluster 采用无中心架构，数据按槽位分布。

graph TB
    subgraph Redis Cluster
        N1[Node 1<br/>0-5460]
        N2[Node 2<br/>5461-10922]
        N3[Node 3<br/>10923-16383]
    end
    N1 <--> N2
    N2 <--> N3
    N1 <--> N3

关键概念：

集群共有 16384 个槽（slot）。
每个 Key 通过 CRC16(key) % 16384 计算所属槽。
每个 Master 负责一部分槽，可配置 Slave 做高可用。
客户端访问错误节点时，会收到 MOVED 或 ASK 重定向。

MOVED vs ASK：

MOVED：槽已经永久迁移到目标节点。
ASK：槽正在迁移中，先访问目标节点一次。

八、事务与 Lua 脚本

8.1 事务（MULTI/EXEC/DISCARD/WATCH）

MULTI
SET a 1
INCR b
EXEC

特点：

命令按顺序入队，EXEC 时一次性执行。
执行期间不会被其他客户端打断。
但没有回滚机制：如果某条命令语法错误，整个事务不执行；如果运行时错误（如 INCR 字符串），后续命令仍会执行。

8.2 Lua 脚本

EVAL "return redis.call('incr', KEYS[1])" 1 counter

特点：

整个脚本作为一个整体在单线程中原子执行。
适用于需要多个命令且要保证原子性的场景，如秒杀、分布式锁、限流。
集群模式下所有 Key 必须落在同一 slot，否则需要加 hash tag，如 {user}:1001:profile。

九、缓存经典问题

9.1 缓存穿透

问题：查询不存在的数据，缓存不命中，请求直接打到数据库。

解法：

缓存空值（设置短 TTL）。
使用布隆过滤器预先判断 Key 是否存在。

9.2 缓存击穿

问题：热点 Key 突然过期，大量请求同时打到数据库。

解法：

热点 Key 设置永不过期，异步更新。
加互斥锁（SETNX），只允许一个线程重建缓存。

9.3 缓存雪崩

问题：大量 Key 同时过期，或 Redis 宕机，数据库压力陡增。

解法：

给 TTL 加随机值，避免同时失效。
多级缓存（本地 + Redis）。
熔断降级。

9.4 缓存与数据库一致性

常见策略：

策略	说明	问题
Cache Aside	读：先读缓存，未命中读 DB 并写回缓存；写：先更新 DB，再删缓存。	短暂不一致
Read/Write Through	由缓存层统一维护 DB 和缓存。	实现复杂
Write Behind	先写缓存，异步写 DB。	可能丢数据

最常用的是 Cache Aside，配合「先更新数据库，再删除缓存」+ 延时双删 + 消息队列补偿，能在大多数场景下保证最终一致。

十、Redis 在 IPTV 系统中的角色

IPTV 系统的特点是：高并发读、强实时性、热点集中、写流量脉冲式。用户在换台、看 EPG、播放点播、抢购付费节目时，系统需要在毫秒级返回结果。

flowchart TB
    subgraph 用户层
        A[机顶盒 / 手机 / Web]
    end

    subgraph 接入层
        B[CDN / 边缘节点]
        C[API Gateway]
    end

    subgraph 应用层
        D[鉴权服务]
        E[EPG 服务]
        F[播放调度服务]
        G[订单 / 秒杀服务]
    end

    subgraph 数据层
        H[(MySQL / 长视频元信息)]
        I[(对象存储 OSS)]
        J[(Redis 缓存 + 实时计算)]
    end

    A --> B --> C
    C --> D & E & F & G
    D --> J
    E --> J
    F --> J
    G --> J
    E --> H
    F --> I
    G --> H
    J -.-> H

场景	Redis 数据结构	作用
用户会话 / Token	String + EXPIRE	毫秒级鉴权
EPG 节目单缓存	Hash / JSON String	减少数据库查询
热播榜单 / 推荐位	Sorted Set (ZSET)	实时排序
播放限速 / 防刷	Lua + INCR + EXPIRE	滑动窗口限流
秒杀 / 付费解锁	SETNX + DECR + Lua	库存扣减
消息通知 / 任务队列	List / Stream	异步解耦

十一、IPTV 项目 Demo

11.1 用户会话缓存

import redis
import uuid
import time

r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

def login(user_id: str, device_id: str, ttl: int = 3600) -> str:
    token = str(uuid.uuid4())
    key = f"session:{token}"
    r.hset(key, mapping={
        "user_id": user_id,
        "device_id": device_id,
        "login_at": str(time.time())
    })
    r.expire(key, ttl)
    return token

def auth(token: str) -> dict | None:
    return r.hgetall(f"session:{token}")

11.2 EPG 节目单缓存

import json
from datetime import datetime

def cache_epg(channel_id: str, programs: list[dict]):
    key = f"epg:{channel_id}:{datetime.today().strftime('%Y%m%d')}"
    pipe = r.pipeline()
    for p in programs:
        pipe.hset(key, p['start_time'], json.dumps(p))
    pipe.expire(key, 86400 * 2)
    pipe.execute()

def get_program(channel_id: str, start_time: str) -> dict | None:
    data = r.hget(f"epg:{channel_id}:{datetime.today().strftime('%Y%m%d')}", start_time)
    return json.loads(data) if data else None

11.3 热播排行榜

def record_view(program_id: str, score: float = 1.0):
    r.zincrby("hot:tv:daily", score, program_id)

def top_n(n: int = 10) -> list[tuple[str, float]]:
    return r.zrevrange("hot:tv:daily", 0, n - 1, withscores=True)

11.4 滑动窗口限流

LIMIT_SCRIPT = """
local key = KEYS[1]
local window = tonumber(ARGV[1])
local limit = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local min = now - window

redis.call('zremrangebyscore', key, '-inf', min)
local count = redis.call('zcard', key)
if count < limit then
    redis.call('zadd', key, now, now)
    redis.call('expire', key, math.ceil(window / 1000))
    return 1
else
    return 0
end
"""

limiter = r.register_script(LIMIT_SCRIPT)

def allow(user_id: str, max_qps: int = 10, window_ms: int = 1000) -> bool:
    key = f"rate_limit:{user_id}"
    now = int(time.time() * 1000)
    return bool(limiter(keys=[key], args=[window_ms, max_qps, now]))

11.5 秒杀 / 限时解锁

SECKILL_SCRIPT = """
local key = KEYS[1]
local user_id = ARGV[1]
local stock = tonumber(redis.call('get', key) or '0')
if stock <= 0 then
    return -1
end
if redis.call('sismember', key .. ':users', user_id) == 1 then
    return 0
end
redis.call('decr', key)
redis.call('sadd', key .. ':users', user_id)
return 1
"""

seckill = r.register_script(SECKILL_SCRIPT)

def try_buy(activity_id: str, user_id: str, total_stock: int) -> int:
    key = f"seckill:{activity_id}:stock"
    r.setnx(key, total_stock)
    return int(seckill(keys=[key], args=[user_id]))

十二、为什么 Redis 不适合做长期存储？

12.1 持久化不是主存储

RDB 会丢数据，AOF 文件大且恢复慢。Redis 的持久化定位是「灾难恢复」，不是「可靠主存」。

12.2 内存成本过高

内存价格是 SSD 的 10-50 倍。IPTV 的媒资、播放记录、订单流水动辄几十 TB，全放 Redis 不现实。

12.3 单线程执行风险

大数据集下，一个 KEYS *、HGETALL 或慢查询可能阻塞整个实例。

12.4 缺乏复杂查询能力

Redis 不支持 SQL、JOIN、二级索引。长期业务数据需要分析统计时，应使用 MySQL / PostgreSQL / ClickHouse。

结论：

Redis 适合「热数据 + 临时状态 + 实时计算」，价值在于速度；长期存储应交给磁盘数据库 + 对象存储。

十三、Redis 容易踩坑的地方

坑	说明	解法
大 Key	String > 10MB，集合元素百万级	拆分、分片、UNLINK 异步删除
热 Key	单个 Key 被高频访问	本地缓存、Key 分片、Cluster
缓存穿透/击穿/雪崩	缓存失效导致 DB 被打挂	布隆过滤器、互斥锁、随机 TTL
未设置 maxmemory	内存打满后写操作报错	设置 maxmemory 和淘汰策略
误用 KEYS	`KEYS *` 扫描全库阻塞主线程	生产禁用，改用 SCAN
Lua 跨 slot	Cluster 下脚本 Key 不在同一 slot	使用 hash tag `{user}:1001:xxx`
事务没有回滚	EXEC 后某命令失败不会撤销前面命令	业务层保证幂等，或用 Lua
主从延迟	读从库可能读到旧数据	对一致性要求高的读走主库

十四、Redis 做消息队列的方法

14.1 List：轻量队列

flowchart LR
    P[Producer] -->|LPUSH queue:transcode task| R[(Redis List)]
    C[Consumer] -->|BRPOP queue:transcode 5| R
    C --> S[执行转码]

r.lpush("queue:transcode", json.dumps({"video_id": "v123"}))
_, task = r.brpop("queue:transcode", timeout=5)

优点：简单、阻塞读。缺点：无 ACK、无多消费者组、无消息回溯。

14.2 Pub/Sub：实时广播

r.publish("live:start", json.dumps({"channel_id": "cctv1"}))

优点：实时、多订阅者。缺点：不持久化，消费者断线期间消息丢失。

14.3 Stream：生产级队列

r.xadd("mq:events", {"event": "video:play", "user_id": "u10086"})

r.xgroup_create("mq:events", "group_log", id="0", mkstream=True)

messages = r.xreadgroup(
    groupname="group_log",
    consumername="worker_1",
    streams={"mq:events": ">"},
    count=10,
    block=5000
)
for stream, entries in messages:
    for msg_id, fields in entries:
        process(fields)
        r.xack("mq:events", "group_log", msg_id)

优点：支持消费者组、ACK、消息回溯。

方式	推荐场景
List	简单任务队列
Pub/Sub	实时广播
Stream	生产级消息队列

十五、总结

《Redis in Action》的核心思想可以概括为一句话：把 Redis 当成内存里的数据结构工具箱，而不是数据库。

Redis 适合：

缓存加速（会话、配置、热点数据）。
实时计算（排行榜、计数器、限流、秒杀）。
异步解耦（List / Pub/Sub / Stream）。

Redis 不适合：

长期持久化存储。
复杂查询与大数据分析。
超大数据集主存储。

避免踩坑的关键是：控制 Key 大小、设置合理 TTL、配置淘汰策略、慎用阻塞命令、理解持久化边界。Redis 用好了是神兵利器，用错了就是生产事故的导火索。

Elasticsearch 从原理到 IPTV 媒资搜索实战：基于 ftmao-meta 项目的完整复盘

Sat, 28 Aug 2021 14:00:00 +0800

Elasticsearch 从原理到 IPTV 媒资搜索实战：基于 ftmao-meta 项目的完整复盘

以我们线上运行的 IPTV 媒资元数据服务 ftmao-meta 为样本，讲清楚一个真实的 ES（实际为 AWS 托管 OpenSearch）应用是怎么设计索引、同步数据、支撑搜索和下游订阅的。所有配置、代码、索引设计均来自项目本身，踩过的坑也一并奉上。

一、项目背景：这是一个什么系统

ftmao-meta 是一个面向多地区运营的 IPTV/OTT 视频内容平台的媒资元数据微服务，Spring Boot 3.3 + Java 21，单模块 Gradle 工程，包结构 gtt.ftmao.meta，分 api / app / bean / core 四层。它管理的数据包括：

影视元数据：电影、剧集、季、集、短视频的多语言标题、简介、海报、演职员、分级、票房；
演职人员：多语言姓名、热度值（pgcHot / ugcHot / imdbHot）、代表作；
物料：剧照海报（artwork）、预告片（trailer）；
C 端搜索：全文检索 + 输入自动补全。

这些数据量巨大（千万级文档）、多语言（英语/西语/葡语，服务拉美市场）、多租户（多家运营商公司共用），而且需要被下游多个服务增量订阅。MySQL 是事实源（Source of Truth），ES 承担所有读路径的检索。

技术选型上的关键事实：

后端是 AWS 托管 OpenSearch，客户端用官方 opensearch-java 2.8.1（org.opensearch.client.opensearch.OpenSearchClient），没有用 spring-data-elasticsearch，也没有 RestHighLevelClient；
全文检索与自动补全能力封装在公司内部库 searchengine-api/core/sync 里，业务代码只调用 SearchApi / SearchSync 门面；
数据同步不走 MQ（Kafka 依赖在启动类里被显式排除），而是"MySQL 任务表 + 定时轮询 + 分布式锁"。

graph TB
    subgraph 上游["上游数据来源"]
        BOSS["运营后台 / 内容录入"]
        PP["PP 开放平台<br/>（REST 拉取外部媒资）"]
    end

    subgraph META["ftmao-meta 服务"]
        API["REST API 层"]
        SVC["业务 Service<br/>MetaService / ArtworkService ..."]
        JOB["定时 Job<br/>PpMetaSyncJob 每 15s"]
        LOCK["分布式锁<br/>AsyncJobExecutorManager"]
    end

    subgraph STORE["存储层"]
        MYSQL[("MySQL<br/>事实源 + 同步任务表")]
        subgraph OS["AWS OpenSearch"]
            DETAIL["meta_detail_index<br/>媒资详情（重索引）"]
            PERSON["meta_person_index<br/>人物详情"]
            ART["meta_artwork_index<br/>剧照物料"]
            TRAILER["meta_trailer_index<br/>预告片"]
            SEARCH["search_engine_index<br/>C端搜索（轻索引）"]
        end
    end

    subgraph DOWN["下游消费方"]
        PORTAL["门户/推荐服务"]
        SUB["增量订阅方<br/>（时间水位拉取变更）"]
    end

    BOSS --> SVC
    PP --> JOB
    SVC -->|"事务内：先写库，再直写 ES"| MYSQL
    SVC --> DETAIL
    SVC --> SEARCH
    JOB --> LOCK --> MYSQL
    JOB -->|"批量灌入"| SEARCH
    API -->|"全文搜索/补全"| SEARCH
    API -->|"mget 回查详情"| DETAIL
    API --> PERSON & ART & TRAILER
    DETAIL -->|"lastModifiedIndicator 水位"| SUB
    SEARCH --> PORTAL

二、先补原理：理解后面设计决策的三个支点

在进入项目细节前，用三句话回顾《Elasticsearch in Action》里最重要的原理，后面每个设计决策都会用到它们。

2.1 倒排索引与分词

ES 搜索快的根本原因是倒排索引：term → 文档列表。而文本进入倒排索引前要经过分析链：

graph LR
    A["原始文本<br/>O Auto da Compadecida"] --> B["Character Filter<br/>变音符号映射 á→a"]
    B --> C["Tokenizer<br/>standard 分词"]
    C --> D["Token Filter<br/>lowercase + stopword + stemmer"]
    D --> E["词项 Term<br/>auto / compadecida"]

一个字段建索引时用哪个 analyzer、搜索时用哪个 analyzer，直接决定了"搜不搜得到"。这就是为什么 mapping 必须在灌数据之前设计好——改 analyzer 意味着重建索引。

2.2 近实时（NRT）与 refresh

文档写入后先进内存缓冲区，默认 1 秒后 refresh 生成 segment 才可被搜索。批量灌数据时调大 refresh_interval、或显式控制 refresh 时机，是写入性能优化的第一手段——后面会看到项目里批量写入怎么用它。

2.3 Query 与 Filter 的区别

Query：算相关性得分 _score，用于全文匹配排序；
Filter：只判断 yes/no，不算分、结果可被缓存，用于精确过滤。

项目里几乎所有查询都是"filter 套 query"的 bool 结构：关键词进 must，租户、类型、软删除标记进 filter。

三、索引设计：一个搜索索引 + 四个详情索引

3.1 索引清单

项目中没有任何 @Document 注解或 mapping JSON 文件，索引 DDL 采用类似 Liquibase 的 changelog 形式管理（changelog/elasticsearch/*.yaml，HTTP method + path + body，由外部部署工具执行），别名字段统一管理：

代码中的别名	实体索引	分片	存什么
`meta_detail_index`	`ftmao-meta-detail-1`	6 主 2 副	媒资详情全集
`meta_person_index`	`ftmao-meta-person-detail`	6 主 2 副	演职人员详情
`meta_artwork_index`	`ftmao-meta-media-artwork`	6 主 2 副	剧照物料
`meta_trailer_index`	`ftmao-meta-media-trailer`	6 主 2 副	预告片
`search_engine_index`	`ftmao-meta-search-engine`	1 分片	C 端搜索/补全

别名与文档类的映射集中在一个枚举里（OpenSearchIndexEnum），业务代码只认别名——这是"换索引不改代码"的基本功，比如 ftmao-meta-detail-1 后面出现 -2，只需要 reindex 后切别名。

3.2 详情索引：重存储、轻检索

meta_detail_index 的 mapping 有个鲜明特征：几乎所有字段都是 keyword，标题、剧情简介都是 keyword + nested，不参与分词检索，大量 nested 对象（displayTitles / plots / posters / casts）配 dynamic: false。

为什么？因为详情索引的职责是**“按 ID/结构化条件精确取数”**，不是全文搜索。keyword 不做分词，聚合、terms 过滤、精确匹配都快；dynamic: false 防止上游数据乱塞字段把 mapping 撑爆（mapping explosion 是生产事故常客）。

3.3 搜索索引：整个项目最精彩的部分

search_engine_index 只有 1 个分片（轻量、追求查询 RT），但它的 analysis 配置是整个项目技术含量最高的地方。以主搜索字段 mainTitle 为例：

# 摘自 changelog（简化）
mainTitle:
  type: text
  store: true
  term_vector: with_positions_offsets   # 为 fast-vector-highlighter 高亮做准备
  analyzer: en_es_pt                     # 英/西/葡三语混合分词器
  fields:
    cut_word:    { analyzer: en_es_pt }              # 正常分词匹配
    all_letters: { analyzer: N_gram(4-15) }          # 长 ngram：前缀/模糊匹配
    word_letters:{ analyzer: N_gram(2-10) }          # 短 ngram：更激进的模糊匹配
    origin:      { type: keyword, normalizer: lowercase }  # 精确匹配/排序

配套自定义组件：

多语分析器 en_es_pt：standard tokenizer + 英语/西语/葡语三套 stopword + stemmer；
变音符号 char_filter：把 áéíóúàèç 等西葡变音符号映射为 ASCII——拉美用户搜 compadecida 也能命中 Compadecida，对多语言市场这是体验生死线；
ngram tokenizer 一批（1–10、4–15 等不同窗口），max_ngram_diff=14；
completion suggester：suggest 字段配 suggester_trigram 分析器，带 3 个 category context（markCate / tenantCate / comboCate）——自动补全可以按内容类型和租户隔离，A 运营商的用户不会看到 B 运营商专有的片名提示。

设计启示：一个"能搜"的字段，实际需要四层子字段分工——正常分词管召回、长 ngram 管前缀联想、短 ngram 管纠错、keyword 管精确和排序。这也正是《Elasticsearch in Action》里"多字段映射"思想的生产级演绎。

3.4 双索引架构：为什么搜索和详情要分开

graph LR
    subgraph 写入["写入侧"]
        D["MetaDetail 完整文档<br/>（几十 KB，含 nested 海报/演员/多语言）"] --> DETAIL["详情索引<br/>6分片 重存储"]
        D -->|"裁剪：docId + mainTitle +<br/>suggest + 过滤字段 + 租户"| SEARCH["搜索索引<br/>1分片 轻量"]
    end
    subgraph 查询["查询侧"]
        U["用户搜索 'auto'"] -->|"① matchSearch 命中<br/>返回 docId 列表"| SEARCH
        SEARCH -->|"② 按 docId mget"| DETAIL
        DETAIL -->|"组装完整详情返回"| U
    end

搜索索引里不存详情，只有：docId、mainTitle（及 ngram 子字段）、suggest、40+ 个 keyword 过滤字段（ext-field-to-index-map 里配置，如媒资类型、地区、年份、分级）、租户字段。好处有三个：

搜索索引小，1 个分片 + 内存友好，C 端 QPS 扛得住；
详情变更不用动搜索索引——海报换了只 update 详情索引；搜索索引只在标题/过滤字段变化时更新；
两类索引可以独立扩缩容、独立重建。

代价也很明显：多一次 mget 回查、数据一致性要维护两份。这个项目用下一节的同步机制来兜底。

四、数据同步：MySQL → ES 的三条路径

ES 是"读模型"，MySQL 才是事实源。项目没用 Canal/MQ，而是自己实现了一套事务内直写 + 任务表轮询的混合方案：

flowchart TD
    A["业务写请求<br/>MetaService.save()"] --> B{"@Transactional"}
    B --> C["① 写 MySQL 业务表"]
    B --> D["② 写 MySQL 同步任务表<br/>MixedMetaSyncTask"]
    B --> E["③ 同事务内直写详情索引<br/>bulkOperationByBatch(refresh=True)"]
    B --> F["④ saveMetaToSearchEngine<br/>同步搜索索引"]
    E --> G{"ES 写失败?"}
    G -->|"是，事务回滚或留下任务"| H["任务表残留记录"]
    D --> I["PpMetaSyncJob<br/>@Scheduled 每 15s"]
    H --> I
    I --> J["分布式锁<br/>executeWithLock"]
    J --> K["MetaTaskProcessService<br/>分批 Lists.partition(batchSize)"]
    K -->|"searchSync.save(batch)"| L["搜索索引"]
    M["失败重试 Job<br/>每小时"] --> J

三条路径各有分工：

同事务直写（主路径）：保证"后台保存完，前台立刻能搜到"。写入时统一刷新 updateTime 和 lastModifiedIndicator（格式：时间戳_docId 的版本游标，下一节详述）；
任务表 + 定时轮询（兜底路径）：15 秒一轮，分布式锁防多实例并发，分批灌入；
失败重试 Job（保险）：每小时扫描失败任务重放。

为什么不纯用 MQ？ 这个系统的写入量级不大（媒资是低频高价值数据，不是日志），事务内直写的一致性收益远大于引入 MQ 的复杂度。这是"按场景选方案"而不是"按潮流选方案"的好例子。

4.1 批量写入的性能细节

工具类 OpenSearchUtil.bulkUpsertDocuments 里有两个值得抄的实践：

// 按配置的 bulkSize（默认 200）分批，避免单个 bulk 过大压垮集群
// 每批显式 refresh(WaitFor)：写完后“等 refresh 完成再返回”，
// 保证同步接口的调用方“写完立即可见”，同时比 refresh=true（每文档刷新）省资源

对照第 2.2 节的 NRT 原理：refresh=WaitFor 是吞吐和可见性之间的甜点——批量场景不要无脑 refresh=true。

五、查询实战：从业务代码反推 ES 用法

5.1 一切查询的起点：软删除过滤

项目里文档不物理删除，而是软删除——所有读路径都要叠一层 isDeleted=0：

// OpenSearchUtil.getUndeletedQuery：所有查询都要过这层包装
Query undeletedQuery = openSearchUtil.getUndeletedQuery(boolQueryBuilder.build()._toQuery());
// 底层就是 bool.filter(terms(isDeleted, [0]))，可能再叠加 status=1（已发布）

业务侧的典型用法（ArtworkService，按媒资 ID 查剧照）：

Query metaIdQuery = Query.of(q -> q.terms(t -> t.field("metaId")
    .terms(tv -> tv.value(Stream.of(request.getMetaId())
        .map(FieldValue::of).toList()))));
boolQueryBuilder.filter(metaIdQuery);
Query undeletedQuery = openSearchUtil.getUndeletedQuery(boolQueryBuilder.build()._toQuery());
SortOptions sortOption = SortOptions.of(s -> s.field(
    f -> f.field("pos").order(SortOrder.Asc)));
List<MediaArtwork> artworks = openSearchUtil.searchDoc(
    OpenSearchIndexEnum.MEDIA_ARTWORK.getIndexName(),
    undeletedQuery, MediaArtwork.class,
    request.getPageId(), request.getPageSize(),
    Collections.singletonList(sortOption), totalCount);

这正是第 2.3 节"filter 不算分、可缓存"原理的落地：结构化条件全部进 filter。

5.2 软删除的实现：updateByQuery + Painless 脚本

删除不是 delete，而是 updateByQuery 打标记：

String script = " ctx._source.isDeleted = 1;"
      + "ctx._source.updateTime = params.currentTime;"
      + "ctx._source.lastModifiedIndicator = params.indicatorPrefix + '_' + ctx._id";
UpdateByQueryRequest request = new UpdateByQueryRequest.Builder()
    .index(indexName).query(query)
    .script(s -> s.inline(i -> i.source(finalScript)
        .params("currentTime", JsonData.of(currentTime))
        .params("indicatorPrefix", JsonData.of(String.valueOf(modifyTime)))))
    .build();

注意脚本里同时更新了 lastModifiedIndicator——软删除也是一次"变更"，必须让下游订阅方感知到（下游才能同步删）。这个细节是订阅体系能闭环的关键。

5.3 两阶段全文搜索

C 端搜索入口 SearchService.searchMedia 的分流逻辑：

if (StringUtils.isNotEmpty(fuzzyMatchingParams.getKeyword())) {
    // 有关键词：内部库全文检索 → 返回 docId + mark（类型）
    resp = searchApi.matchSearch(keyword, marks, pageId, pageSize, tenantIds, params);
} else {
    // 无关键词：纯结构化筛选（找片页、分类浏览）
    resp = searchApi.find(marks, pageId, pageSize, tenantIds, params);
}
// 按 mark 分流 person / meta，回查详情索引取完整数据
openSearchUtil.batchGetDocuments(PERSON_DETAIL.getIndexName(), personDocIds, PersonDetail.class);
openSearchUtil.batchGetDocuments(META_DETAIL.getIndexName(), metaDocIds, MetaDetail.class);

查询条件从哪来？API 层收的是 SQL 风格的 where 模板（MetaQuery.whereTemplate + parameters），WhereClauseUtil 用正则把 in (:x)、between and、JSON_CONTAINS_ALL/ANY 解析成 ES 的 Condition（IN / GREATER_THAN 等），字段名经 FieldNameMappingEnum 做外部名→索引字段名映射。

这个设计的好处：对前端/上游服务来说，查询语法是稳定的数据库风格，不暴露 ES DSL；ES mapping 改名、换引擎，外部无感。

5.4 自动补全：completion suggester + 租户隔离

// SearchService.suggest
List<Prompt> prompts = searchApi.getPromptList(keyword, marks, true, companyId, size, uuid);
// 底层 = 搜索索引 suggest 字段的 completion suggester，
// context 里带 tenantCate=companyId → 补全结果按运营商隔离
// 拿到 docId 后再回查详情索引组装标题和海报

举例如"用户输入 int"：

sequenceDiagram
    participant U as 用户(运营商A)
    participant S as SearchService
    participant SE as 搜索索引 suggester
    participant D as 详情索引
    U->>S: suggest("int", companyId=A)
    S->>SE: completion suggest<br/>context: tenantCate=A
    SE-->>S: ["Interestelar", "Intocáveis"]<br/>+ docId 列表
    S->>D: mget(docIds)
    D-->>S: 标题 + 海报 URL
    S-->>U: 补全列表（带封面）

5.5 一个常被忽略的性能点：只取 ID 就别加载 _source

// fastGetDocumentById：判断文档存在/取 ID 时
// storedFields("_id") + size(1) + trackTotalHits(false)
// 注释原话：类似 MySQL 的 LIMIT 1

trackTotalHits(false)：不精确统计总数（默认只算到 10000），省掉一次全量计数；
storedFields("_id")：不加载 _source，网络传输量从几十 KB 降到几十 B。

列表页"先查 ID 再回查"的场景，这两招能把响应时间砍掉一个量级。

六、增量订阅：ES 作为"变更数据源"

下游服务（推荐、缓存、其他中台）需要感知媒资变更。项目没有用 CDC 或 MQ 广播，而是让下游基于水位游标主动拉取 ES：

sequenceDiagram
    participant SUB as 下游订阅方
    participant Q as SubqueryService
    participant ES as 详情索引

    Note over SUB: 记录上次水位 W0<br/>（lastModifiedIndicator 字符串）
    SUB->>Q: querySubQuery(from=W0, size=500)
    Q->>ES: range(lastModifiedIndicator: gt W0, lt 当前时间-2s)<br/>+ 按 lastModifiedIndicator 升序
    ES-->>Q: 本批变更文档（含软删除的）
    Q-->>SUB: 文档 + 新水位 W1
    SUB->>SUB: 落库/更新缓存，记录 W1
    Note over Q,ES: 对账：subQueryCount 用 count + sort desc + size(1)<br/>取区间最大水位，生产方/消费方核对数量

几个工程细节值得细说：

水位是字符串而非时间戳：lastModifiedIndicator = 时间戳 + "_" + docId。纯时间戳会在同一毫秒内有多个文档时漏数；拼上 docId 后字典序唯一，range gt 翻页不会漏、不会重。这是项目用手写游标替代 search_after 的原因——行为完全可控，且不依赖 ES 的 PIT（point in time）上下文。
lt 当前时间 - 2s 的回调偏移：规避"刚写入还没 refresh 可见"的窗口（第 2.2 节 NRT 原理的直接应用），宁可晚 2 秒，不可漏数据。
软删除文档也带着新水位出现，下游据此删除本地副本——和第 5.2 节的脚本闭环。

七、多租户设计：docId 里藏着租户

// OpenSearchUtil.getDocId：文档 ID = companyId + "#" + metaId
// 例："1001#mv_8848123"、"public#mv_8848123"（公共库）

同一部影片，A 运营商和 B 运营商是两份文档（各自的标题、定价、上架状态可能不同），天然物理隔离；
sourceType 字段区分 PRIVATE（私有）/ PUBLIC（公共）/ MIXED（混合），公共内容用 public# 前缀，查询时按租户策略合并；
所有查询 filter 里都带 companyId / tenant_id，补全用 context 隔离（第 5.4 节）。

经验：多租户搜索系统，把租户编进 docId 比单纯加过滤字段更稳——docId 冲突本身就是一道防串租户的保险。

八、回到原理：这个项目验证了哪些书里的论断

书中原理	项目里的体现
Mapping 先行，改 analyzer 要重建索引	索引 DDL 用 changelog 版本化管理，上线流程化
Filter 不算分、可缓存	租户/类型/软删除/状态全部进 filter，只有关键词算分
多字段映射解决"一个字段多种搜法"	mainTitle 四层子字段：分词/长ngram/短ngram/keyword
NRT 的 refresh 是性能旋钮	批量写入用 `refresh=WaitFor`；订阅端留 2s 偏移
深度翻页要避免 from+size 深分页	手写 `lastModifiedIndicator` 游标替代 search_after
聚合昂贵，慎用	项目几乎零聚合；取最大值用 sort+size(1) 替代 max agg
分片数创建时定死，规划要前置	详情索引 6 分片按数据增长预估；搜索索引刻意 1 分片

九、总结

如果把这套架构压缩成一张图：

graph LR
    W["写路径<br/>MySQL 事务<br/>+ 任务表兜底"] --> ES
    subgraph ES["OpenSearch"]
        S["搜索索引<br/>小而快：ngram+suggester<br/>+租户 context"]
        D["详情索引<br/>大而全：keyword+nested<br/>dynamic:false"]
    end
    ES --> R1["读路径 ①<br/>搜索/补全 → docId"]
    R1 --> R2["读路径 ②<br/>mget 详情组装"]
    ES --> R3["订阅路径<br/>水位游标增量拉取"]

三条核心经验：

索引按"查询模式"而不是"数据表"来设计：搜索索引和详情索引分开，一个为召回优化（ngram、suggester、多语分析器），一个为取数优化（keyword、nested、禁动态字段）；
一致性靠机制不靠运气：事务内直写是主路径，任务表 + 定时 Job + 失败重试是兜底，水位游标让下游最终一致——三层防护各管一段；
所有"黑科技"都是基本原理的应用：refresh 偏移、filter 缓存、storedFields 取 ID、游标翻页……吃透《Elasticsearch in Action》那套原理，生产方案都是它的排列组合。

参考资料：Radu Gheorghe, Matthew Lee Hinman, Roy Russo. 《Elasticsearch in Action》. Manning Publications, 2015；ftmao-meta 项目源码（OpenSearchConfig / OpenSearchUtil / SearchService / SubqueryService / changelog/elasticsearch）。

MySQL 实战笔记：安装、事务、索引、锁与高性能优化

Thu, 28 Nov 2019 14:00:00 +0800

MySQL 实战笔记：安装、事务、索引、锁与高性能优化

MySQL 是互联网业务中使用最广泛的关系型数据库之一。掌握它不能只停留在“会写 CRUD”，还要理解事务隔离、索引结构、锁机制以及高性能架构设计。本文从实战出发，结合常见坑点与优化建议，帮你建立系统性的 MySQL 知识地图。

一、高层次思想：MySQL 在解决什么问题？

关系型数据库的核心价值可以概括为三句话：

持久化：让数据安全地落在磁盘上，程序重启不丢失。
一致性：通过事务与约束，保证数据始终符合业务规则。
高效访问：通过索引、缓存、分区分表等手段，在海量数据中快速读写。

graph TD
    A[业务应用] -->|SQL| B[MySQL Server]
    B --> C[SQL 解析 / 优化]
    C --> D[执行引擎]
    D --> E[存储引擎 InnoDB/MyISAM]
    E --> F[Buffer Pool 缓存]
    E --> G[Redo / Undo Log]
    E --> H[磁盘数据文件]

1.1 MySQL 架构分层

graph LR
    A[连接层] --> B[服务层]
    B --> C[存储引擎层]
    B --> D[查询缓存 / 解析器 / 优化器]
    C --> E[InnoDB 支持事务/行锁]
    C --> F[MyISAM 高速查询/表锁]

层级	职责
连接层	管理客户端连接、权限验证
服务层	SQL 解析、优化、执行
存储引擎层	负责数据的存储与读取

1.2 Buffer Pool：InnoDB 的内存缓存

Buffer Pool 是 InnoDB 在内存中开辟的一块区域，用来缓存数据页和索引页。它是 MySQL 性能的核心，绝大多数读写操作都先发生在 Buffer Pool 中。

为什么需要 Buffer Pool？

磁盘的读写速度比内存慢几个数量级。如果每次查询都读磁盘，性能会极差。Buffer Pool 把热数据放在内存里，大幅减少磁盘 I/O。

Buffer Pool 的工作流程：

sequenceDiagram
    participant App as 应用
    participant BP as Buffer Pool
    participant Disk as 磁盘

    App->>BP: 查询 id=1
    BP-->>App: 命中，直接返回
    Note over BP: 数据页已在内存

    App->>BP: 查询 id=2
    BP->>Disk: 未命中，从磁盘加载
    Disk-->>BP: 返回数据页
    BP-->>App: 返回数据

写数据时的流程：

先把数据页读到 Buffer Pool（如果不在）。
在 Buffer Pool 中修改数据页，此时这个页变成脏页（Dirty Page）。
写 Redo Log（WAL）。
返回成功给应用。
后台线程（Page Cleaner）异步把脏页刷回磁盘。

Buffer Pool 的内部结构：

结构	作用
LRU 链表	管理数据页的使用热度，最近最少使用的页被淘汰
Free 链表	管理空闲页
Flush 链表	管理脏页，等待后台刷盘
Change Buffer	缓存二级索引的修改，减少随机 I/O
Adaptive Hash Index	自动为热点数据页建立哈希索引，加速查找

注意：脏页是异步刷盘的，所以提交成功不代表数据页已经落盘。InnoDB 通过 Redo Log 保证即使崩溃也能恢复。

二、安装、启动与基础配置

2.1 启动 MySQL 服务

# Windows
net start MySQL

# Linux/macOS
sudo systemctl start mysql

2.2 修改 root 密码

ALTER user 'root'@'localhost' IDENTIFIED BY 'root';

2.3 创建数据库时务必指定编码

CREATE DATABASE `test` /*!40100 COLLATE 'utf8mb4_bin' */;

避坑指南 #1：默认的 utf8 在 MySQL 中其实是阉割版（最多 3 字节），无法存储 Emoji 等 4 字节字符。生产环境请统一使用 utf8mb4。

2.4 JDBC 连接串必须带编码与时区

jdbc:mysql://127.0.0.1:3306/crmeb_java?serverTimeZone=UTC&useUnicode=true&characterEncoding=utf8

MySQL 8 推荐写法：

jdbc:mysql://127.0.0.1:3306/db_name?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=utf8mb4

避坑指南 #2：MySQL 8 默认启用 SSL，但旧版驱动连接时可能报错，可显式设置 useSSL=false（内网环境）。时区必须指定，否则会出现时间差 8 小时的问题。

2.5 开启通用查询日志

SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/tmp/mysql.log';
SHOW VARIABLES LIKE "general_log%";

避坑指南 #3：通用日志会记录所有 SQL，性能开销极大。仅用于临时排查问题，生产环境不要长期开启。

三、存储过程：谨慎使用

存储过程（Stored Procedure）是把一组 SQL 语句预编译后存储在数据库内部，通过 CALL 调用的程序单元。它能减少网络往返、封装固定逻辑，但在现代工程实践中已不再被推荐作为首选方案。

为什么不推荐重度使用存储过程？

问题	说明
调试困难	缺乏现代 IDE 的断点、单步调试和日志追踪能力，定位问题成本高。
版本控制弱	存储过程游离在应用代码仓库之外，难以做 Code Review 和版本回滚。
迁移成本高	不同数据库（MySQL、Oracle、SQL Server、PostgreSQL）的存储过程语法差异大，换库时重写代价大。
测试困难	不易做单元测试、集成测试，CI/CD 流程中难以保证质量。
与微服务理念冲突	业务逻辑下沉到数据库，导致数据库成为“另一个服务边界”，增加耦合。

适合使用存储过程的场景

数据迁移与 ETL：一次性、数据库内部的数据清洗、转换任务。
简单的批量操作：例如按固定规则批量归档历史数据。
强依赖数据库原子性的脚本：需要利用数据库事务保证一致性的短时脚本。

更推荐的替代方案

graph LR
    A[复杂业务逻辑] --> B[应用层 / Service 层实现]
    A --> C[ORM / MyBatis 等持久层框架]
    B --> D[便于测试、调试、版本控制]
    C --> D

应用层处理：把复杂逻辑放在 Java/Go/Python 等服务层，配合事务注解保证一致性。
批量 SQL：使用 INSERT ... SELECT 或 LOAD DATA 完成批量导入。
定时任务：使用调度框架（如 Quartz、XXL-JOB）替代存储过程做周期化数据处理。

避坑指南 #4：存储过程调试困难、不利于迁移，现代微服务架构中建议慎用。批量数据处理优先考虑在应用层分批插入，或使用 INSERT ... SELECT。

四、事务：ACID 与隔离级别

4.1 事务的 ACID 特性

graph TD
    A[事务] --> B[Atomicity 原子性]
    A --> C[Consistency 一致性]
    A --> D[Isolation 隔离性]
    A --> E[Durability 持久性]
    B --> F[Undo Log]
    E --> G[Redo Log]

特性	含义	MySQL 实现
原子性	要么全成功，要么全回滚	Undo Log
一致性	事务前后数据满足约束	约束 + 触发器 + 业务校验
隔离性	并发事务互不干扰	锁 + MVCC
持久性	提交后数据不丢失	Redo Log

4.2 Undo Log 与 Redo Log

4.2.1 Redo Log：崩溃恢复与“何时返回成功”

InnoDB 使用 WAL（Write-Ahead Logging） 保证持久性：事务提交前先把修改写到 Redo Log，真正的脏页可以延迟异步刷回磁盘。核心流程如下：

sequenceDiagram
    participant App as 应用/客户端
    participant MySQL as MySQL Server
    participant BP as Buffer Pool
    participant Redo as Redo Log Buffer / 文件
    participant Disk as 磁盘数据文件

    App->>MySQL: BEGIN
    App->>MySQL: UPDATE user SET age=20 WHERE id=1
    MySQL->>BP: 读取数据页并修改 age=20
    MySQL->>Redo: 写入 Redo Log：<br/>"将 id=1 的 age 改为 20"
    Note over Redo: WAL：先写日志，再写磁盘
    App->>MySQL: COMMIT
    MySQL->>Redo: 按策略刷新 Redo Log
    MySQL-->>App: 返回 Commit 成功
    Note over BP,Disk: 脏页由后台线程异步刷盘

Redo 写完后，MySQL 才告诉应用写完成了吗？

答案是：默认配置（innodb_flush_log_at_trx_commit = 1）下，是的。 MySQL 把 Redo Log fsync 到磁盘后，才会返回 COMMIT 成功。

参数值	提交时的行为	持久性	典型场景
1（默认）	每次提交都 `fsync` 刷盘	最高，提交即持久	生产默认，强一致业务
2	写到 OS Page Cache，每秒刷盘	可能丢失 1 秒内数据	追求性能，可容忍少量丢失
0	由后台线程每秒刷一次	最低，进程崩溃可能丢 1 秒	极少使用

关键结论：默认情况下，应用收到 COMMIT 成功，就意味着对应事务的 Redo Log 已经持久化到磁盘。此后即使 MySQL 立刻崩溃，重启时也能根据 Redo Log 恢复这条已提交事务；如果崩溃发生在 fsync 之前，则该事务会被回滚或视为未提交。

崩溃恢复流程：

flowchart TD
    A[MySQL 崩溃后重启] --> B[加载磁盘 Redo Log]
    B --> C[找到上一次 Checkpoint LSN]
    C --> D[扫描 Checkpoint 之后的 Redo 记录]
    D --> E{Redo 记录对应页<br/>是否需要重放?}
    E -->|Redo LSN > 页 LSN| F[重放该条 Redo]
    F --> G[恢复已提交事务的修改]
    E -->|已落盘，无需重放| H[跳过]
    G --> I[恢复完成，数据库可用]
    H --> I
    J[崩溃时 Redo 尚未 fsync] --> K[事务视为未提交<br/>不会恢复]

注意：Redo Log 是物理逻辑日志，恢复时按 LSN 顺序重放。InnoDB 会对比 Redo 记录与数据页上的 LSN，避免对已经落盘的页重复应用，保证幂等性。

4.2.2 Undo Log：回滚是如何实现的？

Redo 记录“新值”用于崩溃后重做；Undo 记录“旧值”用于事务回滚和 MVCC。

Undo Log 回滚流程：

flowchart TD
    A[事务开始 BEGIN] --> B[执行 UPDATE / DELETE]
    B --> C[生成 Undo Log<br/>记录修改前的旧值]
    C --> D[修改 Buffer Pool 数据页]
    D --> E{事务结果}
    E -->|ROLLBACK| F[读取本事务的 Undo Log]
    F --> G[用旧值覆盖 Buffer Pool 中的修改]
    G --> H[释放事务持有的锁]
    H --> I[事务结束，修改被撤销]
    E -->|COMMIT| J[Redo Log 持久化后提交]
    J --> K[Undo Log 标记为可清理]
    K --> L[Purge 线程异步回收]
    L --> M[事务结束]

Undo Log 的两个核心作用：

事务回滚：ROLLBACK 或语句失败时，InnoDB 沿着 Undo Log 把修改逐项撤销，恢复数据到事务开始前的状态，保证原子性。
MVCC 一致性读：RR/RC 级别下，普通 SELECT 不加锁，而是通过 Undo Log 链构造事务开始时可见的数据版本（ReadView），实现无锁并发读。

注意：Undo Log 的修改本身也受到 Redo Log 保护。崩溃恢复时，Undo Log 页也会通过 Redo Log 重建，否则回滚能力会丢失。

注意：事务提交后，Undo Log 不会立即删除。如果其他事务还需要用它构造快照，Undo Log 会继续保留，直到没有事务依赖该旧版本后，Purge 线程才会回收。长事务会导致 Undo 堆积、表空间膨胀。

4.3 事务的并发问题

问题	描述
脏读	事务 A 读到事务 B 未提交的数据，B 回滚后 A 读到的是脏数据
不可重复读	事务 A 多次读取同一行，事务 B 修改并提交，导致 A 两次结果不同
幻读	事务 A 按条件查询一批数据，事务 B 新增/删除满足条件的数据，导致 A 再次查询时结果集不同

避坑指南 #5：不可重复读侧重“修改”，幻读侧重“新增或删除”。InnoDB 默认的可重复读通过 MVCC + 间隙锁（Gap Lock）在很大程度上解决了幻读。

4.4 四种隔离级别

graph LR
    A[读未提交<br>Read Uncommitted] --> B[读已提交<br>Read Committed]
    B --> C[可重复读<br>Repeatable Read]
    C --> D[串行化<br>Serializable]
    style C fill:#e1f5e1

隔离级别	脏读	不可重复读	幻读	说明
读未提交（RU）	是	是	是	基本不使用
读已提交（RC）	否	是	是	Oracle / SQL Server 默认
可重复读（RR）	否	否	否*	MySQL 默认，InnoDB 通过 MVCC + Gap Lock 解决幻读
串行化（S）	否	否	否	性能最差，完全串行

避坑指南 #6：MySQL 默认是可重复读（RR），但很多互联网项目会改为读已提交（RC），因为 RC 锁粒度更小、并发更高。但改为 RC 后，需要业务层自行处理不可重复读问题。

五、索引类型

索引是 MySQL 高性能的基石。理解索引类型与适用场景，比单纯记住语法更重要。

graph TD
    A[MySQL 索引] --> B[普通索引]
    A --> C[唯一索引]
    A --> D[主键索引]
    A --> E[组合索引]
    A --> F[全文索引]
    D --> G[聚簇索引：数据与索引在一起]
    B --> H[二级索引：叶子节点存主键]

5.1 普通索引

CREATE INDEX index_name ON table(column(length));

5.2 唯一索引

CREATE UNIQUE INDEX indexName ON table(column(length));

5.3 主键索引

主键索引是一种特殊的唯一索引，一张表只能有一个主键，且不允许为空。

5.4 组合索引

CREATE INDEX idx_name_age ON user(name, age);

避坑指南 #7：组合索引遵循最左前缀原则。idx_name_age 对 name、name+age 有效，但对单独 age 无效。

5.5 全文索引

适用于 LIKE '%关键词%' 场景，MyISAM 和 InnoDB 5.6+ 都支持。

六、锁机制与 MVCC

6.1 共享锁与排他锁

锁类型	英文	读/写	兼容性
共享锁	S Lock / 读锁	`SELECT ... LOCK IN SHARE MODE`	读读兼容，读写互斥
排他锁	X Lock / 写锁	`SELECT ... FOR UPDATE` / 增删改	与任何锁都互斥

graph LR
    A[共享锁 S] -- 兼容 --> B[共享锁 S]
    A -- 互斥 --> C[排他锁 X]
    C -- 互斥 --> D[排他锁 X]

避坑指南 #8：只有 INSERT / UPDATE / DELETE 会自动加排他锁；普通 SELECT 不加锁。如果需要保证读取的是最新已提交数据并防止被修改，应显式使用 SELECT ... FOR UPDATE。

6.2 MVCC 实现可重复读

sequenceDiagram
    participant T1 as 事务 A
    participant DB as InnoDB
    participant T2 as 事务 B

    T1->>DB: START TRANSACTION<br>创建 ReadView
    T2->>DB: UPDATE row SET x=2<br>并提交
    T1->>DB: SELECT x<br>仍读取快照中的 x=1
    Note over T1,DB: 事务 A 始终使用开始时的 ReadView

MVCC 不是复制一份数据，而是通过 ReadView + 数据行隐藏字段 + Undo Log 版本链，来判断当前事务应该看到哪个版本的数据。

6.2.1 数据行的两个隐藏字段

InnoDB 每行数据都有两个隐藏字段：

DB_TRX_ID：最后修改这行的事务 ID。
DB_ROLL_PTR：回滚指针，指向这行数据在 Undo Log 中的上一个版本。

6.2.2 ReadView 里面有什么？

ReadView 是一个轻量的结构，不保存任何实际数据，只保存生成时刻的事务状态：

字段	含义
`m_ids`	生成 ReadView 时，所有未提交事务的 ID 列表
`min_trx_id`	`m_ids` 中的最小事务 ID
`max_trx_id`	生成 ReadView 时，系统下一个要分配的事务 ID
`creator_trx_id`	创建该 ReadView 的事务自身 ID

6.2.3 可见性判断算法

对于查询到的一行数据，取出它的 DB_TRX_ID，按以下规则判断：

DB_TRX_ID == creator_trx_id：当前事务自己修改的，可见。
DB_TRX_ID < min_trx_id：在 ReadView 创建前已提交，可见。
DB_TRX_ID >= max_trx_id：在 ReadView 创建后才启动的事务修改的，不可见。
min_trx_id <= DB_TRX_ID < max_trx_id：
- DB_TRX_ID 在 m_ids 列表中 → 事务未提交，不可见。
- DB_TRX_ID 不在 m_ids 列表中 → 事务已提交，可见。

如果当前版本不可见，就沿着 DB_ROLL_PTR 到 Undo Log 链中找上一个版本，重复判断，直到找到可见版本。

flowchart TD
    A[SELECT 读取一行] --> B[获取 DB_TRX_ID]
    B --> C{可见性判断}
    C -->|可见| D[返回当前版本]
    C -->|不可见| E[沿 DB_ROLL_PTR 读 Undo Log 上一个版本]
    E --> C

6.2.4 一个具体例子

假设 id=1 的行初始值为 x=1，事务时间线如下：

时间	事务 10	事务 20	事务 30（查询）
T1	开始
T2		开始
T3	更新 x=2，未提交
T4		更新 x=3，未提交
T5			开始，SELECT x

事务 30 生成的 ReadView：

m_ids = [10, 20]
min_trx_id = 10
max_trx_id = 31
creator_trx_id = 30

查询时，当前行最新版本的 DB_TRX_ID = 20：

20 在 m_ids 中 → 未提交 → 不可见。
沿 Undo Log 找到上一个版本，DB_TRX_ID = 10。
10 在 m_ids 中 → 未提交 → 不可见。
再沿 Undo Log 找到初始版本，DB_TRX_ID = 5（假设为初始插入）。
5 < min_trx_id 10 → 已提交 → 可见。

所以事务 30 读到的是 x=1。

6.2.5 RR 与 RC 的区别

RR（可重复读）：ReadView 在事务的第一次 SELECT 时创建，之后整个事务复用该 ReadView。因此同一个事务内多次查询结果一致。
RC（读已提交）：每次 SELECT 都会创建新的 ReadView，所以能看到其他事务已经提交的最新数据。

避坑指南 #9：RR 级别下，事务开始后创建一致性视图，后续查询都基于该快照。FOR UPDATE 可以读到最新数据，同时解决第二类更新丢失问题。

七、MySQL 优化四大方向

graph LR
    A[MySQL 优化] --> B[设计层面]
    A --> C[功能层面]
    A --> D[架构层面]
    A --> E[SQL 层面]
    B --> B1[存储引擎 / 字段类型 / 范式]
    C --> C1[索引 / 缓存 / 分区分表]
    D --> D1[主从复制 / 读写分离 / 负载均衡]
    E --> E1[慢 SQL 分析 / 执行计划]

7.1 存储引擎选择

引擎	特点	适用场景
InnoDB	支持事务、行锁、外键、崩溃恢复	需要数据完整性、高并发的 OLTP 业务
MyISAM	表锁、无事务、查询和插入速度快	读多写少、日志型、临时统计表

避坑指南 #10：MySQL 5.5+ 默认引擎是 InnoDB，新项目无脑选 InnoDB。除非有非常明确的只读/归档场景，否则不要用 MyISAM。

7.2 字段类型选择原则

原则	说明
尽可能小	能用 `INT` 不用 `BIGINT`，能用 `TINYINT` 不用 `INT`
尽可能定长	`CHAR` 比 `VARCHAR` 更适合短定长文本
尽可能用整数	整数比较和索引效率高于字符串
短文本定长	用 `CHAR`
短文本变长	用 `VARCHAR`
长文本	用 `TEXT` / `BLOB`，避免直接索引大字段

7.3 数据库三大范式

graph LR
    A[1NF 原子性] --> B[2NF 消除部分依赖]
    B --> C[3NF 消除传递依赖]

范式	核心要求
第一范式 1NF	字段不可再分，每个字段只存单一值
第二范式 2NF	非主键字段必须完全依赖主键，不能依赖部分主键
第三范式 3NF	消除传递依赖，非主键字段只依赖主键

避坑指南 #11：不要过度范式化。互联网业务为了查询性能，常采用逆范式设计，允许适当冗余，用空间换时间。

7.4 功能层面优化：索引、缓存、分区分表

功能层面优化是在不改变核心业务表结构的前提下，通过索引、缓存、分区分表等手段提升性能。

索引优化

索引是最常用的功能优化手段。核心原则：

WHERE、JOIN、ORDER BY 字段建立索引。
覆盖索引：查询字段都在索引中，避免回表。
最左前缀：组合索引按使用频率和字段顺序设计。
避免索引失效：如函数操作索引列、隐式类型转换、前模糊 LIKE、OR 半边无索引等。

缓存策略

查询缓存：MySQL 8.0 已移除，不建议依赖。
应用层缓存：Redis / Memcached 缓存热点数据，减少数据库压力。
注意缓存一致性：写数据库后要及时失效或更新缓存，避免脏读。

分区分表

当单表数据量过大（通常超过 500 万 - 1000 万行，或单表超过 10GB）时，需要考虑拆分。主要分为两种：

方式	说明	对应用是否透明
分区（Partition）	单张表在物理上拆成多个分区文件，逻辑上仍是一张表	基本透明，应用按普通表读写
分表（Sharding）	把数据拆到多张物理表中，如 `user_0` - `user_15`	不透明，通常需要分库分表中间件或应用层路由

分区（Partition）

分区是 MySQL 提供的原生功能，一张逻辑表由多个物理分区组成，每个分区独立存储。

常见分区类型：

类型	说明	适用场景
RANGE	按连续范围分区，如按时间、ID 范围	日志表、订单表按月份归档
LIST	按离散值列表分区	按地区、状态等枚举值
HASH	按分区键哈希取模	数据分布均匀，无业务热点
KEY	类似 HASH，但由 MySQL 内部决定哈希函数	简化使用

创建分区表示例（RANGE）：

CREATE TABLE user_log (
    id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    action VARCHAR(50),
    created_at DATETIME NOT NULL
) PARTITION BY RANGE (YEAR(created_at)) (
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION pfuture VALUES LESS THAN MAXVALUE
);

分区表的增删改查：

-- 查询整个表（和普通表一样）
SELECT * FROM user_log WHERE created_at >= '2024-01-01';

-- 指定分区查询（强制扫描某个分区）
SELECT * FROM user_log PARTITION (p2024) WHERE action = 'login';

-- 插入数据（MySQL 自动根据分区键路由）
INSERT INTO user_log VALUES (1, 10086, 'login', '2024-06-01 10:00:00');

-- 更新数据（如果修改分区键，可能需要跨分区移动行）
UPDATE user_log SET created_at = '2025-01-01' WHERE id = 1;

-- 删除整个分区的数据（比分批 DELETE 快得多）
ALTER TABLE user_log DROP PARTITION p2022;

分区表的关键点：

分区键必须包含在唯一索引/主键中。例如主键是 (id)，那么不能按 created_at 分区，除非主键改成 (id, created_at)。
查询要命中分区键才能裁剪。如果 WHERE 里没有分区键，MySQL 会扫描所有分区，反而更慢。
分区数量不宜过多。MySQL 官方建议单表分区数控制在 1000 以内，过多会消耗文件描述符和内存。

分表（Sharding）

分表是把一张逻辑表拆成多张物理表，通常需要配合分库分表中间件（如 ShardingSphere、MyCat）或应用层路由。

拆分方式	说明	适用场景
垂直拆分	按业务/字段拆分，如 `user_base` 和 `user_profile`	单表字段过多、冷热数据分离
水平拆分	按行拆分，如 `user_id % 16` 分 16 张表	单表数据量过大、并发过高

水平拆分策略：

策略	优点	缺点
范围分片	按时间/ID 范围，扩容简单	容易热点，如最新时间片集中写入
哈希分片	数据分布均匀	扩容需要迁移数据
一致性哈希	扩容时迁移数据量少	实现稍复杂
列表分片	按地区/类型等枚举值	适合有明显业务边界的数据

分库分表带来的问题：

分布式事务：跨库事务无法靠单机 ACID 保证。
跨库 JOIN：需要在应用层聚合，或反范式冗余字段。
全局唯一 ID：不能用自增主键，需要雪花算法、号段等方案。
分页排序：ORDER BY + LIMIT 跨多表后合并复杂。
数据迁移：扩容时需要平滑迁移历史数据。

避坑指南 #14：不要为了拆分而拆分。大多数业务先做好索引、SQL 优化、加缓存，单表撑到千万级没问题。拆分成本：分区 < 分表 < 分库。优先考虑分区；分区也撑不住时，再考虑分库分表。

7.5 SQL 层面优化：慢 SQL 分析与执行计划

SQL 层面的优化收益往往最高，因为一条烂 SQL 可以把整个数据库拖垮。

如何发现慢 SQL

慢查询日志：slow_query_log = ON，long_query_time 设置阈值。
performance_schema：MySQL 内置性能监控。
pt-query-digest：Percona Toolkit 分析慢日志。
应用层 APM：SkyWalking、Pinpoint 等追踪 SQL 耗时。

EXPLAIN 看执行计划

EXPLAIN SELECT * FROM `order` WHERE age > 18 ORDER BY created_at LIMIT 10;

关键字段：

字段	含义
`type`	访问类型，越靠前越好：`system > const > eq_ref > ref > range > index > ALL`
`key`	实际使用的索引
`rows`	预估扫描行数
`Extra`	额外信息

type 详解：

type 表示 MySQL 访问表的方式，可以理解为“查资料时翻书的方式”。

type	通俗解释	效率	典型 SQL
system	表里最多 1 条数据，直接当常量	⭐⭐⭐⭐⭐	查只有一条配置的配置表
const	通过主键/唯一索引等值查，最多 1 条	⭐⭐⭐⭐⭐	`WHERE id = 1`
eq_ref	JOIN 时，被驱动表用主键/唯一索引匹配，最多 1 条	⭐⭐⭐⭐⭐	`A JOIN B ON A.b_id = B.id`
ref	通过普通索引等值查，可能有多条	⭐⭐⭐⭐	`WHERE phone = 'xxx'`（phone 是普通索引）
range	索引范围扫描	⭐⭐⭐	`WHERE age > 18`、`BETWEEN`、`IN`、`LIKE 'prefix%'`
index	全索引扫描	⭐⭐	`SELECT 索引列 FROM 表`、按索引排序
ALL	全表扫描	⭐	没走索引，逐行读

各 type 详细说明与示例：

1. system：表本身就是常量

表里只有 0 条或 1 条数据，MySQL 把它当成常量处理。

SELECT * FROM system_config;

如果 system_config 只有一条记录，EXPLAIN 可能看到 type = system。实际业务表中很少见。

2. const：精确命中唯一值

通过主键或唯一索引做等值查询，最多返回 1 行。

-- id 是主键
SELECT * FROM user WHERE id = 10086;

-- phone 是唯一索引
SELECT * FROM user WHERE phone = '13800138000';

这是单表查询里最好的 type。

3. eq_ref：JOIN 中的 const

多表 JOIN 时，被驱动表通过主键或唯一索引与驱动表匹配，每次匹配最多返回 1 行。

SELECT o.*, u.name
FROM `order` o
JOIN user u ON o.user_id = u.id;

假设 user.id 是主键，order 表的每一行去 user 表查都是精确命中 1 行，此时 user 表的 type = eq_ref。

4. ref：普通索引等值查询

通过普通索引（非唯一索引）做等值查询，可能返回多条。

-- status 是普通索引
SELECT * FROM `order` WHERE status = 'PAID';

status = 'PAID' 可能对应很多订单。这是生产环境最常见的良好 type。

5. range：索引范围扫描

使用索引做范围查询。

-- age 有索引
SELECT * FROM user WHERE age > 18;

-- create_time 有索引
SELECT * FROM `order`
WHERE create_time BETWEEN '2024-01-01' AND '2024-01-31';

-- id 是主键
SELECT * FROM user WHERE id IN (1, 2, 3, 4);

-- phone 有索引
SELECT * FROM user WHERE phone LIKE '1380%';

注意：LIKE '1380%' 走 range；LIKE '%1380' 或 LIKE '%1380%' 会退化成 ALL。

6. index：全索引扫描

遍历整个索引树，而不是全表扫描数据。

-- name 是索引列
SELECT name FROM user;

-- 按索引列排序
SELECT id FROM user ORDER BY id;

因为索引通常比实际数据小，读索引比读整行快。但如果查询列不在索引里或需要大量回表，index 也会很慢。

7. ALL：全表扫描

没有用到索引，逐行读取整张表。

-- phone 没有索引
SELECT * FROM user WHERE phone = '13800138000';

-- 对索引列使用函数
SELECT * FROM `order` WHERE DATE(create_time) = '2024-01-01';

-- 前模糊 LIKE
SELECT * FROM user WHERE phone LIKE '%1380%';

生产环境出现 type = ALL 通常需要优化。

简单记忆口诀：

system/const 是精确，一行数据最省事；
eq_ref 是 JOIN 版 const，主键关联一对一；
ref 普通索引等值查，可能返回好几行；
range 范围扫描用得广，BETWEEN IN 都能上；
index 全扫索引比表强；
ALL 全表扫描要提防。

生产环境建议：

type	是否需要关注
`system / const / eq_ref / ref`	优秀，基本不用管
`range`	正常，注意范围不要太大
`index`	需要警惕，确认是否真的需要全索引扫描
`ALL`	必须优化，除非表很小（几万行以内）

一般原则：单表查询尽量做到 ref 或更好，范围查询 range 可接受，尽量避免 ALL 和大量数据的 index。

危险的 Extra：

Using filesort：需要额外排序，常见于无索引的 ORDER BY。
Using temporary：需要创建临时表，常见于 GROUP BY、DISTINCT。
Using index：好现象，使用了覆盖索引。
Using where：在存储引擎返回数据后再过滤。

典型慢 SQL 写法与严重踩坑案例

案例 1：`SELECT *`

SELECT * FROM `order` WHERE user_id = 10086;

问题：读取不需要的列，增加网络传输和 Buffer Pool 占用，容易触发回表。

优化：

SELECT order_id, status, amount FROM `order` WHERE user_id = 10086;

案例 2：前模糊 LIKE 导致索引失效

SELECT * FROM user WHERE phone LIKE '%1380%';

问题：% 在开头无法使用 B+ 树索引，会全表扫描。

优化：

改为后缀匹配：LIKE '1380%'（如果有索引仍可用）。
使用全文索引或 Elasticsearch。

案例 3：`OR` 条件半边无索引

SELECT * FROM user WHERE phone = '13800138000' OR email = 'a@b.com';

问题：如果 email 没有索引，MySQL 可能放弃索引，直接全表扫描。

优化：

SELECT * FROM user WHERE phone = '13800138000'
UNION ALL
SELECT * FROM user WHERE email = 'a@b.com';

或给 email 也建索引。

案例 4：隐式类型转换

SELECT * FROM user WHERE phone = 13800138000;

问题：phone 是 varchar，MySQL 会先把所有行的 phone 转成整数再比较，索引失效。

优化：

SELECT * FROM user WHERE phone = '13800138000';

案例 5：函数操作索引列

SELECT * FROM `order` WHERE DATE(create_time) = '2024-01-01';

问题：对索引列使用函数，DATE(create_time) 不是索引本身，索引失效。

优化：

SELECT * FROM `order`
WHERE create_time >= '2024-01-01'
  AND create_time < '2024-01-02';

案例 6：大 OFFSET 深分页

SELECT * FROM `order` ORDER BY id LIMIT 1000000, 10;

问题：MySQL 需要先扫描 1000010 行，再扔掉前面的 1000000 行，越往后越慢。

优化（延迟关联）：

SELECT o.*
FROM `order` o
JOIN (SELECT id FROM `order` ORDER BY id LIMIT 1000000, 10) tmp ON o.id = tmp.id;

或记录上次位置：

SELECT * FROM `order` WHERE id > ? ORDER BY id LIMIT 10;

案例 7：`IN` 子句元素过多

SELECT * FROM user WHERE id IN (1, 2, 3, ..., 50000);

问题：IN 元素过多会导致解析和执行效率下降，甚至超出限制。

优化：分批查询，或把 ID 写入临时表再 JOIN。

案例 8：大事务长时间持有锁

START TRANSACTION;
-- 大量更新操作
UPDATE huge_table SET ... WHERE ...;
-- 业务逻辑处理
-- 几分钟后才 COMMIT

问题：长时间持有行锁/间隙锁，阻塞其他事务，Undo Log 堆积，主从延迟放大。

优化：拆分为小批量事务，减少单次锁定范围。

线上最严重的几个踩坑

踩坑行为	后果	正确做法
`UPDATE / DELETE` 忘记写 `WHERE`	全表数据被改/删，可能导致业务瘫痪	先 `SELECT` 确认影响行数，使用 `LIMIT`，小批量执行
高峰期执行 `ALTER TABLE` / `OPTIMIZE`	锁表，查询堆积，服务雪崩	使用 Online DDL（如 `pt-online-schema-change`），低峰期执行
直接 `SELECT * FROM huge_table`	打满 Buffer Pool，拖垮数据库	加分页、加条件、只查必要字段
慢 SQL 打满连接池	应用无法获取连接，全面超时	设置 SQL 超时，连接池隔离，熔断降级

避坑指南 #15：上线任何 SQL 前，先用 EXPLAIN 检查执行计划。看到 type = ALL、Extra = Using filesort 或 Using temporary 时，必须优化后再上线。

八、高性能架构设计

8.1 主从复制 + 读写分离

graph LR
    A[写请求] --> B[主库 Master]
    B -->|binlog 同步| C[从库 Slave 1]
    B -->|binlog 同步| D[从库 Slave 2]
    E[读请求] --> C
    E --> D

避坑指南 #12：主从复制存在延迟。如果对实时性要求极高（如支付后立刻查询余额），读请求应强制走主库，或在业务层做延迟容忍设计。

8.2 分区分表

方式	说明
垂直拆分	按业务/字段拆分，如用户表拆成 `user_base` 和 `user_profile`
水平拆分	按行拆分，如按 `user_id % 16` 分 16 张表

九、用户权限与数据导出

9.1 创建新用户并授权

-- 创建用户
CREATE USER 'goose_vod'@'%' IDENTIFIED BY 'xxxx';

-- 授权
GRANT ALL PRIVILEGES ON `ad_db`.* TO `goose_vod`@`%`;

-- 刷新权限
FLUSH PRIVILEGES;

避坑指南 #13：生产环境请遵循最小权限原则，不要给业务账号 ALL PRIVILEGES。例如只读账号只授予 SELECT。

9.2 导出数据库

mysqldump -h xxxx-rds.xxxx.us-east-1.rds.amazonaws.com \
  -u goose_vod -p appstore_db > ~/database_dump.txt

十、避坑清单速查表

编号	避坑点
1	数据库字符集用 `utf8mb4`，不要用默认 `utf8`
2	JDBC 连接串指定 `serverTimezone` 和 `characterEncoding`
3	通用日志只用于临时排查，不要长期开启
4	存储过程谨慎使用，优先应用层处理业务逻辑
5	不可重复读 ≠ 幻读，RR 级别下 InnoDB 基本解决幻读
6	根据业务决定是否将隔离级别从 RR 改为 RC
7	组合索引遵循最左前缀原则
8	普通 `SELECT` 不加锁，需要锁时显式 `FOR UPDATE`
9	RR 下快照读基于 ReadView，`FOR UPDATE` 读最新数据
10	新项目默认使用 InnoDB，不要选 MyISAM
11	适度逆范式，用空间换查询时间
12	主从延迟存在，实时读考虑强制走主库
13	生产环境遵循最小权限原则
14	不要为了拆分而拆分；拆分成本：分区 < 分表 < 分库，优先考虑分区
15	上线前用 EXPLAIN 检查执行计划，警惕 ALL / filesort / temporary

十一、总结

MySQL 的学习路径可以概括为：

graph LR
    A[熟练 SQL 与安装配置] --> B[理解事务与隔离级别]
    B --> C[掌握索引设计与优化]
    C --> D[理解锁与 MVCC]
    D --> E[掌握主从复制与读写分离]
    E --> F[持续分析慢 SQL 与执行计划]

高性能 MySQL 没有银弹，核心在于：合理的表结构设计、精准的索引、恰到好处的事务隔离、以及能够水平扩展的架构。希望这份笔记能成为你日常开发与面试复习的速查手册。

数据库 on 方糖猫Blog

MongoDB 从入门到精通：存储引擎、建模、索引、副本集、分片与事务实战

MongoDB 从入门到精通：存储引擎、建模、索引、副本集、分片与事务实战

第一篇 选型认知：什么时候该用 MongoDB，什么时候别逞强

第二篇 WiredTiger：理解存储引擎，才配谈性能

2.1 底层数据模型：BSON，磁盘上到底存了什么

2.2 为什么快：读快与写快的底层原因

2.3 WiredTiger 你必须知道的四件事

2.4 本地环境：直接上副本集，别玩单机

第三篇 数据建模：核心战场，没有之一

3.1 唯一重要的问题：嵌入还是引用

3.2 电商核心建模：订单快照与库存拆分

第四篇 索引与 explain：调优基本功，没有捷径

4.1 explain 是唯一标准答案

4.2 ESR 法则与 Java 建索引

第五篇 聚合管道：把计算下推给服务端

第六篇 副本集：高可用与读写语义的分水岭

6.1 架构与选主

6.2 读写语义：writeConcern 与 readConcern

第七篇 事务与分片：规模化之后的一致性难题

7.1 能不用事务就不用：原子操作的威力

7.2 真正需要事务的场景

7.3 分片：单副本集扛不住之后

第八篇 运维底线与 AI 时代：把系统做稳，把代码写少

8.1 生产运维的最低纲领

8.2 AI 时代：如何少写代码把系统做稳

附录：Demo 与检查清单

Lua 入门：写给 Redis 脚本使用者的极简教程

Lua 入门：写给 Redis 脚本使用者的极简教程

一、为什么 Redis 需要 Lua

二、本地 Lua 环境准备

2.1 安装 Lua

2.2 第一个本地 Lua 程序

2.3 用 Redis 验证脚本

2.4 编辑器推荐

三、Hello World：第一个 Redis Lua 脚本

四、Lua 基础：Redis 场景够用的子集

4.1 变量与类型

4.2 字符串与数字转换

4.3 表（table）：数组 + 字典

4.4 条件判断

4.5 循环

4.6 函数

五、Lua 原理浅析

5.1 解释器与字节码

5.2 内存回收机制

5.3 Table 是核心

5.4 Redis 中的 Lua 沙箱

六、Redis 脚本核心 API

6.1 redis.call 与 redis.pcall

6.2 返回值

6.3 KEYS 与 ARGV 的规范

七、实战：常见 Redis Lua 模式

7.1 限流（滑动窗口）

7.2 分布式锁（可重入简化版）

7.3 库存扣减（防超卖）

7.4 批量删除符合某种前缀的 key

7.5 条件更新（CAS 简化版）

八、调试、常见坑与最佳实践

8.1 调试脚本

8.2 常见踩坑清单

8.3 性能建议

九、总结

从Redis核心原理到 IPTV 视频项目落地

从Redis核心原理到 IPTV 视频项目落地

一、Redis 是什么？一句话定位

二、Redis 为什么快？

三、Redis 数据类型与使用场景

3.1 五种基本数据类型

3.2 三种特殊数据类型

3.3 String：最常用却被低估

3.4 Hash：对象缓存首选

3.5 ZSET：排行榜的王牌

3.6 List 与 Stream：队列双雄

3.7 Bitmap 与 HyperLogLog：海量 UV 统计的利器

四、Redis 底层数据结构速览

4.1 SDS（Simple Dynamic String）

4.2 ziplist（压缩列表）

4.3 quicklist（快速列表）

4.4 intset（整数集合）

第一篇选型认知：什么时候该用 MongoDB，什么时候别逞强

第三篇数据建模：核心战场，没有之一

第四篇索引与 explain：调优基本功，没有捷径

第五篇聚合管道：把计算下推给服务端

第六篇副本集：高可用与读写语义的分水岭

第七篇事务与分片：规模化之后的一致性难题

第八篇运维底线与 AI 时代：把系统做稳，把代码写少