电商 on 方糖猫Blog

Spark 从入门到精通：架构原理、RDD/DataFrame、调优踩坑与电商实战全指南

Wed, 26 Oct 2022 09:30:00 +0800

Spark 从入门到精通：架构原理、RDD/DataFrame、调优踩坑与电商实战全指南

目标读者：写过一两年后端（Java/Scala/Python 皆可）、第一次要碰大数据的同学；或者用 PySpark 写过一些脚本、但一遇到性能问题就抓瞎的同学。写这篇文章时（2022 年 10 月），Spark 3.3 刚发布，DataFrame 早已是绝对主流，Flink 在实时方向上攻城略地。但离线批处理、数仓 ETL、特征工程这些重活，Spark 依然是绕不开的那座山。

全文六篇，顺序就是学习的顺序：

flowchart LR
    A["一 为什么是 Spark<br/>从单机到分布式"] --> B["二 架构与原理<br/>Driver Executor DAG"]
    B --> C["三 RDD 与 DataFrame<br/>两代 API 的分水岭"]
    C --> D["四 电商实战<br/>宽表 漏斗 特征"]
    D --> E["五 调优与踩坑<br/>倾斜 OOM 小文件"]
    E --> F["六 AI 时代<br/>少写代码 多写提示词"]
    style F fill:#e8f4e8

为什么是这个顺序？第一篇解决「为什么要用它」；第二篇解决「它在集群里怎么跑」——不理解这个，写出来的代码就是玄学；第三篇解决「代码怎么写」；第四篇用真实业务把知识串起来；第五篇是血泪史，生产环境和本地 Demo 是两个物种；第六篇聊怎么让 AI 替你干活。

第一篇为什么是 Spark：一台机器装不下的时代

1.1 一个电商场景把问题引出来

假设你在一家中型电商公司做后端。双十一刚过，老板要看一份报表：

昨天所有下单用户，按城市分组，统计成交额、下单次数、客单价，再看这批用户里有多少是 30 天内的新客。

订单表 8 亿行，用户表 4000 万行，行为日志（埋点）一天 20 亿条。MySQL 里跑这个 SQL？GROUP BY 一个 8 亿行的表，跑一晚上 MySQL 先把你杀了——不，是 DBA 先把你杀了。

你想到的办法是「把数据导出来，写个 Python 脚本跑」。8 亿行订单数据，CSV 导出大概 400GB。你的开发机内存 32GB。装不下，这就是大数据的全部问题。

解决思路只有两个方向：

flowchart TB
    subgraph 思路一["思路一：垂直扩展（Stack Overflow 式的天真）"]
        A1["换个 1TB 内存的机器"] --> A2["贵得离谱<br/>且有物理上限"]
    end
    subgraph 思路二["思路二：水平扩展（唯一出路）"]
        B1["把 400GB 切成 1000 份"] --> B2["1000 台机器<br/>每台处理 400MB"]
        B2 --> B3["各自算局部结果<br/>最后合并"]
    end

思路二就是分布式计算。但自己写 1000 台机器的协调代码？分发任务、处理机器挂掉、合并结果、处理网络超时……你会写出第二个 Hadoop。

Spark 就是替你把这些脏活全包了：你只写「对这批数据做什么变换」，它负责切分、调度、容错、合并。

1.2 Spark 在生态里的位置

新人最容易被一堆名词搞晕：Hadoop、HDFS、YARN、Hive、Spark、Flink。一张图说清楚：

flowchart TB
    subgraph 存储层
        HDFS["HDFS<br/>分布式文件系统<br/>（把文件切块存到多台机器）"]
        S3["S3 / OSS<br/>对象存储"]
    end
    subgraph 资源层
        YARN["YARN / K8s<br/>集群资源调度<br/>（给任务分配 CPU 和内存）"]
    end
    subgraph 计算层
        MR["MapReduce<br/>老一辈 磁盘IO 慢"]
        SPARK["Spark<br/>内存计算 快<br/>本篇主角"]
        FLINK["Flink<br/>流处理专精"]
    end
    subgraph 应用层
        HIVE["Hive/Spark SQL<br/>SQL 写报表"]
        DS["数据科学<br/>MLlib 特征工程"]
    end
    HDFS --> YARN
    S3 --> YARN
    YARN --> MR
    YARN --> SPARK
    YARN --> FLINK
    SPARK --> HIVE
    SPARK --> DS
    style SPARK fill:#ffd699

几个关键认知：

Spark 不是存储系统，它没有自己的存储，数据放在 HDFS、Hive 表、S3 甚至 MySQL 里，它读进来算完再写回去。
Spark 也不是资源调度器，它跑在 YARN 或 Kubernetes 上，向它们「申请」机器。
Spark 相对 MapReduce 的快，核心就一句话：中间结果放内存，不落地磁盘。MapReduce 每步都要写磁盘，迭代式计算（比如机器学习跑 50 轮迭代）就慢到不可用。

踩坑预告：很多人学 Spark 的第一步是去装 Hadoop 全家桶，装了一周还没跑起来 Hello World。其实本地学习完全不需要——Spark 有 local 模式， pip 装个 pyspark 就能跑。下一篇的 Demo 全是单机可运行的。

第二篇架构与原理：代码提交之后到底发生了什么

这是最重要的一篇。Spark 调优 80% 靠对这套架构的直觉，剩下 20% 才是参数。

2.1 一次 Spark 任务的全貌

flowchart TB
    CODE["你的代码<br/>spark.read... .groupBy... .write..."] --> DRV
    subgraph Cluster["集群（YARN / K8s）"]
        subgraph DRV["Driver（司机/总指挥）"]
            DAG["DAG Scheduler<br/>把代码翻译成执行计划<br/>切成若干 Stage"]
            TS["Task Scheduler<br/>把 Stage 拆成 Task<br/>派发给 Executor"]
        end
        subgraph EXE["Executor × N（干活的工人）"]
            T1["Task 1<br/>处理 Partition 1"]
            T2["Task 2<br/>处理 Partition 2"]
            T3["Task 3<br/>处理 Partition 3"]
            CACHE["内存/磁盘<br/>缓存中间数据"]
        end
    end
    TS --> T1
    TS --> T2
    TS --> T3
    T1 -.shuffle 阶段互相交换数据.-> T2

关键角色就三个：

Driver：你的 main 函数（或 PySpark 脚本）运行的地方。它不干活，它发号施令——分析你的代码、生成执行计划、把任务派发出去、回收结果。Driver 挂了，整个任务就完了。
Executor：集群里真正干活的 JVM 进程，每个 Executor 有若干核，每个核同时跑一个 Task。数据是**分区（Partition）**存储的，一个 Task 处理一个 Partition。
Shuffle：当操作需要跨机器汇总数据（groupBy、join、distinct），数据就要在网络上重新分发——这叫 Shuffle。Shuffle 是 Spark 任务慢的第一大原因，后文反复出现。

2.2 懒执行（Lazy Evaluation）：为什么你的代码"没报错"却在运行时炸了

新手最常踩的认知坑：Spark 代码写下去并不会立刻执行。

df = spark.read.csv("orders.csv")          # 没执行！只是记录"要读个文件"
df2 = df.filter(df.amount > 100)           # 没执行！只是记录"要过滤"
df3 = df2.groupBy("city").sum("amount")    # 没执行！只是记录"要分组聚合"
df3.write.save("output")                   # 现在才真正开始跑！

读数据、过滤、分组这些叫 Transformation（变换），只是往计划里加节点；write、count、collect、show 这些叫 Action（行动），碰到 Action，Driver 才把整条链路翻译成 DAG（有向无环图），切成 Stage，真正派发执行。

这个设计的好处是优化：Spark 的 Catalyst 优化器能看到整条链路，比如发现你过滤条件写晚了，它可以自动把 filter 下推到读数据时就做（Predicate Pushdown），少读一半数据。

但坑也随之而来：

踩坑故事 1：错误行号的谎言 刚转 Spark 时我排查一个任务失败，日志说第 87 行 df.write.save() 报错 “文件不存在”。我盯着 87 行看了半小时——write 语法没问题啊！后来才明白：真正的错误发生在第 12 行的 spark.read（路径写错了），但因为是懒执行，直到 87 行触发 Action 才爆出来。看 Spark 报错，永远要从日志里的执行计划往上找 Transformation 的源头，而不是看报错行号。

2.3 Stage 是怎么切出来的：宽依赖与窄依赖

理解 Shuffle 就理解了 Stage 的切分：

flowchart LR
    subgraph Stage1["Stage 1（窄依赖，流水线执行）"]
        P1["Partition 1<br/>读文件"] --> F1["filter<br/>过滤"]
        P2["Partition 2<br/>读文件"] --> F2["filter<br/>过滤"]
    end
    subgraph SHUFFLE["⚡ Shuffle（跨网络搬数据）"]
        direction TB
        S["按 city 重新分区<br/>同 city 的数据<br/>汇聚到同一 Partition"]
    end
    subgraph Stage2["Stage 2"]
        G1["Partition A<br/>北京的订单<br/>sum(amount)"]
        G2["Partition B<br/>上海的订单<br/>sum(amount)"]
    end
    F1 --> SHUFFLE
    F2 --> SHUFFLE
    SHUFFLE --> G1
    SHUFFLE --> G2
    style SHUFFLE fill:#ffcccc

窄依赖（filter、map）：子 Partition 只依赖父的一个 Partition，可以像流水线一样在同一台机器一口气算完，不分 Stage。
宽依赖（groupBy、join、distinct）：子 Partition 需要父的所有 Partition 的数据，必须 Shuffle，Stage 在这里断开。

一个 Stage 内的失败重试只重跑这个 Stage。所以 Spark 的容错单位是 Stage——这也是为什么 Spark 会把 Shuffle 的中间结果落盘（对，嘴上说自己内存计算，Shuffle 还是要写磁盘的），挂了能从这里恢复，而不是从头再来。

第三篇 RDD 与 DataFrame：两代 API 的分水岭

3.1 RDD：能看清每个零件，但要自己造发动机

RDD（弹性分布式数据集）是 Spark 1.x 的核心抽象。用它写上面的需求：

// RDD 风格：你告诉 Spark 每一步"怎么做"
orders
  .filter(_.split(",")(5).toDouble > 100)     // 自己解析 CSV，自己转类型
  .map(line => (line.split(",")(3),           // 自己取城市字段做 key
                line.split(",")(5).toDouble)) // 自己取金额做 value
  .reduceByKey(_ + _)                          // 按 key 聚合
  .saveAsTextFile("output")

RDD 的问题是：Spark 看不懂你在干什么。filter(_.split(",")(5).toDouble > 100) 对优化器来说就是一个黑盒 lambda，它不知道你在过滤哪列，没法做谓词下推，没法选更好的 join 策略。而且 JVM 里每一行都是一个 Java 对象，序列化开销大、GC 压力巨大。

3.2 DataFrame：你只说"要什么"，优化器替你想"怎么做"

DataFrame（Spark 1.3 引入，2.0 后与 Dataset 合并）给数据加了Schema（表结构），从此 Spark 能看懂你的意图：

# DataFrame 风格：声明式
(spark.read
  .schema("order_id STRING, city STRING, amount DOUBLE")
  .csv("orders.csv")
  .filter("amount > 100")
  .groupBy("city")
  .sum("amount")
  .write.parquet("output"))

两者差距有多大？同样的逻辑，DataFrame 通常比 RDD 快 2~10 倍，原因：

flowchart TB
    subgraph RDD路径["RDD：信任程序员"]
        R1["你的 lambda"] --> R2["逐行 Java 对象<br/>序列化/GC 开销大<br/>优化器爱莫能助"]
    end
    subgraph DF路径["DataFrame：信任优化器"]
        D1["声明式表达式"] --> D2["Catalyst 优化器<br/>逻辑计划优化<br/>谓词下推/列裁剪"]
        D2 --> D3["Tungsten 执行引擎<br/>二进制内存布局<br/>代码生成 绕开 GC"]
    end
    style DF路径 fill:#e8f4e8

一句话结论（2022 年视角）：新业务永远用 DataFrame/Spark SQL 写，RDD 只在两种情况下出现——操作的是非结构化数据（比如解析一堆不规则日志），或者需要逐分区精细控制（mapPartitions 里建数据库连接池这种）。面试让你手写 RDD wordcount 是考察理解，不是让你生产上这么写。

3.3 本地就能跑的完整 Demo

别急着上集群。装个 Python 环境就能跑：

pip install pyspark==3.3.0

造一份模拟电商订单数据，跑通「读 → 变换 → 聚合 → 写」全流程：

# demo01_basic.py
from pyspark.sql import SparkSession
from pyspark.sql import functions as F

spark = (SparkSession.builder
         .appName("demo01")
         .master("local[*]")      # 本地模式，用满 CPU 核
         .getOrCreate())

# 造数据：100 万行模拟订单
orders = (spark.range(0, 1_000_000)
          .select(
              F.concat(F.lit("ORD"), F.col("id")).alias("order_id"),
              (F.col("id") % 50000).alias("user_id"),
              F.element_at(
                  F.array([F.lit(c) for c in
                           ["北京", "上海", "广州", "深圳", "杭州"]]),
                  (F.col("id") % 5 + 1).cast("int")).alias("city"),
              (F.rand() * 2000).alias("amount"),
              F.date_add(F.lit("2022-10-25"),
                         -(F.col("id") % 30).cast("int")).alias("order_date")))

result = (orders
          .filter(F.col("amount") > 100)
          .groupBy("city")
          .agg(F.count("*").alias("order_cnt"),
               F.round(F.sum("amount"), 2).alias("gmv"),
               F.round(F.avg("amount"), 2).alias("avg_price"))
          .orderBy(F.desc("gmv")))

result.show()          # Action：真正触发执行
result.write.mode("overwrite").parquet("output/city_gmv")
spark.stop()

运行：

python demo01_basic.py

输出：

+----+---------+-----------+---------+
|city|order_cnt|        gmv|avg_price|
+----+---------+-----------+---------+
|  深圳|   190231|...        |  1050.12|
|  北京|   190087|...        |  1049.87|
...
+----+---------+-----------+---------+

这个 Demo 麻雀虽小，五脏俱全：spark.range 造数、element_at 数组取值、rand 随机数、聚合多指标、写 Parquet。本地玩熟了，语法迁移到集群上一行都不用改——这就是 Spark 的优雅之处。

踩坑故事 2：Windows 上的 winutils.exe 我在 Windows 笔记本上第一次跑 PySpark，直接 winutils.exe 缺失报错 + 一堆权限异常。解决办法是下载对应 Hadoop 版本的 winutils.exe 放到 %HADOOP_HOME%\bin 并设置环境变量。后来学乖了：学习期直接 WSL2 或者 Docker 起个 Linux 环境，少生一肚子气。

第四篇电商实战：把知识串成业务

这一篇用三个电商真实场景，把前面的知识点全部用起来。这三个场景也是面试里最高频的"你做过什么项目"素材。

4.1 场景一：订单宽表（每日 ETL）

业务：订单数据分散在三张表——订单主表（order_id、user_id、amount、pay_time）、订单明细表（order_id、sku_id、quantity）、商品维表（sku_id、category、brand）。数据仓库要求每天凌晨产出一张"订单明细宽表"，下游 BI 直接查它。

# demo02_dwd_wide_table.py
orders = spark.table("ods.orders").filter(F.col("dt") == "2022-10-25")
items  = spark.table("ods.order_items").filter(F.col("dt") == "2022-10-25")
skus   = spark.table("dim.sku").filter(F.col("dt") == "2022-10-25")

wide = (items
        .join(orders, "order_id")
        .join(F.broadcast(skus), "sku_id")   # ★ 维表小，广播它！
        .select("order_id", "user_id", "sku_id", "category", "brand",
                "quantity", "amount", "pay_time")
        .withColumn("dt", F.lit("2022-10-25")))

(wide.write
 .mode("overwrite")
 .partitionBy("dt")
 .parquet("warehouse/dwd/order_detail_wide"))

知识点：Broadcast Join。普通 join 两张表都要 Shuffle；但如果一张表很小（商品维表几十万行，几十 MB），Spark 可以把它整个复制到每个 Executor 的内存里，大表原地不动就能完成 join——Shuffle 直接消失，速度提升一个数量级。

判断标准：小表 < spark.sql.autoBroadcastJoinThreshold（默认 10MB，生产常调到 100MB~500MB）。写 F.broadcast(skus) 是显式强制，防止优化器估算失误。

flowchart LR
    subgraph 普通Join["普通 Sort-Merge Join（两张表都 Shuffle）"]
        A1["大表 Partition"] -.网络搬家.-> J1["Join 节点"]
        A2["维表 Partition"] -.网络搬家.-> J1
    end
    subgraph 广播Join["Broadcast Join（只有小表复制）"]
        B1["大表 Partition 1<br/>原地不动"] --> C1["本地 Join<br/>查内存里的小表"]
        B2["大表 Partition 2<br/>原地不动"] --> C2["本地 Join<br/>查内存里的小表"]
        SM["小表整表复制<br/>→ 每个 Executor"] --> C1
        SM --> C2
    end
    style 广播Join fill:#e8f4e8

4.2 场景二：用户行为漏斗（转化率分析）

业务：运营想知道双十一预热期的转化漏斗：曝光 → 点击 → 加购 → 下单 → 支付，每一步流失多少人。

# demo03_funnel.py
events = spark.table("ods.user_events").filter(F.col("dt") == "2022-10-25")
# events 字段：user_id, event_type(view/click/cart/order/pay), ts

# 每个用户在每一步的最早时间
first_ts = (events
            .groupBy("user_id")
            .agg(F.min(F.when(F.col("event_type") == "view",  F.col("ts"))).alias("t_view"),
                 F.min(F.when(F.col("event_type") == "click", F.col("ts"))).alias("t_click"),
                 F.min(F.when(F.col("event_type") == "cart",  F.col("ts"))).alias("t_cart"),
                 F.min(F.when(F.col("event_type") == "order", F.col("ts"))).alias("t_order"),
                 F.min(F.when(F.col("event_type") == "pay",   F.col("ts"))).alias("t_pay")))

# 严格漏斗：必须按时间顺序走到该步才算转化
funnel = first_ts.agg(
    F.count("t_view").alias("曝光"),
    F.count(F.when(F.col("t_click") > F.col("t_view"), 1)).alias("点击"),
    F.count(F.when(F.col("t_cart")  > F.col("t_click"), 1)).alias("加购"),
    F.count(F.when(F.col("t_order") > F.col("t_cart"),  1)).alias("下单"),
    F.count(F.when(F.col("t_pay")   > F.col("t_order"), 1)).alias("支付"))

funnel.show()

知识点：groupBy + 条件聚合（F.when inside agg）是漏斗分析的标准套路——一行 SQL 出五步漏斗，不用写五次 count 再 join。这也是经典面试题。

踩坑故事 3：漏斗口径的战争 我第一版漏斗上线后，运营说数据和他们对不上。查了半天，发现分歧在口径：我写的是"严格顺序漏斗"（必须 view 之后才 click 才算），运营期望的是"存在性漏斗"（只要当天两个行为都发生过就算）。大数据开发一半的返工不是技术问题，是口径没对齐。现在的习惯：开工前把每一步的定义写成一行白话发群里，确认了再写代码。

4.3 场景三：推荐特征工程（用户画像）

业务：算法团队要用户特征——每个用户近 30 天的购买次数、客单价、最偏爱类目、最近一次购买距今天数（RFM 模型的雏形）。

# demo04_user_features.py
from pyspark.sql.window import Window

orders_30d = spark.table("dwd.order_detail_wide").filter(
    F.col("dt").between("2022-09-26", "2022-10-25"))

# 基础聚合特征
agg_feat = (orders_30d
            .groupBy("user_id")
            .agg(F.countDistinct("order_id").alias("order_cnt_30d"),
                 F.round(F.avg("amount"), 2).alias("avg_amount_30d"),
                 F.max("pay_time").alias("last_pay_time")))

# 最偏爱类目：窗口函数按类目的购买金额排序取第一
w = Window.partitionBy("user_id").orderBy(F.desc("cat_amount"))
top_cat = (orders_30d
           .groupBy("user_id", "category")
           .agg(F.sum("amount").alias("cat_amount"))
           .withColumn("rn", F.row_number().over(w))
           .filter(F.col("rn") == 1)
           .select("user_id", F.col("category").alias("top_category")))

features = (agg_feat
            .join(top_cat, "user_id")
            .withColumn("days_since_last_pay",
                        F.datediff(F.lit("2022-10-26"), F.col("last_pay_time"))))

features.write.mode("overwrite").parquet("features/user_rfm/dt=2022-10-25")

知识点：窗口函数（Window.partitionBy(...).orderBy(...) + row_number）是"每组取 TopN"的标准解法，Hive SQL 里也是同一句，大数据面试必考。

三个场景串起来，就是一条标准的离线数仓链路：

flowchart LR
    subgraph 数据源
        DB["业务 MySQL<br/>订单/明细/商品"]
        LOG["埋点日志<br/>曝光/点击/加购"]
    end
    DB -->|Sqoop/DataX 同步| ODS
    LOG -->|Flume/直接落盘| ODS
    subgraph 数仓["数仓分层（Hive on Spark）"]
        ODS["ODS 贴源层<br/>原样搬运"] --> DWD["DWD 明细层<br/>清洗 关联 宽表<br/>★ 场景一"]
        DWD --> DWS["DWS 汇总层<br/>按主题聚合<br/>★ 场景二漏斗"]
        DWS --> ADS["ADS 应用层<br/>直接服务业务<br/>★ 场景三特征"]
    end
    ADS --> BI["BI 报表"]
    ADS --> ALG["推荐算法"]

第五篇调优与踩坑：生产环境才是真的战场

本地 Demo 岁月静好，上了生产环境才知道什么叫残酷。下面三个坑，每一个我都在凌晨两点处理过。

5.1 天坑一：数据倾斜（一个 Task 跑三小时，其他三分钟）

现象：任务 99% 的 Stage 秒过，最后一个 Stage 的 200 个 Task 里，199 个 5 分钟跑完，1 个跑了 3 小时还在爬。Spark UI 上看，那个 Task 的 Shuffle Read 是别人的几百倍。

原因：某个 key 的数据量碾压其他 key。电商里最典型的就是：

大促时某个爆款商品（iPhone 发售当天）的订单明细占全站 30%；
维表 join 时空值/默认值 key——脏数据的 user_id = null 或 '-1' 有上千万条，全挤到一个 Partition。

排查：Spark UI → Stages → 看 Task 的 Summary Metrics，Max 时间远大于 Median（中位数），就是倾斜。

解法三板斧：

# 招式1：过滤异常 key（脏数据导致的倾斜，90% 的情况）
df = df.filter(F.col("user_id").isNotNull() & (F.col("user_id") != "-1"))

# 招式2：热点 key 加盐打散（真热点，比如爆款商品）
# 给大表的热点 key 加随机后缀 0~9，小表对应 key 复制 10 份
salted = big.withColumn(
    "join_key",
    F.when(F.col("sku_id") == "爆款SKU",
           F.concat(F.col("sku_id"), F.lit("_"), (F.rand()*10).cast("int")))
     .otherwise(F.col("sku_id")))
small_exploded = small.withColumn(
    "join_key",
    F.when(F.col("sku_id") == "爆款SKU",
           F.concat(F.col("sku_id"), F.lit("_"),
                    F.explode(F.array([F.lit(i) for i in range(10)]))))
     .otherwise(F.col("sku_id")))

# 招式3：开启 AQE 自动处理（Spark 3.x 的救星）
spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.skewJoin.enabled", "true")

踩坑故事 4：AQE 救了我一个通宵 2022 年上半年迁移 Spark 3.x 后开了 AQE（Adaptive Query Execution），它能在运行时发现倾斜的 Partition 并自动拆分。以前要手工调参数 spark.sql.shuffle.partitions 反复试的任务，AQE 直接自己搞定了。所以第一建议永远是：先升级到 Spark 3.x 并开启 AQE，再用脑子去调。

flowchart TB
    subgraph 倾斜前["倾斜：一个 Partition 吞掉 40% 数据"]
        K1["Partition 1: 50MB"] 
        K2["Partition 2: 8GB 😱"] 
        K3["Partition 3: 50MB"]
    end
    subgraph 倾斜后["AQE 拆分后：化整为零"]
        L1["Partition 1: 50MB"]
        L2a["Partition 2a: 200MB"]
        L2b["Partition 2b: 200MB"]
        L2c["Partition 2c: 200MB<br/>...共拆 40 份"]
        L3["Partition 3: 50MB"]
    end
    倾斜前 -->|"AQE 运行时检测拆分"| 倾斜后
    style K2 fill:#ffcccc

5.2 天坑二：OOM（内存不够，但到底谁不够）

Spark 的 OOM 分两种，报错长得像，病因完全不同：

报错关键字	病因	解法
`ExecutorLostFailure` / 容器被 kill / `java.lang.OutOfMemoryError`	Executor 内存不够：数据太多、缓存太大	加 `executor-memory`、增加分区数摊薄数据、减少 `cache` 滥用
Driver 端 OOM	Driver 内存不够：几乎永远是 `collect()` / `toPandas()` 把全量数据拉回 Driver	不要用 collect 收大数据！用 `take(100)` 抽样看，用 `write` 落盘

踩坑故事 5：一个 collect 拖垮了整个集群调度 同事为了"快速验证"，在生产任务里写了 df.collect() 然后 len() 一下——那张表 2 亿行。Driver 内存从 4G 一路撑爆，任务挂掉不说，还因为是调度系统的重要任务，报警电话打到了总监那里。从此组里 Code Review 第一条红线：搜索代码里有没有 collect()、toPandas()，有就必须说明数据量上限。

5.3 天坑三：小文件灾难（HDFS 的慢性病）

现象：任务很快跑完，但写出的结果目录里是 20000 个 100KB 的小文件。然后：Hive 查这张表慢得离谱，NameNode 内存报警，下游任务读它要启动几万个 Task。

原因：200 个分区 × 每次写 100 个文件 = 每天积累，几个月后就是几百万小文件。HDFS 的 NameNode 把每个文件的元数据放内存，小文件多是集群的头号慢性病。

解法：

# 写出前合并分区（注意：coalesce 不 Shuffle，repartition 会 Shuffle）
df.coalesce(20).write.parquet(...)        # 知道大概要几个文件时用它
df.repartition(20, "dt").write.parquet(...)  # 需要按列重新分区时用它

# 根治：开启 AQE 的 Shuffle 分区自动合并，从源头减少小文件
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")

5.4 一张排障决策图

任务慢了/挂了，按这个顺序查：

flowchart TD
    Q1{"任务挂了还是慢？"}
    Q1 -->|挂了| Q2{"Driver 日志里<br/>OOM 关键字？"}
    Q2 -->|Executor 端| F1["加 executor-memory<br/>或增大分区数"]
    Q2 -->|Driver 端| F2["查 collect/toPandas<br/>换成 write 或 take"]
    Q2 -->|文件不存在等| F3["懒执行报错错位<br/>从执行计划往上找源头"]
    Q1 -->|慢| Q3{"Spark UI 看 Stage：<br/>个别 Task 特别慢？"}
    Q3 -->|是 Max远大于Median| F4["数据倾斜<br/>过滤脏key/加盐/AQE"]
    Q3 -->|否 全都慢| Q4{"Shuffle Read/Write<br/>数据量巨大？"}
    Q4 -->|是| F5["能广播的小表广播<br/>列裁剪 过滤下推<br/>提前聚合减少数据量"]
    Q4 -->|否| F6["查上游：小文件太多？<br/>查集群：资源不够排队？"]

第六篇 AI 时代：少写代码，完成大数据开发

时间快进到 AI 编程工具普及之后。回头看，Spark 开发是最适合被 AI 改造的领域之一，因为它的代码模式极其规整：读、变换、聚合、写，套路就那么多。

6.1 AI 能替你做什么，不能替你做什么

flowchart LR
    subgraph AI擅长["AI 做得比人好"]
        A1["自然语言 → PySpark/SQL 代码<br/>按用户30天行为算RFM特征 一句话出码"]
        A2["样板代码生成<br/>Schema 定义 造数脚本 单元测试"]
        A3["报错诊断<br/>贴堆栈 直接定位到懒执行错位/倾斜"]
        A4["口径文档化<br/>把代码翻译成业务能看懂的白话"]
    end
    subgraph AI不擅长["人必须自己把关"]
        B1["业务口径<br/>漏斗是严格顺序还是存在性<br/>AI 不知道你老板要什么"]
        B2["性能直觉<br/>哪里该广播 哪里会倾斜<br/>要看真实数据分布"]
        B3["生产决策<br/>资源参数 重跑策略 数据回补"]
    end

我的实际工作流变化：

以前：写「用户漏斗分析」= 查文档 30 分钟 + 写代码 40 分钟 + 调试 30 分钟。
现在：给 AI 描述清楚——表名、字段、漏斗定义（严格按时间顺序）、输出格式——10 秒出代码，我花 20 分钟 review 口径和边界条件。总耗时砍到三分之一。

但注意：省下来的时间全部应该砸在口径确认和数据校验上。AI 写的代码语法几乎不会错，但它不知道你们的 user_id = '-1' 是脏数据、不知道运营要的是存在性漏斗。这正是第五篇那些坑的价值——AI 时代，踩坑经验不是贬值了，而是成了你最贵的资产，因为代码人人都能生成，能判断代码对不对的人变稀缺了。

6.2 具体怎么干：三个提效姿势

姿势一：需求描述模板化。 给 AI 下指令时固定四段式：

背景：表 ods.user_events，字段 user_id/event_type/ts，按天分区 dt
任务：计算 2022-10-25 的转化漏斗 曝光→点击→加购→下单→支付
口径：严格顺序漏斗，后一步的最早时间必须大于前一步
输出：一行五列，列名用中文

第四篇场景三的完整代码，用这样的提示词一次就能生成得八九不离十。

姿势二：报错即提示词。 Spark 报错堆栈又长又唬人，直接整段贴给 AI，附上你的 Transformation 代码，它对「懒执行错位」「ClassNotFound（依赖没打包）」「分区越界」这类经典错误的诊断准确率很高。

姿势三：让 AI 写测试和校验脚本。 大数据开发最缺的就是测试——数据对不对以前靠人肉抽查。现在让 AI 顺手生成校验 SQL（行数对比、NULL 比例、金额总和与上游对账），质量反而比手工时代更好了。

6.3 冷静的一句话

AI 不会让你"少学 Spark"，它让学习曲线的重心变了：以前背 API 占 60% 的时间，现在这部分 AI 补上了；剩下 40%——架构直觉、业务口径、排障经验——变成了 100% 的核心竞争力。入门变容易了，精通的标准反而更高了。

思考与感悟

写完这篇文章，有几句话想单独说：

1. 学 Spark 的本质是学"分布式的世界观"。 单机时代的直觉——数据随手可得、循环遍历随意、内存无限——全都要扔掉。你要习惯一种新的思维方式：数据是流动的、分区是平行的、Shuffle 是昂贵的、失败是必然的（所以容错设计是一等公民）。这套世界观建立起来之后，学 Flink、学 Kafka、学 ClickHouse 都会很快，因为它们要解决的是同一族问题。

2. 调优经验 = 疼痛的记忆。 没有人看文档能学会处理数据倾斜，都是被凌晨两点的报警电话教会的。所以别怕踩坑，踩了记下来——我这篇第五篇的每个坑，当年都值一个通宵。

3. 离业务近一点，离技术远一点。 做了几年大数据，最大的感悟是：把 ETL 跑得快不算本事，知道这张表给谁用、口径对不对、错了谁会亏钱才是本事。电商场景里，GMV 算错 1% 可能就是一个部门的年终奖。技术只是手段，数据是业务的镜像。

4. AI 时代最值得押注的能力是"判断力"。 生成代码会越来越便宜，判断"这段代码对不对、这个口径该不该这么定、这个架构扛不扛得住双十一"会越来越贵。把 AI 当成一个能力极强但没有常识的实习生：活让它干，锅你来背，所以你必须看得懂它干的活。

与君共勉。

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」的门口，建议按八篇顺序在本地副本集上把每个坑亲手复现一遍——看别人踩坑是故事，自己踩一遍才是经验。

starmall：一个微信小程序电商系统的全栈实战——预约、支付与订单架构解析

Tue, 20 Jul 2021 10:00:00 +0800

starmall：一个微信小程序电商系统的全栈实战——预约、支付与订单架构解析

这是我 2021 年做的一套完整电商系统 starmall（六爻星辰）：微信小程序端 + Java 后端 + PC 管理后台，支持商品购买、老师咨询时段预约、择吉日查询、在线咨询等业务。整理开源出来，写篇文章做一次完整的技术复盘。

前端（uni-app 小程序）：https://gitee.com/soulnew/starmall
后端（Java + 管理端）：https://gitee.com/soulnew/crm_server
技术栈：Spring Boot 2.2 + MyBatis-Plus + MySQL + Redis / uni-app + uView / Vue 2 + Element UI（管理端）
说明：后端是在开源商城 CRMEB Java 版 基础上二次开发的，分销/秒杀/拼团/砍价等营销能力来自底座，预约系统、择吉日、名片、咨询聊天等是自研部分

一、整体架构

graph TD
    MP["微信小程序端<br/>starmall uni-app + uView"] -->|"https://ftmao.com/api/front/**"| API["SpringBoot 单体后端<br/>62 个 Mapper / 23 个前台 Controller"]
    H5["H5 / App<br/>uni-app 多端编译"] --> API
    ADMIN["PC 管理后台<br/>Vue 2 + Element UI + ECharts"] -->|"后台接口"| API
    API --> MYSQL["MySQL 5.7<br/>62 张表 Druid 连接池"]
    API --> REDIS["Redis<br/>token / 订单缓存 / 任务队列 / 配置缓存"]
    API --> WX["微信开放平台<br/>登录 / 支付 V2 / 订阅消息"]
    API --> QN["七牛云 OSS<br/>图片上传"]
    API --> QY["企业微信机器人<br/>部署结果通知"]
    MP -->|"wss://... websocket"| CHAT["咨询聊天服务"]

代码规模：后端约 850 个 Java 文件、12.6 万行；小程序前端业务代码约 1.2 万行；数据库初始化 SQL 全量在仓库里，共 62 张表。后端按业务分包：front（小程序接口）、order/payment、marketing、seckill、task（定时任务）、wechat，以及自研的 appoint（预约）、lunar（黄历）等模块。

二、功能介绍

2.1 商品购买全流程

标准的商城闭环：商品详情（多规格 SKU）→ 立即购买/加购物车 → 确认订单（优惠券、积分抵扣、运费计算）→ 创建订单 → 微信支付 → 轮询支付结果 → 收货评价 → 退款/售后。支付是真实对接的微信支付 V2——后端手工实现 XML 报文 + MD5 签名调统一下单（WeChatPayServiceImpl，746 行），前端弹起 wx.requestPayment，不是 mock。

此外还支持：余额支付、运费模板（满额包邮/指定城市包邮/按件数重量体积三种首续费）、物流查询、自提核销码、再次下单。营销玩法（秒杀、砍价、拼团、优惠券）来自 CRMEB 底座，一应俱全。

2.2 老师咨询时段预约（自研核心）

这是这个项目区别于普通商城的地方——卖的不只是实物商品，还有"老师的时间"：

商品分类为"老师类"时，商品详情页出现一个时段选择器（每天 6 个时段：9/11/13/15/17/19 点）；
teacher_plan 表按「日期 × 时段」预生成号源，被约走的时段前端置灰；
下单时携带 teacherPlanId，创建订单的同一个事务里把该时段标记为已约——号源占用和订单创建要么一起成功要么一起回滚，不会出现"钱付了时段没了"；
号源由定时任务 TeacherPlanTask 每 8 小时自动向前补齐未来 8 天，并清理过期的空闲号源。

2.3 其他自研功能

择吉日查询：4.7 万行黄历数据入库（lunar 系列表），按"宜"事反查吉日，比如查"最近适合搬家的日子"；
在线咨询：基于 WebSocket 长连接的实时聊天，支持文字/语音/图片消息（详见第三章「长连接聊天」）；
老师名片、文章资讯、签到积分、充值、小程序订阅消息提醒；
管理后台：商品/订单/营销/分销/财务/短信/按钮级权限/数据统计大屏（ECharts）。

三、后端能力全景

后端虽然是 SpringBoot 单体，但能力面相当完整：前台 23 个 Controller、62 个 MyBatis Mapper，按业务分包组织：

graph TD
    subgraph M1["业务模块"]
        A1["front 前台接口<br/>23 个 Controller"]
        A2["order / payment<br/>订单与支付"]
        A3["marketing / seckill / bargain / combination<br/>优惠券 秒杀 砍价 拼团"]
        A4["appoint / lunar / businessCard<br/>预约 择吉日 名片（自研）"]
        A5["finance / statistics / export<br/>充值提现 数据统计 Excel 导出"]
        A6["wechat / wechatMessage / sms<br/>微信生态与短信"]
        A7["task<br/>定时任务体系"]
    end
    subgraph M2["公共层"]
        B1["拦截器链<br/>前台 Token / 后台 Token+权限 / Swagger"]
        B2["工具层 RedisUtil / WxPayUtil / CrmebUtil"]
        B3["ThreadLocal 上下文传递当前用户"]
    end
    A1 --> B1
    A2 --> B2
    B1 --> B3

商城主链路之外，后端还有一批容易被忽略的能力：

微信公众号消息自动回复：wechatMessage 模块支持文字/语音/图片/图文四种回复类型，关注、取关、扫码等事件都有对应处理；
模板消息与订阅消息：小程序订阅消息、公众号模板消息的增删查与群发，且发送走异步任务（AsyncWeChatProgramTempMessage 等），不阻塞主流程；
渠道二维码与素材管理：带参数的推广二维码、微信素材的上传管理；
数据导出与统计：POI 实现的 Excel 导出、交易/商品/用户多维统计接口（配合管理端 ECharts 大屏）；
短信与物流：短信验证码/通知、快递物流轨迹查询；
接口文档：Swagger 在线文档 + 仓库内置 admin/app/公共三份离线接口文档。

3.1 长连接聊天（WebSocket）架构

在线咨询是这个系统的"第二前台"，采用的是 WebSocket 长连接 + HTTP 接口的组合方案。部署上两个服务跑在同一台服务器，由 nginx 按路径前缀分流：

graph TD
    MP["小程序聊天页<br/>pages/chat"] -->|"wss://.../websocket/userId/sessionId"| NGX["nginx 按路径分流"]
    MP -->|"HTTP /chat/session/**  /chat/msg/**"| NGX
    MP -->|"HTTP /api/front/**"| NGX
    NGX --> CHAT["聊天服务<br/>WebSocket 长连接 + 会话/消息接口"]
    NGX --> MALL["商城后端 crm_server<br/>SpringBoot 18080"]

从开源的小程序端实现和接口契约，可以看到这套长连接聊天的几个设计要点：

连接即身份：WebSocket 握手 URL 直接携带 userId/sessionId，连接建立的同时就完成了身份识别与会话路由，不需要额外的登录帧；
实时走长连接，持久化走 HTTP：收发消息走 WebSocket（消息体为 JSON）；会话绑定（session/bindSession）、会话列表、删除会话、历史消息拉取（msg/msgList）都走 /chat/ 前缀的 HTTP 接口——长连接管"实时推送"，HTTP 管"可查询、可回溯"，职责分得很干净；
统一的消息类型协议：contentType 1=文字、2=语音（带 contentDuration 时长）、3=图片（先经 user/upload/image 上传拿到 URL，再把 URL 作为消息内容发出）；
语音消息的移动端交互：按住说话（touchstart/touchend 控制录音起止）、上滑取消（touchmove/touchcancel），体验和微信原生聊天对齐；
发送体验乐观化：消息发出后先本地 push 进消息列表立即上屏，send 的 fail 回调再 toast 兜底提示。

需要如实说明：聊天服务端的代码没有随这两个仓库开源（它部署在同一台服务器上，由 nginx 分流），仓库里能看到的生产实现是小程序端；crm_server 里的 com/im/SocketServer.java 只是当时练手的原生 TCP Socket demo（12345 端口），并非线上实现。

四、技术亮点

4.1 下单幂等：两段式 + 唯一键兜底

小程序网络环境下用户双击、重试、断网重发是常态，下单接口必须幂等。这里用了一个两段式设计：

graph TD
    A["order/confirm 确认订单页"] --> B["订单数据序列化存 Redis<br/>key = md5 当前时间<br/>有效期 60 分钟"]
    B --> C["order/create/orderKey 创建订单"]
    C --> D{"第一步:查库判重<br/>StoreOrder.unique = orderKey"}
    D -->|"已存在"| E["直接返回已有订单<br/>不重复创建"]
    D -->|"不存在"| F{"第二步:校验 Redis 缓存<br/>是否过期/被用过"}
    F -->|"过期"| G["拒绝 提示重新确认"]
    F -->|"有效"| H["事务内创建订单<br/>成功后删除缓存"]

unique 字段是最后的兜底——即使 Redis 挂了、缓存丢了，数据库唯一约束也保证同一个 orderKey 不会建出两张单。

4.2 原子扣库存防超卖

库存扣减没有用"先查后改"，而是一条 SQL 完成：

// setSql + 条件改写，数据库层面原子完成
stock = stock - n   且要求   stock - n >= 0

数据库单行更新的原子性天然挡住并发超卖，不需要分布式锁。秒杀/砍价/拼团场景更复杂：同一事务内要扣活动表 + 活动 SKU 表 + 商品表 + 商品 SKU 表四份库存，任何一步失败整体回滚。

4.3 编程式事务包住整个建单过程

创建订单是个多写操作：扣库存、占预约时段、写订单主表、写订单详情、核销优惠券、写订单日志。代码用 TransactionTemplate 编程式事务（而不是 @Transactional 注解）把这一串操作包起来——好处是事务边界精确可控，不会把整个方法（包括不需要事务的远程调用）都圈进去。订单核心逻辑集中在 OrderUtils.java（1500+ 行）和 OrderServiceImpl.java（近 1000 行）。

4.4 支付回调：防重 + 异步化

微信支付的回调处理（CallbackServiceImpl.weChat，448 行）有几个关键点：

解析 XML、校验 return_code/result_code，按 attach 里携带的 userId + type 区分是订单支付还是充值；
已支付直接返回 SUCCESS——微信会多次重推回调，幂等是回调接口的生死线；
事务内完成 updatePaid（置订单已支付）+ 扣积分 + 拼团状态处理；
后续的"慢动作"——发短信、推订阅消息、分销结算——不放在回调里同步做，而是 lPush 进 Redis 队列异步执行，回调接口尽快给微信返回，避免超时重推。

4.5 没有 MQ：Redis List + 定时任务的务实替代

项目没有引入 RabbitMQ/RocketMQ，而是用 Redis List 当队列 + Spring @Scheduled 定时任务消费，撑起了一整套异步任务体系：

graph LR
    A["下单成功<br/>lPush ORDER_AUTO_CANCEL_KEY"] --> Q["Redis List 队列"]
    P["支付成功回调<br/>lPush 后续动作"] --> Q
    Q --> T1["OrderAutoCancelTask<br/>每分钟消费<br/>超时未支付自动取消 + 回滚库存"]
    Q --> T2["自动收货 / 自动好评"]
    Q --> T3["优惠券过期 / 砍价截止<br/>佣金解冻"]
    Q --> T4["TeacherPlanTask<br/>每8小时补齐号源"]

task/order/ 下共有 8 个定时任务。对这个体量的系统，省掉一个 MQ 的部署运维成本，换来的是完全够用的可靠性——这是小项目技术选型上我很认可的一个取舍。

4.6 鉴权链路：UUID Token + Redis + ThreadLocal

没有用 JWT，而是更传统的方案：登录后签发 UUID 存 Redis（按模块区分 key 前缀），拦截器 FrontTokenInterceptor → CheckFrontToken → TokenManagerImpl 逐级校验，通过后把当前用户放进 ThreadLocal 供全链路取用。管理端是 Token + 权限双拦截器。好处是服务端可随时踢人下线（删 Redis key 即可），这是纯 JWT 做不到的。

4.7 其他值得提的实现

订单快照：下单时把购物车内容序列化成 JSON 存进 StoreOrderInfo.info，之后商品改价改名都不影响历史订单的展示；
运费计算引擎：getOrderPriceGroup 支持满额包邮、指定城市包邮（件数 + 金额双条件）、按件数/重量/体积三种首续计费模式；
XSS 转义：用户输入统一 escapeHtml4；
部署脚本：start.sh nohup 启动 + 轮询日志判断启动成功 + 企业微信机器人推送部署结果——单机部署也搞出了仪式感。

五、复盘与遗憾

底座与自研的边界：秒杀/拼团/砍价/分销这些"重"能力直接复用 CRMEB 底座，把精力集中在业务差异化（预约、择吉日、聊天）上——对个人开发者来说这是正确的杠杆；
单体的局限：所有东西在一个 SpringBoot 应用里，定时任务、支付、前台接口互相影响，量大了必然要拆；
原子扣库存的返回值没检查：setSql 扣减失败（库存不足）时影响的行数为 0，但代码没有校验这个返回值，极端情况下会漏判超卖——这是现在回头看想补的一个洞；
聊天服务端未开源：如第三章所述，长连接聊天的服务端实现没有随仓库开源，小程序端和接口契约是完整的，算是开源的一点遗憾。

六、写在最后

这个项目让我完整走了一遍"真实收钱"的系统该有的样子：幂等、事务、防超卖、回调防重、异步补偿——每一个点背后都是电商系统趟过的坑。代码在 https://gitee.com/soulnew/starmall 和 https://gitee.com/soulnew/crm_server，建库 SQL、接口文档都在仓库里，希望能给做小程序商城的朋友一个可参照的完整样本。

电商 on 方糖猫Blog

Spark 从入门到精通：架构原理、RDD/DataFrame、调优踩坑与电商实战全指南

Spark 从入门到精通：架构原理、RDD/DataFrame、调优踩坑与电商实战全指南

第一篇 为什么是 Spark：一台机器装不下的时代

1.1 一个电商场景把问题引出来

1.2 Spark 在生态里的位置

第二篇 架构与原理：代码提交之后到底发生了什么

2.1 一次 Spark 任务的全貌

2.2 懒执行（Lazy Evaluation）：为什么你的代码"没报错"却在运行时炸了

2.3 Stage 是怎么切出来的：宽依赖与窄依赖

第三篇 RDD 与 DataFrame：两代 API 的分水岭

3.1 RDD：能看清每个零件，但要自己造发动机

3.2 DataFrame：你只说"要什么"，优化器替你想"怎么做"

3.3 本地就能跑的完整 Demo

第四篇 电商实战：把知识串成业务

4.1 场景一：订单宽表（每日 ETL）

4.2 场景二：用户行为漏斗（转化率分析）

4.3 场景三：推荐特征工程（用户画像）

第五篇 调优与踩坑：生产环境才是真的战场

5.1 天坑一：数据倾斜（一个 Task 跑三小时，其他三分钟）

5.2 天坑二：OOM（内存不够，但到底谁不够）

5.3 天坑三：小文件灾难（HDFS 的慢性病）

5.4 一张排障决策图

第六篇 AI 时代：少写代码，完成大数据开发

6.1 AI 能替你做什么，不能替你做什么

6.2 具体怎么干：三个提效姿势

6.3 冷静的一句话

思考与感悟

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 与检查清单

starmall：一个微信小程序电商系统的全栈实战——预约、支付与订单架构解析

starmall：一个微信小程序电商系统的全栈实战——预约、支付与订单架构解析

一、整体架构

二、功能介绍

2.1 商品购买全流程

2.2 老师咨询时段预约（自研核心）

2.3 其他自研功能

三、后端能力全景

3.1 长连接聊天（WebSocket）架构

四、技术亮点

4.1 下单幂等：两段式 + 唯一键兜底

4.2 原子扣库存防超卖

4.3 编程式事务包住整个建单过程

4.4 支付回调：防重 + 异步化

4.5 没有 MQ：Redis List + 定时任务的务实替代

4.6 鉴权链路：UUID Token + Redis + ThreadLocal

4.7 其他值得提的实现

五、复盘与遗憾

六、写在最后

第一篇为什么是 Spark：一台机器装不下的时代

第二篇架构与原理：代码提交之后到底发生了什么

第四篇电商实战：把知识串成业务

第五篇调优与踩坑：生产环境才是真的战场

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

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

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

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

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

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

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