Java on 方糖猫Blog

C 端 IPTV 产品的 Java 高并发架构设计：高可用、高性能、零信任与缓存一致性

Mon, 19 Oct 2026 10:00:00 +0800

C 端 IPTV 产品的 Java 高并发架构设计：高可用、高性能、零信任与缓存一致性

过去几年我一直在做一个面向海外的 C 端 IPTV 产品（STB 机顶盒 + 移动端，多品牌多租户，跑在 AWS 上）。这篇文章是我对这套系统架构的复盘：高并发、高可用、高性能、高安全、缓存一致性这几件事我们分别是怎么做的、踩过什么坑。过程中我们落地了不少 Netflix 的开源组件和公开实践（Hystrix、EVCache、Zuul 的网关思想、混沌工程等），但每一个决策都是经过我们自己生产环境验证或修正的，不是照搬。文中方案细节来自真实的系统设计文档（Video Cloud 目标模型、vod-auth、CloudRouter、DRM、网盘整改等），脱敏后分享。

一、先搞清楚对手：C 端 IPTV 的流量模型

设计之前先看清流量的形状。这是我做这套系统第一天就逼自己回答的问题：

特征	说明	架构含义
潮汐效应极强	晚 8 点 - 11 点是高峰，大促、球赛、爆款剧上线时流量成倍脉冲	弹性伸缩 + 削峰，按高峰容量做预案
读极多、写极少	EPG 节目单、Meta 元数据、Layout 下发占了 9 成以上流量	缓存优先，读路径尽量不打 DB
播放鉴权是超级热点	每次起播、切台都要鉴权取播放链接，QPS 随在线用户数线性涨	热点接口单独优化（缓存 + 短 TTL + 滑动续期）
设备在线心跳	app 轮询 session，百万级设备定时上报	心跳服务独立部署，写路径异步化
多品牌多租户	同一套系统服务多个品牌（巴西、俄语区等）	分库隔离爆炸半径，account_id 前缀区分品牌

这个流量形状——读多写少、晚间高峰、播放路径是生命线——决定了后面所有的架构取舍。

二、总体架构：一张图看清全貌

graph TB
    subgraph 终端
        STB["STB 机顶盒"]
        APP["移动 App"]
        WEB["Web / Portal"]
    end

    subgraph 接入层
        ELB["AWS ELB"]
        APISIX["APISIX 网关<br/>限流 Sentinel / WAF / 鉴权前置"]
    end

    subgraph 微服务层
        AUTH["vod-auth<br/>登录注册 / 账号 / 子账号"]
        SESS["common-session<br/>会话管理"]
        META["vod-meta-api<br/>元数据 / Layout / EPG"]
        PROF["profile<br/>观看历史 / 收藏 / 偏好"]
        CLOUD["vod-cloud<br/>个人网盘"]
        ROUTER["CloudRouter<br/>播放链接路由"]
        DRM["drmlicense<br/>DRM 鉴权与 license 下发"]
    end

    subgraph 数据层
        MYSQL["MySQL RDS<br/>按品牌分库"]
        REDIS["Redis Cluster<br/>Session / 验证码 / Meta 缓存"]
        METAREDIS["Meta 专用 Redis Cluster"]
        ES["Elasticsearch<br/>检索字段"]
        KAFKA["Kafka MSK<br/>Meta 同步 / 网盘同步"]
    end

    subgraph 内容侧
        STREAM["Streaming 流媒体"]
        CDN["CDN / Squid 边缘缓存"]
        CP["cloudProxy<br/>第三方网盘适配"]
    end

    STB --> ELB
    APP --> ELB
    WEB --> ELB
    ELB --> APISIX
    APISIX --> AUTH
    APISIX --> SESS
    APISIX --> META
    APISIX --> PROF
    APISIX --> CLOUD
    APISIX --> ROUTER
    ROUTER --> DRM
    ROUTER --> STREAM
    STREAM --> CDN
    STREAM --> CP
    META --> METAREDIS
    META --> ES
    AUTH --> MYSQL
    AUTH --> REDIS
    SESS --> REDIS
    CLOUD --> KAFKA
    META --> KAFKA

几个关键决策，后面逐章展开：

接入层：链路是 app -> ELB -> APISIX -> vod 微服务，限流用 Sentinel，网关做鉴权前置和 WAF。网关选型时我认真研究过 Netflix Zuul 2 从同步阻塞改异步非阻塞的历程——结论是网关本身绝不能成为瓶颈。我们体量没那么大，APISIX（底层同样是 Nginx + Lua 的高性能异步模型）已经够用。
服务拆分：按业务域拆（Auth / Profile / Meta / Cloud / Session），不是按技术层拆。领域拆分的完整过程在视频系统 DDD 实战里写过。
数据层：MySQL 按品牌分库（{brand}_account_db 等）；Redis 承载 Session、验证码、热点数据；Meta 用独立的 Redis Cluster 全量缓存，与业务缓存物理隔离；检索字段入 ES。
异步化：Kafka（MSK）只干两件事——Meta 同步管道和网盘同步，不滥用。这是我给自己立的规矩：每加一个 MQ topic 都要回答「同步调用为什么不行」。

三、高并发：把流量挡在离用户最近的地方

高并发的核心心法就一句：每一层都尽量把请求消化掉，别让它穿透到下一层。越靠近 DB 越贵。

3.1 网关层：第一道削峰闸

我们在网关层做了三件事：

限流：APISIX 自带 limit-req / limit-count 插件做粗粒度限流，Sentinel 做服务级细粒度熔断限流（现网组合就是「ELK + Skywalking + Sentinel（APISIX）」）。
鉴权前置：明显非法的请求（无 token、签名错误、UA 黑名单）在网关直接 401/403，不放行到业务服务。被攻击时这一层挡掉的流量经常比业务层处理的还多。
静态配置下发走 CDN：/ui/cfg/v1、/layout/v1 这类终端配置接口，内容变化频率低，直接走 CDN 缓存，源站只承担回源请求。

3.2 热点接口：播放鉴权链接的缓存设计

CloudRouter（播放源路由服务）是我手里最热的路径：每次起播都要按 logicStreamId 换真实的下载/播放链接。我做的设计非常直接：

graph LR
    A["App 起播请求<br/>logicStreamId"] --> B{"查 Redis"}
    B -- "命中" --> C["刷新 TTL 滑动续期<br/>直接返回链接"]
    B -- "未命中" --> D["查 MySQL 两表<br/>logic_stream + file_source"]
    D --> E["构建下载链接 DownloadBO<br/>link / fileSize / expired"]
    E --> F["写回 Redis"]
    F --> G["返回"]

三个细节值得说：

命中即续期（滑动 TTL）：热播内容的链接永不过期，冷内容自然淘汰——不需要人工预热。这个设计替我省掉了整个「热点内容运营」的麻烦。
缓存对象自带过期时间：链接本身有 expired 字段，客户端在链接到期前会重新请求，和缓存 TTL 是两层独立的过期机制，互不相信。
失败快速抛出：查不到直接抛业务异常，不做 fallback 到第三方存储的慢路径——播放链路每一毫秒都值钱。

3.3 多级缓存：L1 + L2

纯 Redis 方案在超热点 key 上依然会打满单个分片（新片上线当晚的 metaId 我真实遇到过）。为了解决这个问题我研究了 Netflix 的 EVCache——它的多副本加客户端本地缓存思路给了我启发，但我们体量用不上 EVCache 全套，于是我基于 Caffeine（L1 进程内缓存）+ Redis（L2）自己实现了一个两级缓存框架并开源，见我开发的 keCache：面向 Spring Boot 3 的 L1 + L2 两级缓存框架，要点：

L1 短 TTL（秒级），扛住瞬时洪峰；
L1 失效消息走 Redis Pub/Sub 广播，保证多实例间 L1 不一致的窗口可控；
序列化用 Kryo，比 JDK 序列化小 3-5 倍。

3.4 写路径异步化：MQ 削峰

写少但集中的场景（新片上线批量导入 Meta、网盘大规模刷新）我全部走 Kafka：

graph LR
    A["vod-sync-dispatcher<br/>每 30 秒轮询上游片源"] --> B["Kafka MSK"]
    B --> C["vod-imdb-meta-sync<br/>元数据入 Redis + ES"]
    D["vod-cloud-sync-dispatcher"] --> B
    B --> E["vod-cloud-sync-worker<br/>刷新网盘"]
    F["http2Msk<br/>大数据 HTTP 回调转 MQ"] --> B
    B --> G["偏好计算<br/>you may like"]

生产者-消费者模型 + MQ 缓冲，让上游脉冲（片源方一次推几万条 meta）被摊平成消费者能吃得动的匀速流。当时的 MQ 选型过程见消息队列总结：RabbitMQ、Kafka、RocketMQ 与 Redis MQ。

另一个异步化的例子是我设计的转码调度：Quartz + DB 状态机驱动，每个片源转出 1-3 个分辨率、每个分辨率一个任务，用「动态归一化权重调度算法」分配执行器（priority = 客户权重 / 活跃任务数，兼顾多客户公平与并发槽位控制），30 分钟轮询任务进度。慢不要紧，稳和公平才要紧——这是典型的「离线任务用状态机换可靠性」。

四、高可用：假设一切依赖都会挂

我做高可用的两条心法，是从 Netflix 的工程实践里学来并在我们系统里反复验证过的：Design for failure（为失败而设计）和 Blast radius（控制爆炸半径）。落地到我们系统：

4.1 熔断、降级与兜底重试

熔断：我们早期直接用 Netflix 开源的 Hystrix 做熔断隔离，Hystrix 停更后迁移到 Resilience4j（网关层用 Sentinel）。工具换了，规则不变：下游超时率/错误率超阈值就熔断，快速失败，绝不线程排队等死。Hystrix 的线程池隔离思想对我们影响很大——核心链路（登录、起播）和非核心链路（埋点上报）的资源池必须分开。
降级而非失败：Meta 自动匹配失败时我定的策略是降级创建默认元数据，不影响文件源状态——内容能播永远比信息完美重要。
兜底重试：CloudAsset 的异常处理是我给全系统定的统一模式——3 次以内本轮调度重试，超过 3 次任务进失败状态，由独立的失败任务调度器兜底。关键设计点：主流程不被重试拖死，失败任务有独立通道排队消化，互不阻塞。

graph TB
    A["任务执行"] --> B{"成功?"}
    B -- "是" --> C["完成"]
    B -- "否, failCount+1"] --> D{"failCount ＞ 3?"}
    D -- "否" --> A
    D -- "是" --> E["status = fail"]
    E --> F["独立失败任务调度器<br/>定时扫描兜底重试"]
    F --> A

后来我把这类「一定要跑到」的可靠执行逻辑抽成了通用组件开源，见我开发的 KE Reliable Executor。

4.2 多租户隔离：分库就是隔舱

多品牌共享一套代码，但我在数据层做了物理隔离：

MySQL 按品牌分库（{brand}_account_db、{brand}_profile_db），公共数据在 vod_meta_db；
account_id 前缀区分品牌（MFC:11、TVELA:12、WAKA:13），应用层强制路由；
实体普遍带 env / vnoId 字段，logicStreamId 内嵌环境标识。

某品牌数据被打爆、误删、需要回滚时，影响面天然被限制在单库内。这就是水密隔舱——后来某品牌做数据订正时我真切体会到这个设计的价值。

4.3 依赖解耦：订阅模式

DRM 链路里我有个坚持：drmlicense 不直接依赖 Headend 和 drmencryptor 的在线接口，而是以订阅模式收 DrmContentInfoBO 和 ContentKeyBO，自己组装 logicalStream 与 PSSH 的关系。上游挂了，license 下发用已订阅到的数据照常工作。原因是算术：同步调用是可用性的乘法，异步订阅是加法——一个可用性 99.9% 的服务同步串依赖十个同样 99.9% 的服务，链路可用性就只剩 99% 了。

4.4 混沌工程：轻量版就够

Netflix 的 Chaos Monkey 是随机杀生产实例，逼所有服务习惯「邻居随时消失」。我评估后没敢直接上生产，但保留了这个思想的两个轻量实践：预发环境定期随机关停单个实例观察告警与自愈；每个季度做一次依赖演练（手动切断 Redis 从库、Kafka 单 broker），验证降级路径真的能用。我的原则：降级方案不演练就等于没有——每次演练几乎都能发现某条降级路径已经悄悄失效。

五、高性能：把钱花在读路径上

高性能章节不长，因为大部分事前面已经做了。补几个我做过的针对性的点：

优化点	做法
Meta 全量入内存	元数据全量进专用 Redis Cluster，终端 `/root/v1`、`/tree/v1` 等接口零 DB 访问
检索走 ES	只有关键检索字段入 Elasticsearch，不全量双写
播放内容边缘缓存	Streaming 前置 Squid + CDN，热点片源命中边缘节点，源站只承担回源（对应 Netflix Open Connect 的角色，我们用商用 CDN 实现）
大表治理	观看历史表现网 2-3 亿行，是我一直盯着的最大风险点：每天定时任务删 90 天前历史 + 按账号双表拆分（设备账号/普通账号）
JVM 与连接池	G1/ZGC、HikariCP 连接池按「连接数 = (核数 × 2) + 磁盘数」起步压测调优，慢 SQL 进 Skywalking 告警

原则：性能优化的 80% 是让请求根本到不了慢的地方，剩下 20% 才是调参数。

六、缓存一致性与缓存高可用

这是全文我最想细说的一章。缓存是性能的来源，也是我事故最多的地方。

6.1 一致性策略：先写 DB，后删缓存

vod-auth 的账号数据我用的是标准的 Cache Aside + 写后删除：先写 DB，成功后再删缓存，下次读时回源重建。为什么选「删除」而不是「更新」？我想清楚过：「先写 DB 再删缓存」只有在「读线程恰好踩着写间隙回源了旧值」的极端窗口才会短暂不一致，而「更新缓存」在并发双写下会乱序覆盖出脏数据。删除的失败模式是 miss（回源一次，便宜），更新的失败模式是脏数据（播错内容，贵）。

对一致性要求更高的场景（套餐权益、付费状态），我在删除之上再加一层：

延迟双删：写 DB → 删缓存 → 延迟 N 秒 → 再删一次，兜住间隙回源；
或用 MQ 发缓存失效消息，由消费者负责删除 + 失败重试，把「删缓存失败」这个尾巴也闭环掉。

6.2 缓存三大经典问题的组合拳

问题	我遇到的场景	解法
穿透	恶意刷不存在的 metaId / accountId	布隆过滤器拦截 + 空值短 TTL 缓存（30 秒）
击穿	爆款剧上线，热点 key 过期瞬间	逻辑过期 + 互斥重建：value 里带逻辑过期时间，过期后只放一个线程回源，其余返回旧值
雪崩	大量 key 同 TTL 同时到期	TTL 加随机抖动（基础值 ± 20%）+ Redis Cluster 多主分摊

逻辑过期方案有个工程细节：回源重建要用分布式锁（Meta 绑定我用的就是分布式锁，获取失败快速失败、重新调度），且锁的 TTL 必须大于回源耗时，finally 里释放——我在 CloudAsset 方案里专门写了「任何异常都会释放分布式锁、清除 ThreadLocal」，这是血泪经验，锁泄漏一次就够排查一晚上。

6.3 缓存自身的高可用

Redis Cluster 多主 + 从：Meta 缓存我用独立集群，和 Session/验证码的集群物理隔离——Meta 集群被打挂不影响用户登录。
多级缓存兜底：Redis 整体不可用时，L1（Caffeine）还能扛住读过期窗口，服务降级而不是全灭。
从 EVCache 学到的运营观：我研究 Netflix EVCache 时最大的收获不是 memcached 本身，而是他们把缓存当成 tier-0 服务运营——独立容量规划、独立监控、独立 SLO。我照这个思路给缓存集群配了和业务服务同级别的告警与容量评审。缓存在高并发系统里不是优化项，是一级基础设施——这点很多团队要到出事才懂，我庆幸自己学得早。

七、零信任安全与必要防御

7.1 零信任：永不信任，始终验证

我们的安全体系是在几次整改后逐步按零信任思路重建的——内网不再等于可信，每一次调用都要验证身份，不论它来自哪里。落地到我的系统，是这几件事：

用户侧：accessToken（JWT，sub = accountId）+ 播放票据 tk12（内含 expireTime / accountId / streamId，由平台密钥签发）。App 起播时两个都要验，token 验「你是谁」，tk12 验「你能不能播这条流、能播到什么时候」。
设备侧：账号卡与设备绑定（ac_device_binding），device_limit 限制并发设备数，挤掉盗号共享的盈利空间。
服务间：内部接口（/internal-api/...）不走公网网关，服务间调用带服务身份凭证。我评估过 mTLS + SPIFFE 这套工作负载身份方案（Netflix 零信任改造用的就是这条路），对我们体量偏重，最终落地为「内部接口不暴露 + 调用方白名单」，等规模上来再升级。
最小权限：cloudProxy 是我专门做的收敛层——把对第三方网盘（Mega 等）的所有访问收敛成一个适配层，只暴露 checkPassword 和 getDownloadLink 两个接口，业务服务根本不接触第三方凭证。

7.2 一次真实的安全整改：网盘密码泄露

这是我亲手推动的整改，值得完整复盘。背景：网盘打包工具生成的加密网盘包里含账号 + 加密后的登录密码，加解密密钥一旦泄露，所有网盘账号密码全部泄露。

整改分两步走：

第一步，密码不落地。 新网盘包不再写密码，改为写入与网盘账号一一对应的 shareKey（UUID）。导入时只校验 shareKey 一致性，通过后把网盘与用户关联。按网盘包 version 字段区分新老包走新旧两条校验逻辑，平滑迁移——存量兼容是安全改造里最容易被低估的工作量，这一步我花的精力比新逻辑本身还多。

第二步，密钥体系升级。 对称加密改 RSA 非对称加密：

graph TB
    A["CP / Reseller<br/>只拿到 RSA 公钥"] --> B["公钥加密网盘包<br/>公钥泄露也无法解包"]
    C["VNO 上传私钥<br/>加密保存于平台 pkg_rsa_key 表"] --> D["导入时按 VNO 查私钥"]
    B --> E["网盘包带签名<br/>含 pkgId + keyId"]
    E --> D
    D --> F["先验签再解密<br/>解密成功才关联用户"]

配套我设计的密钥轮换机制：平台同时最多两个 Key 生效；更新时旧密钥先进入最长 30 天缓冲期，再生成新密钥对；存在生效中的旧密钥则不允许再次更新——防止轮换频率失控导致历史包无法解密。

另外扫码登录链路我也推动做过同类加固：扫码站点从 S3 静态托管（明文登录）迁移到托管服务并接入加固方案，鉴权统一收口到 vod-auth。

7.3 接口消息体加密：HTTPS 之上的第二道锁

有人会问：全站都上 HTTPS 了，为什么还要在应用层再加密一次消息体？我的理由有三个，都来自实际教训：

HTTPS 防不住终端侧的抓包。Charles/Fiddler 挂个代理证书，App 和网关之间的明文报文一览无余——协议字段、业务参数、token 用法全暴露。C 端 App 发出去的那一刻起，客户端环境就不可信。
HTTPS 到网关就终止了。TLS 在 ELB/APISIX 卸载后，内网转发的是明文；零信任的原则是内网也不可信，敏感报文在网关之后依然应该处于加密状态。
IPTV 场景的特殊性：播放鉴权、充值、账号接口一旦被逆向出报文格式，黑产就可以脱离 App 直接伪造请求刷接口。

我设计的方案是 TLS 为底线 + 应用层 AES 加密消息体，核心链路如下：

graph LR
    A["App 启动<br/>ECDH 密钥协商<br/>网关公钥经 SSL Pinning 校验"] --> B["得到会话密钥 sessionKey<br/>按 session 绑定"]
    B --> C["业务请求<br/>AES-256-GCM 加密 body"]
    C --> D["明文头带 token + 时间戳<br/>+ nonce + HMAC 签名"]
    D --> E["网关统一解密过滤器<br/>验签名 / 验时间窗 / 验 nonce"]
    E --> F["业务服务收到明文<br/>响应同样加密回传"]

工程上的几个取舍，都是试出来的：

密钥协商用 ECDH，不用硬编码密钥。早期图省事在 App 里内置过 AES 密钥，App 被反编译后全线失守，改成登录/启动时 ECDH 动态协商、密钥绑定 session、服务端定期强制轮换。SSL Pinning（证书固定）挡住大部分中间人代理，让 ECDH 协商本身不被劫持。
AES-256-GCM 而不是 CBC：GCM 自带完整性校验（AEAD），加密和防篡改一次完成；密钥 nonce 绝不复用。
头部明文、body 加密：token、时间戳、nonce、签名放明文头里，网关不解密就能先做限流和鉴权前置；body 整体加密，解密收敛在网关的统一过滤器里，业务服务无感知——加解密逻辑散落进每个 Controller 是维护灾难。
不是所有接口都加密。EPG、Meta 这类公开内容接口只走 HTTPS + 签名；登录、充值、播放鉴权、账号操作这些敏感接口才上消息体加密。全量加密的 CPU 成本和排查问题的痛苦不成比例——加密后的日志排障要靠专门的脱密工具，这也是成本。
绝不自研算法。所有原语都用成熟实现（AES-GCM、ECDH、HMAC-SHA256），自己拼协议可以，自己造算法不行。

7.4 必要防御：防攻击清单

攻击面	我们的防御手段
接口刷量 / CC 攻击	网关限流 + Sentinel 熔断；登录、验证码接口按 IP + 账号双维度计数
短信/邮件轰炸机	验证码存 Redis 带 TTL，验证成功后立即删除防重放；单账号/单 IP 频次限制
重放攻击	请求带时间戳 + nonce，token 短过期
抓包 / 中间人	HTTPS + SSL Pinning + 敏感接口消息体加密（见 7.3）
越权访问	tk12 绑定 `accountId + streamId`，换账号播放直接鉴权失败
篡改网盘包	RSA 签名验签，验签不过不解密
撞库 / 盗号	登录失败计数锁定（`account_black_list`）、设备绑定、子账号体系隔离
敏感信息外泄	交接文档脱敏（我们的交接文档里曾出现明文环境密码，是我抓出来的典型反面教材）；日志脱敏；DB 密码字段只存哈希

7.5 DRM：内容安全的最后一道门

DRM 链路的安全设计我同样按零信任思路做：ContentKey 由独立密钥服务（drmencryptor）管理，先查缓存没有再向外部 DRM 厂商申请并落库缓存；播放优先走离线 license（有缓存用缓存），PSSH 异常才降级在线 license。license 本身带过期时间，App 本地不持久化密钥。系统支持 Goose DRM 与 Multi-DRM（Widevine）切换，切换动作就是删旧流加新流——密钥体系与业务流解耦，这个设计让后来的 DRM 厂商迁移几乎没动业务代码。

八、可观测性：没有度量就没有高可用

我们的现网组合：ELK 日志 + Skywalking 链路追踪 + Prometheus/Grafana 指标 + Nacos 配置中心，每个子系统独立 ES index。

我压测过的容量数据（v7.16 集群）：只写日志约 11 万条/秒，只写 Skywalking 约 2 万条/秒，混合写时日志 6 万 + 链路 1 万/秒。

血泪教训：周一高峰 Skywalking 曾出现 4 小时写入延迟，日志量增长也让 Logstash 排队。事后我立了两条规矩：

日志与链路采样分离：高峰期链路数据降采样，保住日志；两者绝不能互相拖死。
本地日志保留 30 天，crontab 定时清理——磁盘写满导致的 ELK 雪崩比业务故障还常见。

我还坚持一点：告警要打在用户可感知的指标上（起播成功率、鉴权失败率、链接过期率），而不是只打 CPU 内存——机器好好的但用户看不了，是最尴尬的监控盲区。服务间的依赖关系复杂到一定程度后，「告警来了不知道谁影响了谁」会成为新问题，Netflix 为此专门做过一套服务拓扑系统，我研究过它的实现并整理了笔记：Netflix 服务拓扑系统笔记。

九、总结：一张 checklist

维度	我采用的核心手段	用到的 Netflix 开源组件 / 实践
高并发	网关限流、缓存优先、MQ 削峰、多级缓存	Zuul 2 异步化思想、EVCache 启发 keCache
高可用	熔断降级、失败兜底调度器、多租户分库隔离、订阅模式解耦	Hystrix（后迁 Resilience4j/Sentinel）、Chaos Monkey 轻量版
高性能	Meta 全量入内存、ES 检索、CDN/Squid 边缘缓存、大表治理	Open Connect 的边缘缓存角色
缓存一致性	先写 DB 后删缓存 + 延迟双删、逻辑过期防击穿、随机 TTL 防雪崩	EVCache 的缓存运营观
零信任	双票据鉴权、设备绑定、内部接口白名单、最小权限适配层	零信任改造思路（mTLS/SPIFFE 评估后暂缓）
攻击防御	网关 WAF/限流、验证码防重放、RSA 验签、黑名单、敏感接口消息体加密	—
可观测	ELK + Skywalking + Prometheus，日志链路采样分离	服务拓扑系统的思路

最后一句实话：这套架构没有一样是发明出来的，全部是踩坑踩出来的。网盘密码泄露、Skywalking 四小时延迟、2-3 亿行的历史大表——每个设计决策背后都有一次事故或一次险些事故。Netflix 的开源组件和博客帮我少踩了很多坑，但终究要自己踩过才知道坑有多深。架构师的职责不是画出完美的图，而是让每个坑只踩一次。

我开发的keCache：面向 Spring Boot 3 的 L1 + L2 两级缓存框架

Thu, 04 Sep 2025 14:16:44 +0800

在高并发 Java 业务里，缓存几乎是标配。但“用缓存”这件事从来不是只有“加 Redis”一种答案：本地缓存快却解决不了多机一致，Redis 能共享却多了网络与序列化开销。我最近实现一个把两者结合起来、并针对集群一致性做了不少细节处理的小而美框架 —— keCache，现在做一次系统梳理。

一、keCache 是什么

keCache 是一个基于 Java 17 + Spring Boot 3.x + Caffeine + Redisson 的本地缓存框架，采用 L1（Caffeine 本地缓存）+ L2（Redis 分布式缓存） 两级架构，同时提供：

声明式注解（@LocalCacheable、@LocalCacheEvict、@LocalCacheClear）
编程式 API（CacheTemplate）
集群失效广播（Redisson Pub/Sub）
空值保护（防止缓存穿透）
数据一致性校准 SPI

它的定位不是“又一个 Redis 客户端”，而是“让本地缓存能在集群环境下安全使用”的胶水层。

1.1 整体架构

graph TD
    App[业务 Service] -->|注解或 API| Facade["CacheTemplate / AOP 切面"]
    Facade --> L1{L1 Caffeine}
    L1 -->|命中| Return[返回数据]
    L1 -->|未命中| L2{L2 Redis}
    L2 -->|命中| Deserialize[Jackson 反序列化]
    Deserialize --> Backfill[回填 L1]
    Backfill --> Return
    L2 -->|未命中| Load["执行方法 / 加载数据"]
    Load --> Write["写入 L1 & L2"]
    Write --> Return
    PubSub["Redisson Pub/Sub"] -->|失效事件| L1
    Calibration[CalibrationProvider SPI] -->|定时校准| L2

二、开源地址

Gitee：https://gitee.com/soulnew/ke-cache

三、为什么需要 keCache？与纯 Redis / 纯 Caffeine 的对比

很多团队在选择缓存方案时，常常在“纯 Redis”和“纯 Caffeine”之间摇摆。keCache 试图在二者之间取得平衡。

维度	纯 Caffeine	纯 Redis	keCache（L1 + L2）
读取延迟	极低（内存内）	较高（网络 + 序列化）	热数据近似 Caffeine，冷数据走 Redis
单机内存压力	大（全部数据在本 JVM）	小（Redis 承担）	小（只有热数据在本地）
集群一致性	无，各节点独立加载	强一致	最终一致，写操作广播失效
缓存穿透保护	需自行实现	需自行实现	内置 NullValue 短 TTL 保护
多机共享	不支持	支持	支持（L2 Redis）
适用场景	只读/准静态数据、单节点	写多读少、需要强一致	读多写少、可接受最终一致

3.1 相比纯 Caffeine 的好处

Caffeine 是 JVM 内缓存的佼佼者，但它天然只服务于当前进程。在集群部署时：

每台机器都要独立加载数据，导致数据库在启动/预热时被打 N 次。
数据更新后其他节点无法感知，容易出现 A 节点已更新、B 节点仍读旧值的“ stale data ”问题。
内存占用随节点数线性增长，同样一份热数据在每个 JVM 都存一份。

keCache 用 L2 Redis 作为共享底座：首次加载从 Redis 取，后续读请求命中本地 Caffeine；写操作时通过 Redis Pub/Sub 通知其他节点清除本地缓存。这样既保留了 Caffeine 的本地速度，又解决了多机一致性难题。

3.2 相比纯 Redis 的好处

Redis 虽然性能好，但毕竟跨进程：

网络 RTT 不可忽视：高频读取时，哪怕 1ms 也会累积成可观的延迟。
序列化/反序列化开销：Java 对象要先转成 JSON/二进制，再还原，CPU 和 GC 都有压力。
热点 Key 风险：大促期间某些热 Key 会被反复打到同一个 Redis 节点。

keCache 把最热的数据放在本地 JVM 里，只有本地未命中或更新时才访问 Redis，显著降低网络和序列化开销，也分散了 Redis 热点压力。

3.3 方案选型速查

flowchart TD
    Start([开始选缓存方案]) --> Q1{是否需要多机共享?}
    Q1 -->|否| Q2{数据是否只读 /<br/>准静态?}
    Q2 -->|是| Caffeine[纯 Caffeine<br/>简单高效]
    Q2 -->|否| Q3{能否接受最终一致?}
    Q3 -->|能| KeCache[keCache<br/>L1 + L2 加速]
    Q3 -->|否| RedisOnly[纯 Redis /<br/>DB 强一致]
    Q1 -->|是| Q4{写多读少 /<br/>强一致?}
    Q4 -->|是| RedisOnly
    Q4 -->|否| KeCache

3.4 一句话总结

keCache 适合“读多写少、能接受最终一致、希望兼顾本地速度与集群共享”的业务场景；如果你的业务对实时一致性要求极高（如库存扣减、金融记账），建议直接走 Redis 或数据库方案。

四、核心能力速览

能力	说明
声明式缓存	`@LocalCacheable` / `@LocalCacheEvict` / `@LocalCacheClear`，支持 SpEL
多键映射	`@LocalCacheable.Multi` 一次方法返回构建多个索引 key
编程式 API	`CacheTemplate.get/put/evict/clear`，类型安全
二级缓存	L1 Caffeine + L2 Redis，读时先 L1 再 L2，未命中回调加载
空值保护	DB 不存在的 key 缓存短 TTL 的 NullValue，防止缓存穿透
集群一致性	Redisson Pub/Sub 广播失效事件，其他 JVM 清除本地 L1
自失效屏蔽	事件携带 `sourceId`，本机忽略自己发出的事件，避免误清本地缓存
广播风暴防护	远程失效事件只清 L1，不再次广播
数据校准	`CalibrationProvider` SPI，支持时间戳扫描或 CDC 扩展

4.1 读取流程

flowchart TD
    Start([读请求]) --> L1[查 L1 Caffeine]
    L1 -->|命中| A[直接返回]
    L1 -->|未命中| L2[查 L2 Redis]
    L2 -->|命中| Deserialize[Jackson 反序列化]
    Deserialize --> Backfill[回填 L1]
    Backfill --> Return[返回数据]
    L2 -->|未命中| Method[执行真实方法]
    Method --> NullCheck{结果是否为 null?}
    NullCheck -->|是| NullVal[写入 NullValue 到 L1/L2<br/>TTL: null-value-ttl]
    NullCheck -->|否| RealVal[写入真实值到 L1/L2]
    NullVal --> ReturnNull[返回 null]
    RealVal --> Return

4.2 写入与集群失效广播流程

sequenceDiagram
    participant A as 节点 A（写请求）
    participant DB as 数据库
    participant R as Redis（L2）
    participant P as Redis Pub/Sub
    participant B as 节点 B
    participant C as 节点 C

    A->>DB: 更新数据
    A->>R: 删除/覆盖 L2 Key
    A->>P: 发布 EvictEvent（携带 sourceId）
    A->>A: 清除本机 L1

    P->>B: 接收 EvictEvent
    B->>B: sourceId ≠ 本机？
    B->>B: 清除本地 L1
    Note over B: 只清 L1，不再次广播

    P->>C: 接收 EvictEvent
    C->>C: sourceId ≠ 本机？
    C->>C: 清除本地 L1

五、快速开始

5.1 引入 Starter

<dependency>
    <groupId>com.keke</groupId>
    <artifactId>kecache-spring-boot-starter</artifactId>
    <version>1.0.0-SNAPSHOT</version>
</dependency>

5.2 启用缓存

import com.keke.kecache.starter.annotation.EnableKeCache;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableKeCache
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

5.3 基础配置

local-cache:
  enabled: true
  namespace: kecache.sample
  default-ttl: 30m
  null-value-ttl: 5m

  caffeine:
    default:
      maximum-size: 1000
      expire-after-write: 10m
      record-stats: true

  redis:
    address: redis://127.0.0.1:6379
    broadcast-channel: kecache:evict
    default-ttl: 30m

  calibration:
    enabled: false

5.4 声明式使用示例

@Service
public class AccountService {

    @LocalCacheable(
        cacheNames = "tve_account_info",
        key = "'id_' + #accountId",
        unless = "#result == null"
    )
    public AccountInfo getById(long accountId) {
        return accountDao.loadById(accountId);
    }

    // 一次查询构建多个索引 key
    @LocalCacheable.Multi({
        @LocalCacheable(cacheNames = "tve_account_info", key = "'id_' + #accountId"),
        @LocalCacheable(cacheNames = "tve_account_info", key = "'nm_' + #result.accountName", unless = "#result == null")
    })
    public AccountInfo getByIdMultiIndex(long accountId) {
        return accountDao.loadById(accountId);
    }

    @LocalCacheEvict(cacheNames = "tve_account_info", key = "'id_' + #accountId")
    public void updateById(long accountId, AccountInfo info) {
        accountDao.update(accountId, info);
    }

    @LocalCacheClear(cacheNames = "tve_account_info")
    public void clearAll() {
        accountDao.clear();
    }
}

5.5 编程式使用

@Service
public class AccountService {

    @Autowired
    private CacheTemplate cacheTemplate;

    public AccountInfo getById(long accountId) {
        return cacheTemplate.get("tve_account_info", "id_" + accountId, key -> {
            return accountDao.loadById(accountId);
        });
    }
}

六、模块结构

graph TD
    Parent[kecache-parent] --> API[kecache-api<br/>注解 / SPI / 配置模型 / 事件]
    Parent --> Core[kecache-core<br/>统一门面 / Key策略 / 空值保护]
    Parent --> Caffeine[kecache-provider-caffeine<br/>L1 Caffeine 实现]
    Parent --> Redisson[kecache-provider-redisson<br/>L2 Redis + 失效广播]
    Parent --> Calibration[kecache-calibration<br/>数据一致性校准]
    Parent --> Starter[kecache-spring-boot-starter<br/>自动配置 + AOP]
    Parent --> Sample[kecache-spring-boot-sample<br/>示例应用 + 测试]

    Starter --> API
    Starter --> Core
    Core --> Caffeine
    Core --> Redisson
    Core --> Calibration

七、关键约定（写代码前必读）

L1 key：cacheName#dataKey
L2 key：{namespace|cacheName}:dataKey（使用 hash tag 避免集群模式下 slot 分散）
默认读写策略：Cache-Aside
失效广播频道：默认 kecache:evict
序列化：Jackson 启用 default typing，保留类型信息

八、使用注意点与避坑指南

8.1 Redis 是硬性依赖

L2 缓存和失效广播都依赖 Redis，测试与运行前请确保 Redis 可达。运行全部测试需要本地启动 Redis：

mvn clean test

8.2 集群一致性是“最终一致”，不是实时一致

本地缓存存在一致窗口：A 节点写入并广播，B 节点收到消息前仍可能读到旧值。对于库存、余额、订单状态等强一致场景，建议绕过本地缓存，直接走 Redis 或数据库。

8.3 空值保护是把双刃剑

默认对 null 结果缓存 5 分钟，可防止缓存穿透。但如果业务刚刚从 DB 写入了一条新记录，而之前查询时正好命中了 NullValue，就会出现“写入后 5 分钟内查不到”的延迟。需要时可：

缩短 null-value-ttl
在写入后主动 @LocalCacheEvict
对新增数据敏感的 cacheName 关闭空值保护

8.4 序列化类型变更要兼容

Redis 层使用 Jackson 并保留类型信息。如果缓存对象发生不兼容的类结构变更（如字段类型改变、删除字段、包名调整），旧数据反序列化可能失败。建议：

对缓存 DTO 做版本控制
重大变更时清空 Redis 对应 key 或切换 cacheName
避免把接口、匿名类、动态代理对象放入缓存

8.5 注意 Key 的命名空间隔离

L2 key 格式为 {namespace|cacheName}:dataKey。如果多个业务共用同一个 Redis 实例，务必设置不同的 namespace，否则可能出现 Key 冲突。

8.6 `@LocalCacheable.Multi` 的 `result` 引用要判空

多索引注解里如果通过 #result.xxx 取字段，必须配合 unless = "#result == null"，否则方法返回 null 时会触发 SpEL 计算异常。

8.7 AOP 自调用不会生效

和 Spring Cache 一样，keCache 的注解基于 AOP。同类方法内部调用（this.method()）不会走代理，缓存注解不会生效。需要时注入自身代理或改用编程式 CacheTemplate。

8.8 谨慎使用 `@LocalCacheClear`

@LocalCacheClear 会清空整个 cacheName 的本地缓存并广播。在高并发场景下，频繁全量清除会：

导致本地缓存命中率骤降
引发集体回源，DB 压力陡增
产生大量广播消息

建议优先使用 @LocalCacheEvict 精确驱逐。

8.9 校准任务不是开箱即用的

CalibrationProvider 目前只是 SPI 骨架，需要业务方自己实现 fetchChanges(Instant start, Instant end) 逻辑（如查变更表、CDC 日志）。开启 local-cache.calibration.enabled=true 后才会按 Cron 触发。

8.10 当前 Redis 部署模式限制

自动配置里的 RedissonClient 目前只实现了 single 单节点模式。如果生产环境使用 Redis Cluster、Sentinel 或主从，需要自行扩展配置。

8.11 关注 Caffeine 内存与统计

默认开启 record-stats: true，本地缓存命中率、加载次数等都会被记录。建议配合 actuator / Micrometer（后续可扩展）监控：

maximum-size 是否设置合理
本地缓存命中率
加载耗时与异常率

九、许可证

keCache 采用 MIT 协议开源。

十、总结

keCache 是一个目标聚焦、实现克制的两级缓存框架：

如果你想要 Caffeine 的速度 + Redis 的共享能力，它值得尝试。
如果你希望 声明式注解即可解决集群本地缓存一致性问题，它提供了失效广播与自失效屏蔽。
如果你的业务对 实时一致性零容忍，请把它当作“加速层”而非“唯一数据源”。

有兴趣可以直接到 Gitee 查看源码与示例：https://gitee.com/soulnew/ke-cache。

我开发的KE Reliable Executor：基于 Redis/MySQL 的 Spring Boot 可靠任务执行框架

Mon, 04 Aug 2025 17:10:00 +0800

我开发的KE Reliable Executor：基于 Redis/MySQL 的 Spring Boot 可靠任务执行框架

在微服务里，异步任务随处可见：支付后通知第三方、订单超时取消、批量对账、报表生成……这些任务有一个共同诉求——不能丢、不能重复执行、失败能重试、状态要能查。

传统做法是直接引入 Kafka、RocketMQ 这类重型消息中间件。但对于很多中小型业务来说，这未免太重：

需要额外维护 Broker、Topic、消费组；
团队要熟悉一套新的运维和监控体系；
为了“可靠”还要配置死信队列、事务消息等高级特性。

如果你的系统里已经有 Redis（或 MySQL），并且任务量级尚未达到 MQ 的吞吐上限，那么完全可以基于 Redis 搭一个轻量且可靠的异步任务执行框架。

我开发是这样一个框架：KE Reliable Executor。

开源地址：https://gitee.com/soulnew/reliableexecutor

一、为什么需要这个工具？

先回顾一下常见异步任务场景里的痛点：

痛点	说明
任务丢失	服务重启或执行线程异常退出后，未执行的任务找不到了
重复执行	多实例部署时，同一个任务被多个节点同时消费
失败即结束	业务异常或网络抖动后，没有自动重试机制
状态黑盒	无法查询任务当前是成功、失败、执行中还是已取消
接入成本高	引入 MQ 需要改代码、加依赖、搭集群

KE Reliable Executor 要解决的就是这些问题。它把“可靠任务执行”抽象成一个 Spring Boot Starter：

业务方只负责定义任务处理器和提交任务；
框架负责存储、调度、加锁、重试、状态流转、清理；
所有状态都可通过 API 查询，也可通过 Micrometer 指标监控。

适合什么场景？

已有 Redis/MySQL，不想额外维护 MQ；
任务量中等，对可靠性和重试有要求；
需要任务状态可查询、可人工介入；
团队希望以最小成本获得“类 MQ”的可靠执行能力。

不适合什么场景？

海量消息、高吞吐（Kafka/RocketMQ 更合适）；
严格顺序消费（ZSET 按时间排序，不保证业务绝对顺序）；
需要复杂路由、死信队列、事务消息等高级 MQ 特性。

二、与竞品的对比

2.1 与 Kafka / RocketMQ 对比

维度	Kafka / RocketMQ	KE Reliable Executor
基础设施	需要独立 Broker 集群	复用 Redis 或 MySQL
运维成本	高（Topic、消费组、监控）	低（Spring Boot Starter）
接入成本	需要学习 SDK 与语义	注解 + 注入接口即可
吞吐量	极高	中等
状态查询	需自建审计表	内置状态查询
重试机制	需配置消费重试	内置可配置重试
适用阶段	大型业务、高并发	中小型业务、快速落地

结论：KE Reliable Executor 不是取代 MQ，而是在“已有 Redis/MySQL、任务量可控”的场景下，提供一个更轻量的选择。

2.2 与 Spring `@Scheduled` + 数据库轮询对比

很多团队最早会用数据库表 + @Scheduled 轮询来实现异步任务。这种做法的问题：

无分布式锁：多实例同时轮询会重复执行；
无状态机：任务状态全靠字段控制，容易混乱；
无统一重试策略：重试间隔、重试次数需要手写；
无优雅关闭：应用关闭时可能丢失正在执行的任务。

KE Reliable Executor 把这些都封装好了：

Master 选举 + 任务级锁保证不重复；
明确的状态机（CREATED → RUNNING → PENDING/COMPLETED/FAILED）；
可配置的重试间隔与次数；
优雅释放锁与线程池关闭。

2.3 与 XXL-JOB / PowerJob 对比

XXL-JOB 和 PowerJob 是优秀的分布式任务调度平台，但它们更适合定时任务和调度中心模式：

需要单独部署调度中心；
适合 Cron 表达式触发的批处理任务；
任务由业务主动提交的场景下，接入不够自然。

KE Reliable Executor 更像一个嵌入式任务队列：

无额外服务，随业务应用启动；
任务由业务代码主动提交；
强调“提交即可靠执行”，而非定时触发。

三、整体架构

3.1 模块解构图

graph TD
    A[业务服务] -->|submitTask| B(ReliableExecutor API)
    B --> C[TaskScheduler]
    C --> D{Master 锁}
    D -->|持有锁| E[扫描 ZSET 任务]
    E --> F[任务级锁]
    F -->|获取成功| G[提交线程池]
    G --> H[TaskExecutor]
    H --> I["任务处理器 @ReliableTaskHandler"]
    I -->|成功| J[移入 FINISHED]
    I -->|失败| K[更新为 PENDING 等待重试]
    C --> L[TaskStorage]
    L --> M[RedisTaskStorage]
    L --> N[JdbcTaskStorage]
    H --> O[ReliableTaskListener]
    C --> P[ReliableExecutorMetrics]

3.2 两层锁模型

graph TB
    subgraph 全局层
        A[Master 锁] -->|仅一个实例| B[负责调度扫描]
    end
    subgraph 任务层
        C["任务级锁 task-lock:{taskId}"] -->|仅一个线程| D[执行任务]
    end
    B --> C

Master 锁：同一时刻只有一个实例负责扫描任务，避免多节点拉取同一批任务。
任务级锁：针对每个 CREATED 任务，提交执行前再抢一次锁，保证同一任务不会被并发执行。

3.3 队列设计

graph LR
    A[提交任务] -->|add| B[Redis ZSET running-task-zset]
    B -->|ZRANGE 按 score| C[调度器]
    C -->|执行成功/失败/超时| D[Lua 原子转移]
    D -->|RPUSH + ZREM| E[Redis List finished-task-list]

使用 ZSET 而非 List 的核心原因：

天然支持时间调度：score 编码创建时间或下次重试时间；
任务唯一：同一个 member 在队列中只有一份；
状态分区：CREATED 与 PENDING 使用不同 score 基数，一次范围查询即可区分。

Score 编码规则：

score = BASE + epochMillis * 100 + retryCount

CREATED 基数：1_000_000_000_000_000
PENDING 基数：2_000_000_000_000_000

3.4 任务状态机

stateDiagram-v2
    [*] --> CREATED: submitTask
    CREATED --> RUNNING: 调度/立即执行
    RUNNING --> COMPLETED: 执行成功
    RUNNING --> PENDING: 执行失败，未超重试
    PENDING --> RUNNING: 到达重试时间
    RUNNING --> FAILED: 超过重试次数
    RUNNING --> TIMEOUT: 超过最大时长
    CREATED --> CANCELLED: 取消任务
    PENDING --> CANCELLED: 取消任务
    RUNNING --> ERROR: 无处理器/参数错误

四、核心设计要点

4.1 Lua 原子转移

任务进入终态时，必须保证“写入 finished list”和“从 ZSET 移除”是原子的，否则可能出现：

任务已判定成功但还在 ZSET 里，被下一次调度捞出来；
任务已从 ZSET 移除但 finished list 没写入，查询不到结果。

框架使用 Lua 脚本完成这一转移：

local score = redis.call('ZSCORE', KEYS[1], ARGV[1]);
redis.call('RPUSH', KEYS[2], ARGV[2]);
if score then
    redis.call('ZREM', KEYS[1], ARGV[1]);
    return 1;
else
    return 0;
end

逻辑：先查 ZSET，无论是否存在都把终态信息写入 finished list，如果存在再删除。整个脚本在 Redis 单线程执行，天然原子。

4.2 Double-Check

调度器拿到任务级锁后、提交线程池前，会再次回查 Redis：

任务是否仍在 running ZSET 中？
任务状态是否仍是 CREATED？

任一条件不满足，立即释放锁并跳过。这是经典的双重检查模式，把“检查-执行”串在锁保护的临界区内。

4.3 双存储后端

graph TD
    A[TaskStorage 接口] --> B[RedisTaskStorage]
    A --> C[JdbcTaskStorage]
    B --> D[Redisson ZSET + List]
    C --> E[reliable_executor_task 表]
    F[配置 reliable-executor.task-storage] -->|redis/mysql| A

redis：默认，适合已有 Redis 的场景；
mysql：适合不希望引入 Redis 或需要更强持久化的场景。

两种后端通过 Spring 条件装配切换，业务代码无感知。

五、快速开始

5.1 引入依赖

dependencies {
    implementation 'com.ftmao:ke-reliable-executor:1.0.0-SNAPSHOT'
    implementation 'org.redisson:redisson-spring-boot-starter:3.27.2'
}

5.2 配置

spring:
  application:
    name: my-app
  redis:
    redisson:
      config: |
        singleServerConfig:
          address: "redis://127.0.0.1:6379"

reliable-executor:
  task-storage: redis
  core-pool-size: 5
  max-pool-size: 10
  queue-capacity: 100

5.3 定义处理器

@Component
public class OrderTaskHandler {

    @ReliableTaskHandler(name = "process_order", paramType = OrderParam.class)
    public void processOrder(OrderParam param) {
        // 业务逻辑
    }

    @ReliableTaskHandler(name = "send_notify")
    public void sendNotify() {
        // 无参任务
    }
}

5.4 提交任务

@Service
@RequiredArgsConstructor
public class OrderService {

    private final ReliableExecutor reliableExecutor;

    public void submitOrder(OrderParam param) {
        TaskSubmitRequest request = TaskSubmitRequest.builder()
                .taskId(UUID.randomUUID().toString())
                .taskName("process_order")
                .taskParameter(param)
                .retryLimit(3)
                .retryInterval(2000)
                .maxDurationMillis(60000)
                .build();
        reliableExecutor.submitTask(request);
    }
}

5.5 监听生命周期

@Component
public class MyTaskListener implements ReliableTaskListener {

    @Override
    public void onTaskCompleted(String taskId, String taskName) {
        // 任务成功
    }

    @Override
    public void onTaskFailed(String taskId, String taskName, String status) {
        // 任务最终失败
    }
}

六、使用注意点与避坑指南

6.1 业务幂等仍然是最后一道防线

框架通过两层锁、double-check、Lua 原子转移把重复执行的概率降到极低，但任何分布式系统都无法 100% 保证幂等。业务 Handler 仍然应该保证幂等，尤其是涉及写数据库、调用外部接口的场景。

6.2 taskId 需要业务保证唯一

框架使用业务传入的 taskId 作为任务唯一标识。如果同一业务单据重复提交相同 taskId，第二次提交会生成新的 ZSET member（如果业务字段不同）或覆盖（如果完全相同）。建议用业务主键 + 操作类型组合生成 taskId，例如 order_12345_pay。

6.3 重试间隔与最大时长的权衡

reliable-executor:
  retryInterval: 2000      # 失败后 2s 再试
  maxDurationMillis: 60000 # 任务最长存活 60s

retryInterval 过小会导致失败任务快速反复执行，放大下游压力；
maxDurationMillis 是从任务创建时间算起，不是单次执行时间；
建议失败任务采用指数退避（当前版本为固定间隔，后续可扩展）。

6.4 MySQL 分支需要自行引入 JPA

框架中 spring-boot-starter-data-jpa 是 compileOnly，使用 MySQL 存储时需要在业务应用里显式引入：

implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
runtimeOnly 'com.mysql:mysql-connector-j'

并执行建表脚本 db/migration/V1__create_reliable_executor_tables.sql。

6.5 Redis 集群环境注意 Key 前缀

框架默认使用 spring.application.name 作为 Redis Key 前缀。如果多个应用共用同一个 Redis 实例，务必设置不同的 spring.application.name，否则任务会互相串扰。

6.6 线程池队列满载时会跳过调度

当线程池队列达到 queueCapacity 时，调度器会跳过本次周期，避免无限制堆积。如果业务出现持续高峰，建议：

调大 maxPoolSize 和 queueCapacity；
监控 reliable_executor_threadpool_queue_size 指标；
必要时配合业务限流。

6.7 不要忽略超时任务

maxDurationMillis 是从创建时间算起的总时长。如果一个任务在队列里排队太久，可能还没执行就触发 TIMEOUT。对于允许较长延迟的任务，要把这个值设大；对于实时性任务，要把重试间隔和排队容量一起考虑。

6.8 本地开发无 Redis 怎么办？

使用 MySQL 分支（H2 也可以跑测试）；
或者本地启动一个 Redis Docker 容器；
框架的 Redis 集成测试会在无 Redis 时自动跳过，不影响 CI。

七、监控指标

框架内置 Micrometer 指标，可接入 Prometheus/Actuator：

指标名	含义
`reliable_executor_is_master`	当前节点是否为 Master
`reliable_executor_tasks_scheduled_total`	累计调度任务数
`reliable_executor_tasks_executed_total`	累计执行任务数
`reliable_executor_tasks_completed_total`	累计成功任务数
`reliable_executor_tasks_failed_total`	累计失败任务数
`reliable_executor_tasks_timeout_total`	累计超时任务数
`reliable_executor_tasks_retried_total`	累计重试次数
`reliable_executor_threadpool_queue_size`	线程池队列大小
`reliable_executor_task_execution_seconds`	任务执行耗时

八、开源与示例

开源地址：https://gitee.com/soulnew/reliableexecutor
示例模块：example/ 子项目包含可运行的 Spring Boot 应用和 REST 接口示例，可直接启动体验任务提交与执行。

九、总结

KE Reliable Executor 是一个轻量、可靠、易接入的异步任务执行框架。它用 Redis ZSET + 两层锁 + Lua 原子转移，在“不引入重型 MQ”的前提下，提供了任务提交、调度、重试、状态查询、监控等完整能力；同时通过 MySQL 分支提供了另一种存储选择。

如果你的业务符合以下特征，不妨试试它：

已有 Redis/MySQL；
任务量中等，重视可靠性；
希望快速落地，不想为 MQ 付出额外运维成本；
需要任务状态可观测、可人工介入。

记住：框架层负责把重复消费的概率降到极低，业务层仍应保证 Handler 幂等，这才是工程上的稳妥做法。

《领域驱动设计》精简版：一张图看懂 DDD，引用开源 ddd-demo

Thu, 27 Jul 2023 20:00:00 +0800

《领域驱动设计》精简版：一张图看懂 DDD，引用开源 ddd-demo

这份笔记基于 Eric Evans 的《领域驱动设计》以及 Vaughn Vernon 的《实现领域驱动设计》《领域驱动设计精粹》，结合日常工程实践做了补充。文中完整代码实现参考开源项目 soulnew/ddd-demo，可直接克隆运行。

一、为什么需要 DDD？

传统分层架构（Controller → Service → DAO）的问题：

问题	表现
贫血模型	`Service` 里全是 if/else，Entity 只有 getter/setter
语义泄漏	业务术语被翻译成 `status = 1`，新人读不懂
边界模糊	一个 `OrderService` 同时处理库存、支付、物流
复用困难	同样叫“用户”，在会员、权限、订单里含义不同

DDD 的核心主张：让软件结构对齐业务领域，用业务语言写代码，用边界保护领域模型。

二、一张图：DDD 战略-战术全景

mindmap
  root((领域驱动设计 DDD))
    战略设计 Strategic Design
      领域 Domain
      子域 Subdomain
        核心域 Core
        支撑域 Supporting
        通用域 Generic
      限界上下文 Bounded Context
      上下文映射 Context Mapping
        合作关系 Partnership
        共享内核 Shared Kernel
        客户-供应商 Customer-Supplier
        遵奉者 Conformist
        防腐层 ACL
        开放主机服务 OHS
        发布语言 PL
        各行其道 Separate Ways
    战术设计 Tactical Design
      实体 Entity
      值对象 Value Object
      聚合 Aggregate
      领域服务 Domain Service
      仓储 Repository
      工厂 Factory
      领域事件 Domain Event
      应用服务 Application Service
    统一语言 Ubiquitous Language
    分层架构 Layered Architecture
      用户界面层 UI
      应用层 Application
      领域层 Domain
      基础设施层 Infrastructure

记忆口诀：先战略（划边界），后战术（建模型），全程讲“统一语言”。

三、战略设计：先画地图，再打仗

3.1 领域 = 问题空间 + 解决方案空间

graph LR
    A[问题空间<br/>Problem Space] --> B[领域 Domain<br/>业务要解决的问题]
    B --> C[子域 Subdomain<br/>可独立讨论的业务板块]
    C --> D[核心域 Core Domain<br/>竞争优势]
    C --> E[支撑域 Supporting<br/>定制但非核心]
    C --> F[通用域 Generic<br/>可外购/复用]
    D --> G[解决方案空间<br/>Solution Space]
    E --> G
    F --> G
    G --> H[限界上下文 Bounded Context<br/>一个模型只在一个上下文内有效]

示例：在线医疗平台

子域	类型	说明
问诊	核心域	核心竞争力，需精研模型
处方	支撑域	受监管约束，需定制但非差异化
支付	通用域	可直接对接微信/支付宝
消息通知	通用域	短信/推送可用第三方

3.2 限界上下文 Bounded Context

定义：限界上下文是领域模型能够保持一致性和完整性的显式边界。在边界内部，每个业务术语、概念、规则都有精确且唯一的含义；同一概念在不同限界上下文中可以拥有不同定义。它是 DDD 战略设计中保护模型不被语义污染的最小单元。

同一个业务名词，在不同上下文里含义可能完全不同。DDD 用“限界上下文”给模型画边界。

graph TB
    subgraph 商品上下文 Product Context
        P1[商品 = SKU + 价格 + 库存]
    end
    subgraph 订单上下文 Order Context
        P2[商品 = 快照 + 购买时价格 + 数量]
    end
    subgraph 物流上下文 Logistics Context
        P3[商品 = 重量 + 体积 + 易碎标识]
    end
    subgraph 营销上下文 Marketing Context
        P4[商品 = 卖点 + 优惠券适用规则]
    end
    P1 -.->|映射| P2
    P1 -.->|映射| P3
    P1 -.->|映射| P4

关键认知：不要追求“一个全局统一的数据模型”，要在上下文内部统一，在上下文之间显式映射。

3.3 上下文映射模式

定义：上下文映射模式是 DDD 中用于描述不同限界上下文之间集成关系与协作方式的战略模式集合。由于每个限界上下文都有自己的模型和统一语言，当业务流程跨越多个上下文时，需要通过上下文映射来显式定义它们如何依赖、转换与协作，从而保证边界清晰、演化可控。

graph LR
    A[上下文 A] -->|合作关系<br/>Partnership| B[上下文 B]
    C[上下文 C] -->|共享内核<br/>Shared Kernel| D[上下文 D]
    E[上游 Upstream] -->|客户-供应商<br/>Customer-Supplier| F[下游 Downstream]
    G[强势上游] -->|遵奉者<br/>Conformist| H[下游]
    I[下游] -->|防腐层 ACL| J[外部系统]
    K[开放主机服务 OHS<br/>+ 发布语言 PL] --> L[下游]
    M[上下文 M] -.->|各行其道<br/>Separate Ways| N[上下文 N]

模式	使用场景
合作关系	两个团队互相依赖，共同演进
共享内核	核心模型由双方共同维护，改动需同步
客户-供应商	上游优先服务下游需求，下游有话语权
遵奉者	上游强势（如外部 SaaS），下游无条件接受
防腐层 ACL	隔离遗留系统或外部 API，保护领域模型
开放主机服务 + 发布语言	上游提供稳定 API/协议，供多个下游消费
各行其道	关联微弱，各自独立

3.4 从限界上下文到微服务边界

限界上下文是语义边界——一个模型在这个边界内含义一致；微服务是部署边界——独立代码库、独立数据库、独立发布单元。二者不是一回事，但 DDD 划分微服务边界时，最可靠的起点就是限界上下文。

映射原则

graph LR
    A[业务领域] --> B[识别子域<br/>Core / Supporting / Generic]
    B --> C[定义限界上下文<br/>语义边界]
    C --> D{是否满足<br/>拆分条件？}
    D -->|是| E[一个微服务]
    D -->|否| F[多个上下文合并<br/>或模块化单体]
    E --> G[独立数据库<br/>独立部署<br/>API / 事件交互]

默认规则：一个限界上下文对应一个微服务。

例外情况：

情况	处理
上下文内部模块差异极大（性能、安全、团队）	可进一步拆分，但要保留相同的“统一语言”子空间
多个上下文非常小且高度协作	可合并为一个服务，内部用模块隔离
团队规模小、业务简单	先模块化单体，随演进再拆
强一致事务需求	优先放在同一服务 / 同一数据库内

拆分的启发条件

满足以下任意一条，都可以把限界上下文拆成独立微服务：

独立演进：团队能独立发布，不阻塞他人。
独立伸缩：流量特征不同，例如订单读多写少，库存强一致写频繁。
独立故障域：一个服务故障不应拖垮整个平台。
独立技术栈：某些上下文需要特殊存储（图数据库、时序数据库等）。
合规隔离：支付、医疗、金融数据需要独立部署和审计。

案例：B2C 电商的微服务边界划分

以常见的 B2C 电商为例，演示“子域 → 限界上下文 → 微服务”的完整推导过程。

第一步：识别子域

子域	类型	说明
订单	核心域	下单、状态机、优惠计算
库存	核心域	实时库存、预占、扣减
支付	通用域	对接微信 / 支付宝 / 信用卡
物流	支撑域	运单、轨迹、配送规则
商品	核心域	类目、属性、价格
营销	支撑域	优惠券、满减、秒杀
会员	支撑域	积分、等级、权益

第二步：定义限界上下文与统一语言

同一个业务名词在不同上下文里含义不同，这正是拆分的语义依据。

上下文	“商品”在该上下文中的含义	“订单”在该上下文中的含义
商品上下文	SKU、SPU、类目、主图、售价	无
订单上下文	商品快照（下单时的价格和描述）	聚合根：状态、金额、行项
库存上下文	可售数量、预占数量、仓库	无
物流上下文	重量、体积、易碎标识	发货单、包裹、运单
营销上下文	适用优惠券的商品范围	优惠分摊、实付金额

关键判断：如果两个地方对“商品”的定义和生命周期完全不同，就应分属不同上下文，也倾向于拆成不同微服务。

第三步：映射为微服务

graph TB
    subgraph 微服务边界
        P[商品服务<br/>Product Service]
        O[订单服务<br/>Order Service]
        I[库存服务<br/>Inventory Service]
        PAY[支付服务<br/>Payment Service]
        L[物流服务<br/>Logistics Service]
        M[营销服务<br/>Marketing Service]
        U[会员服务<br/>Member Service]
    end

    O -->|预占库存| I
    O -->|发起支付| PAY
    I -->|OrderPaid 事件| L
    O -->|查询商品信息| P
    O -->|计算优惠| M
    U -->|积分抵扣| O

第四步：选择上下文映射模式

关系	模式	说明
订单 → 库存	客户-供应商 + 最终一致	订单调用库存预占接口；库存发布 `InventoryReserved` 事件
订单 → 支付	开放主机服务 OHS	支付提供标准支付网关 API，多个业务共用
库存 → 物流	发布语言 PL + 领域事件	`OrderPaid` 事件触发物流创建发货单
订单 → 商品	遵奉者 / ACL	商品模型由商品服务定义，订单只保存快照
营销 → 订单	共享内核 Shared Kernel	优惠分摊算法需双方共同维护

常见反模式

反模式	问题	正确做法
按 CRUD 实体拆分	`UserService`、`OrderService`、`ProductService` 只是数据表代理	按业务能力（上下文）拆分，服务内包含完整业务规则
按前端页面拆分	一个页面一个服务	页面是组合层，服务应按领域聚合
过度拆分	一次下单调 20 个接口	先模块化单体，验证边界后再拆
共享数据库	多个服务直接操作同一张表	每个服务拥有自己的数据，通过 API / 事件交互

一句话：微服务边界不是拍脑袋定的，而是从“限界上下文”出发，结合团队、性能、合规、发布节奏再微调的结果。

四、战术设计：在限界上下文里建模型

4.1 核心概念关系图

classDiagram
    class AggregateRoot {
        +Entity root
        +invariant()
    }
    class Entity {
        +identity
        +continuity
    }
    class ValueObject {
        +immutable
        +equality by value
    }
    class DomainEvent {
        +eventId
        +occurredOn
        +payload
    }
    class Repository {
        +save(aggregate)
        +byId(id)
    }
    class DomainService {
        +cross-aggregate logic
    }
    class Factory {
        +create()
    }
    AggregateRoot --> Entity : contains
    AggregateRoot --> ValueObject : contains
    AggregateRoot --> DomainEvent : publishes
    Repository --> AggregateRoot : persists
    Factory --> AggregateRoot : creates
    DomainService --> AggregateRoot : orchestrates

4.2 实体 Entity vs 值对象 Value Object

graph LR
    subgraph Entity
        E1[Order #1001] --> E2[状态变化<br/>待支付 → 已发货 → 已完成]
        E2 --> E3[同一 identity<br/>状态变了还是它]
    end
    subgraph Value Object
        V1[Money amount=100 currency=CNY] --> V2[不可变]
        V2 --> V3[替换即新生<br/>money = money * 2]
    end

判断标准：

如果对象需要被追踪生命周期，有独立身份 → 实体
如果对象只描述属性，换了值就等于换了对象 → 值对象

五、完整设计 Demo：电商订单上下文

完整的代码实现可参考开源项目：

Gitee: soulnew/ddd-demo
https://gitee.com/soulnew/ddd-demo

该项目演示了一个典型的 DDD 工程结构，包括：

领域层：实体、值对象、聚合根、领域服务、领域事件
应用层：应用服务、Command/Query、事务编排
基础设施层：仓储实现、外部 API 适配、消息发布
接口层：Controller / API 入口

建议结合本节的战术概念，重点阅读：

domain/ 下的聚合根如何封装业务规则（如订单状态机）。
application/ 下的应用服务如何编排用例，不写业务规则。
infrastructure/ 下的仓储实现如何把领域模型映射到持久化。

如果你想快速跑通一个最小可运行示例，也可以直接克隆该项目：

git clone https://gitee.com/soulnew/ddd-demo.git

下面只保留一个最小示意图，帮助理解“充血模型”与“贫血模型”的关键差异。

5.1 充血模型 vs 贫血模型对比

贫血模型	充血模型
`OrderService` 里写 `if (status.equals("PAID"))`	`Order.pay()` 自己封装状态机
`OrderEntity` 只有 getter/setter	`Order` 有业务方法，规则集中在领域对象
规则散落在 Service	不变量、状态变更由聚合根保证
持久化即领域模型	持久化是领域模型的投影

核心原则：把“什么样合法”的判断放到领域对象里，应用服务只负责“什么时候调用”。

六、分层架构：代码放哪里？

graph TB
    subgraph 用户界面层 UI/API
        U1[Controller / Handler]
    end
    subgraph 应用层 Application
        A1[Application Service]
        A2[DTO / Command / Query]
    end
    subgraph 领域层 Domain
        D1[Entity]
        D2[Value Object]
        D3[Domain Service]
        D4[Domain Event]
        D5[Repository Interface]
    end
    subgraph 基础设施层 Infrastructure
        I1[Repository Implementation]
        I2[Message Queue]
        I3[Database]
        I4[External API Client]
    end

    U1 --> A1
    A1 --> D1
    A1 --> D3
    D1 --> D2
    D1 -.->|发布| D4
    A1 --> D5
    D5 -.->|由| I1
    I1 --> I3
    A1 -.->|发送| I2
    A1 -.->|调用| I4

依赖方向：UI → 应用 → 领域；基础设施通过接口被领域依赖（依赖倒置）。

层级	职责	不该做的事
UI	接收请求、返回响应	不直接操作 Repository
应用层	编排用例、事务、权限校验	不写业务规则
领域层	业务规则、不变量、状态变更	不依赖框架/数据库
基础设施	持久化、消息、外部调用	不侵入领域规则

七、聚合设计：四条黄金规则

graph TB
    subgraph 聚合根 Order
        O1[Order] --> L1[OrderLineItem]
        O1 --> L2[OrderLineItem]
        O1 --> M1[Money total]
        O1 --> A1[Address shipping]
        O1 --> E1[DomainEvent list]
    end
    subgraph 外部只能通过聚合根访问
        X[其他上下文] -->|byId/order.pay| O1
        X -.->|❌ 不能直接修改| L1
    end

一个聚合只有一个聚合根，外部对象只能引用聚合根 ID。
聚合内部强一致，跨聚合最终一致（用领域事件）。
小聚合优先，大聚合会成性能瓶颈和并发热点。
删除聚合根级联删除其内部对象。

反例：如果把 User 和 Order 放在同一个聚合里，用户每次下单都会锁定整个用户聚合，极端不合理。

八、领域事件：跨聚合/上下文的胶水

sequenceDiagram
    participant O as Order 聚合
    participant E as Event Bus
    participant I as Inventory 上下文
    participant L as Logistics 上下文
    O->>O: order.pay()
    O->>E: publish OrderPaid
    E->>I: consume OrderPaid
    I->>I: 扣减库存
    E->>L: consume OrderPaid
    L->>L: 创建发货单

领域事件的价值：

解耦：Order 不需要知道 Inventory 和 Logistics 的存在。
最终一致：接受短时间不一致，换取可扩展性。
审计：事件日志本身就是业务轨迹。

九、常见反模式与纠正

反模式	现象	纠正
贫血领域模型	Entity 只有字段，Service 全是逻辑	把不变规则和状态变更放回实体
万能聚合	一个聚合包含十几个实体	按业务不变量拆分，跨聚合用事件
数据库驱动建模	先建表，再写代码	先建模，再映射持久化
跨上下文直接引用	Order 直接持有 Inventory 对象	只存 ID，通过 ACL/OHS 交互
应用层写业务规则	`if order.status == ...` 散落在 Service	下放到领域对象
值对象可变	`money.setAmount(100)`	用 final 类 + 不可变字段，替换而非修改

十、什么时候用 DDD，什么时候不用？

flowchart TD
    A[项目是否复杂？] -->|否| B[简单 CRUD 即可]
    A -->|是| C[业务是否快速变化？]
    C -->|否| D[事务脚本 / 简单分层]
    C -->|是| E[团队是否愿意投入统一语言？]
    E -->|否| F[DDD 收益低]
    E -->|是| G[DDD 值得尝试]
    G --> H[从核心域开始<br/>小步迭代]

适合 DDD：

业务复杂、领域专家与开发需紧密协作
核心域需要长期演进
微服务边界模糊，需要战略设计

不适合 DDD：

简单数据录入/展示系统
生命周期短、需求稳定的项目
团队没有领域专家时间投入

十一、实战案例：新项目从 0 到 1 落地 DDD

前面讲的都是概念和 Demo，下面以 在线健身私教平台 FitCoach 为例，把“如何划分领域、子域、限界上下文、微服务，以及如何决策充血/贫血模型、如何裁剪 DDD”串成一条完整思路。

11.1 项目背景与目标

FitCoach 要做一个连接私教与学员的平台，核心能力包括：

学员购买课程包、预约上课时间、查看训练记录
教练管理学员、制定训练计划、记录每次上课内容
运营人员配置课程 SKU、促销活动、处理退款申诉
对接第三方支付、短信推送、以及第三方直播上课工具

业务不算极端复杂，但涉及“课程、预约、课时、计划、会员、支付、营销”多个概念，且预计会快速迭代。这正是 DDD 能帮上忙的地方：先把业务地图画清楚，再决定怎么写代码。

11.2 第一步：识别领域与子域

领域（Domain） 就是整个健身私教业务要解决的问题空间。通过事件风暴或用户旅程，可以识别出以下子域：

子域	类型	判断理由	投入策略
私教课程与预约	核心域	直接决定用户体验和变现效率	投入最好的领域专家和工程师
训练计划与记录	核心域	教练专业能力的载体，差异化关键	与课程域紧密协作演进
会员与教练档案	支撑域	需要定制，但不是竞争壁垒	内部实现，够用即可
支付与财务	通用域	行业通用能力	对接微信/支付宝，封装标准接口
消息通知	通用域	短信/推送/站内信	使用第三方 SaaS
内容（文章/视频）	支撑域	运营辅助，提升留存	可用开源 CMS 改造

划分子域的权衡要点：

不要从技术模块出发。例如不要先想“需要一个 UserService”，而要想“会员管理”这个业务能力。
核心域通常只有 1-2 个。如果把所有子域都标成核心，等于没有重点。
通用域不要自己造轮子。支付、通知直接买，团队精力留给核心域。
子域边界可以随业务演化。MVP 阶段可以把“训练计划”放在“课程域”里，等业务复杂后再拆出来。

11.3 第二步：划分限界上下文

划分的核心问题是：同一个业务名词，在不同地方含义是否不同？生命周期是否独立？

以“课程”这个词为例：

上下文	“课程”在该上下文中的含义	关键概念
课程目录上下文	可售卖的课程 SKU：价格、有效期、适用人群、退费规则	CourseCatalog, PricePolicy
预约调度上下文	一次具体的上课时间：教练、学员、时段、状态	Appointment, TimeSlot
训练记录上下文	一次实际上课产生的记录：消耗课时、训练内容、教练反馈	TrainingRecord, ConsumedSession
营销上下文	参与促销的课程范围：满减、套餐、优惠券适用	PromotionRule, Bundle
财务上下文	课程订单的应收、实收、退款流水	CourseOrder, Refund

因为“课程”的含义和生命周期在每个上下文里都不同，所以应该拆成不同的限界上下文。FitCoach 最终划分如下：

课程目录上下文（Course Catalog Context）
预约调度上下文（Scheduling Context）
训练记录上下文（Training Record Context）
会员上下文（Member Context）
教练上下文（Coach Context）
支付上下文（Payment Context）
营销上下文（Marketing Context）
消息通知上下文（Notification Context）

关键判断：如果两个地方对同一个名词的定义和生命周期不同，就倾向于拆成不同上下文；如果概念高度一致且总是一起变化，可以合并。

11.4 第三步：推导微服务边界

默认规则是一个限界上下文对应一个微服务，但 FitCoach 还要考虑团队规模、数据一致性、发布频率、性能特征。

限界上下文	微服务决策	决策理由
课程目录	独立服务	变化频繁，运营经常调整 SKU 和价格
预约调度	独立服务	高并发读，学员大量刷可选时段，需单独伸缩
训练记录	独立服务	写多读少，数据量大，未来可能要独立归档
会员 + 教练档案	合并为“账户服务”	MVP 阶段都很薄，且登录后经常一起查询；内部用模块隔离
支付	独立服务	涉及资金安全、合规审计、对接第三方
营销	独立服务	活动频繁，不能影响核心预约链路
消息通知	独立服务	可被多个业务复用，适合独立演进

合并的例外处理：

会员和教练虽然业务概念不同，但 MVP 阶段数据模型简单，合并可以减少一次远程调用。
如果后续教练业务复杂化（排期、评级、分成、资质认证），再把教练上下文拆成独立服务。

一句话：微服务边界从限界上下文出发，再结合团队、性能、合规、数据一致性做微调。

11.5 第四步：选择上下文映射模式

不同上下文之间不是孤立的，需要显式定义它们如何协作。

graph LR
    A[预约上下文] -->|Customer-Supplier| B[课程目录上下文]
    C[训练记录上下文] -->|Customer-Supplier| A
    D[支付上下文] -->|OHS + PL| E[预约上下文]
    F[营销上下文] -->|Shared Kernel| A
    G[消息通知上下文] -->|Conformist| H[短信/推送第三方]
    I[账户服务] -->|OHS + PL| J[所有业务服务]
    K[训练记录上下文] -->|ACL| L[直播上课工具]

关系	模式	说明
预约 → 课程目录	客户-供应商	预约需要课程的名称、价格、时长；课程目录提供稳定查询接口
训练记录 → 预约	客户-供应商	训练记录基于已完成的预约生成
支付 → 各业务	开放主机服务 OHS	支付提供统一的收款、退款、对账 API
营销 → 预约	共享内核 Shared Kernel	促销分摊、优惠券核销规则需要双方共同维护
消息通知 → 第三方	遵奉者 Conformist	直接调用第三方 SDK，模型由第三方定义
训练记录 → 直播工具	防腐层 ACL	直播工具接口不稳定，通过 ACL 隔离，保护领域模型

11.6 第五步：充血模型 vs 贫血模型决策

DDD 并不要求全场充血。模型选择应该看该上下文的业务复杂度，而不是追求统一风格。

上下文	推荐模型	理由
预约调度	充血模型	状态机复杂：待预约 → 已预约 → 已签到 → 已完成 → 已取消；有取消规则、爽约规则
训练记录	充血模型	记录不可变，但课时消耗计算、教练评分聚合有业务规则
课程目录	贫血模型可接受	主要是 CRUD，业务规则少
账户服务	贫血模型	数据管理为主，验证规则简单
消息通知	贫血/过程式	基本是发送逻辑，无复杂领域规则
营销	充血模型	优惠计算、互斥规则、分摊逻辑复杂

预约上下文的充血模型示例：

public class Appointment {
    private AppointmentId id;
    private TimeSlot timeSlot;
    private MemberId memberId;
    private CoachId coachId;
    private AppointmentStatus status;
    private List<DomainEvent> domainEvents = new ArrayList<>();

    public void cancel(LocalDateTime now) {
        if (status != AppointmentStatus.BOOKED) {
            throw new DomainException("只能取消已预约的课程");
        }
        if (timeSlot.start().minusHours(24).isBefore(now)) {
            throw new DomainException("开课 24 小时内不可取消");
        }
        this.status = AppointmentStatus.CANCELLED;
        domainEvents.add(new AppointmentCancelled(id, now));
    }

    public void checkIn(LocalDateTime now) {
        if (status != AppointmentStatus.BOOKED) {
            throw new DomainException("未预约不能签到");
        }
        this.status = AppointmentStatus.COMPLETED;
        domainEvents.add(new AppointmentCheckedIn(id, memberId, coachId, now));
    }
}

决策口诀：

状态机复杂、不变量多、业务规则变化快 → 充血模型
主要是增删改查、数据为主、规则简单 → 贫血模型即可
不确定时，先写贫血，等规则复杂了再重构为充血

11.7 第六步：DDD 是否可以裁剪？

可以，而且应该根据项目情况裁剪。 DDD 不是全有或全无的框架。

场景 1：只用战略设计，战术设计从简

适合情况：业务复杂但技术栈简单、团队经验不足、MVP 阶段要快速上线。
FitCoach 初期做法：先画好限界上下文和微服务边界，服务内部用简单 CRUD + Service 实现。
价值：至少解决了“边界混乱、术语不一致、重复造轮子”的问题。

场景 2：只用战术设计，在已有边界内建模

适合情况：系统边界已经清楚，但某个模块内部逻辑混乱（如遗留系统重构）。
FitCoach 示例：课程目录已经稳定，但预约状态机满是 if/else，可以只对“预约上下文”做充血模型重构。
风险：如果战略边界本身不清晰，战术设计会变成“在错误的地方做正确的事”。

场景 3：战略 + 战术都用，但不用高级模式

这是最常见的落地方式。
FitCoach 可以用：限界上下文 + 充血模型 + 领域事件 + 分层架构。
可以先不用：事件溯源、CQRS、六边形架构的严格形式。

裁剪原则

复杂的地方用 DDD，简单的地方不要硬套。
先战略后战术，边界不清不要深入建模型。
一个项目可以不同上下文用不同成熟度：核心域充血 + 贫血，通用域直接用 SDK。
不要为了 DDD 而 DDD，目标是降低业务复杂度，不是写出“DDD 标准代码”。

11.8 落地时间线建议

阶段	目标	关键产出
Week 1-2	事件风暴 + 统一语言	子域图、限界上下文图、术语表
Week 3	微服务边界与映射模式	服务拆分方案、接口契约初稿
Week 4-6	核心域战术设计	聚合、实体、值对象、领域事件、测试
Week 7-8	基础设施 + 集成测试	数据库、消息队列、CI/CD 流水线
持续	演进	根据业务变化调整边界和模型

新手常犯的错误：一上来就在所有服务里写聚合根、值对象、领域事件。正确做法是先画地图，再对核心域精雕细琢，其他域能跑通即可。

十二、一句话总结

DDD = 用“统一语言”沟通业务，用“限界上下文”划分边界并推导微服务边界，用“聚合/实体/值对象”封装领域知识，用“领域事件”连接上下文，让软件结构真正反映业务结构。

把 soulnew/ddd-demo 的 Demo 跑一遍，再画一张你自己业务的战略地图，并尝试标出可能的微服务边界，你就已经比 80% 自称做 DDD 的人更接近它的本质了。

参考

Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software
Vaughn Vernon. Implementing Domain-Driven Design
Vaughn Vernon. Domain-Driven Design Distilled

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、接口文档都在仓库里，希望能给做小程序商城的朋友一个可参照的完整样本。

《Netty 源码剖析与应用》详细总结：写给从未接触过 Netty 的人

Sat, 20 Feb 2021 10:00:00 +0800

《Netty 源码剖析与应用》详细总结：写给从未接触过 Netty 的人

参考书籍：刘耀林《Netty 源码剖析与应用》（电子工业出版社，2020 年 11 月）目标读者：会 Java、听说过 Netty 但没系统学过，想一篇文章建立 Netty 核心知识框架的人。

〇、这本书讲什么？为什么学 Netty？

普通开发在工作中很少直接碰 Netty，但只要翻开任何一个主流分布式框架的底层源码，通信模块几乎都是它：Dubbo、gRPC、Spark、Flink、Elasticsearch、HBase（HBase 从 2.0 开始默认用 Netty RPC Server 替代原生实现）。不管是做 Java Web 后台还是大数据，Netty 都是绕不过去的地基。

为什么不直接用 JDK 的 NIO？作者的回答很直白：用原生 NIO 写一套高效稳定的通信模块非常难——要处理多路复用、粘包拆包、线程模型、内存管理、断线重连等一堆坑。Netty 把这些全部封装好，让普通人也能快速开发高性能、面向协议的服务端和客户端。

全书的结构是循序渐进的四部分：

flowchart LR
    A["第一部分：实战入门<br/>第1章 Netty基础篇<br/>第2章 原理部分<br/>第3章 分布式RPC"] --> B["第二部分：核心源码剖析<br/>第4章 核心组件<br/>（NioEventLoop/Channel/ByteBuf）<br/>第5章 读/写请求源码"]
    B --> C["第三部分：内存管理<br/>第6章 jemalloc内存池<br/>（全书最难）"]
    C --> D["第四部分：高级应用与调优<br/>第7章 时间轮高级应用<br/>第8章 问题分析与性能调优"]

两个贯穿全书的高级项目：一套类似 Dubbo 的分布式 RPC 框架（第 3 章写、第 8 章压测调优），以及一套基于时间轮的 10 亿级任务调度监控引擎（第 7 章）。

一、Netty 基础篇：先看长连接通信长什么样（第 1 章）

1.1 服务端五步法

Netty 服务端程序的固定套路：

创建两个线程组：Boss 线程组专门接收客户端连接；Worker 线程组处理已接收连接的 I/O 读写；
用启动辅助类 ServerBootstrap 配置启动参数（如 ChannelOption.SO_RCVBUF / SO_SNDBUF 设置接收/发送缓冲区大小）；
Boss 把接收到的连接注册到 Worker 后，交给 ChannelInitializer 初始化 Handler 链；
编写业务 Handler（继承 ChannelInboundHandlerAdapter，重写 channelRead）；
绑定端口——绑定由 Boss 线程完成，所以主线程要执行同步阻塞方法等待绑定完成。

这就是经典的主从 Reactor 模型：

flowchart TD
    subgraph BossGroup["Boss 线程组（接收连接）"]
        B1["Boss NioEventLoop<br/>监听 OP_ACCEPT"]
    end
    subgraph WorkerGroup["Worker 线程组（处理 I/O）"]
        W1["Worker 线程 1<br/>管理多个 Channel"]
        W2["Worker 线程 2<br/>管理多个 Channel"]
    end
    C1["客户端连接 1"] --> B1
    C2["客户端连接 2"] --> B1
    C3["客户端连接 3"] --> B1
    B1 -->|"注册 SocketChannel"| W1
    B1 -->|"注册 SocketChannel"| W2
    W1 --> P1["ChannelPipeline<br/>Decoder → 业务Handler → Encoder"]
    W2 --> P2["ChannelPipeline<br/>Decoder → 业务Handler → Encoder"]

1.2 一个值得琢磨的示例：客户端怎么"同步等"异步响应

第 1 章的客户端示例藏着一个 Netty 编程的核心范式。客户端连续发 100 个请求，服务端异步返回。问题是：channel.writeAndFlush() 是异步的，主线程怎么拿到响应结果？

书里的解法是自实现一套 RequestFuture 机制（这正是 Dubbo 等 RPC 框架的原型）：

每个请求带唯一 id，发送前把 RequestFuture 存入以 id 为 key 的 Map，主线程在 future.get() 上阻塞等待；
服务端 Handler 处理完后，把结果带上请求 id 写回；
客户端 channelRead 收到响应，按 id 找到对应的 Future，设置结果并唤醒主线程。

书中的思考题也很有意思：示例里客户端输出是有序的（按 id 逐个 get），如何修改代码让输出无序？——答案是不再按顺序 get，而是在响应到达的回调里直接输出。这个小实验能帮你真正理解"异步 + 回调"与"同步等待"的差别。

二、原理部分：绕不开的六块基石（第 2 章）

2.1 多路复用器：select、poll、epoll

BIO 时代每个 Socket 连接要一条线程同步阻塞，1 万连接就要 1 万条线程，根本扛不住。NIO 的**多路复用器（Selector）**让一条线程可以管理成千上万个连接的接入和读写事件。

三种经典模型的区别（面试高频）：

模型	遍历方式	连接数上限	触发方式
select	轮询全部 fd	1024 左右	水平触发
poll	轮询全部 fd	无硬上限	水平触发
epoll	回调就绪列表，只处理活跃连接	无硬上限	支持边缘触发

一个容易混淆的点：JDK 自带的 epoll 封装是水平触发（LT）的，而 Netty 通过 JNI 自己重写的 epoll 是边缘触发（ET）的，这也是 Netty 在 Linux 上推荐 EpollEventLoop 的原因之一。

2.2 Netty 的线程模型

Netty 的 Boss/Worker 默认线程数与 CPU 核数挂钩（默认核数 × 2）。Boss 只关心 OP_ACCEPT，接收连接后把 SocketChannel 按策略轮询注册到某个 Worker 的 Selector 上。关键约束：一个 Channel 在其生命周期内只绑定一个 EventLoop 线程，所以处理 Channel 的所有事件都不需要加锁——这是 Netty 高并发能力的重要来源。

2.3 编码和解码：TCP 粘包/半包问题

TCP 是面向字节流的协议，它把数据看成无结构的字节流，根本不知道"一条消息"的边界在哪。于是产生了经典问题：

粘包：两条消息被合并成一次发送/接收；
半包（拆包）：一条消息被拆成多次接收。

flowchart LR
    subgraph 发送方
        A["业务对象"] --> B["编码器 Encoder<br/>对象 → 字节"]
        B --> C["TCP 输出缓冲区<br/>SO_SNDBUF"]
    end
    C -->|"② TCP 网络传输<br/>（受滑动窗口/拥塞控制影响）"| D["TCP 输入缓冲区<br/>SO_RCVBUF"]
    subgraph 接收方
        D --> E["解码器 Decoder<br/>处理粘包/半包"]
        E --> F["业务对象"]
    end

Netty 的解法是在 Pipeline 里插解码器：固定长度解码器、分隔符解码器、长度字段解码器（LengthFieldBasedFrameDecoder，最常用）——协议头里放一个长度字段，解码器攒够一条完整消息才往下游传。书中第 3 章手写 RPC 时就是用自定义协议（协议头 + 长度 + 内容）解决的。

2.4 序列化：Protobuf 与 Kryo

Protobuf（Google）：跨语言、压缩率高（相同数据比 JSON 小 3~5 倍）、需要预定义 schema，适合 RPC 服务间通信；
Kryo：专注 Java，使用简单、速度快，但不跨语言，适合 Java 生态内部。

2.5 零拷贝：少搬一次数据是一次

零拷贝指操作数据时无须把 Buffer 从一个内存区域拷贝到另一个区域。Netty 里主要有三种场景：

堆外直接内存收发：用堆内存做 Socket 读写时，JVM 会先把堆内数据拷贝到堆外再写入 Socket；Netty 收发直接使用堆外内存，省掉这次拷贝；
CompositeByteBuf 组合视图：一条消息被拆成多个数据包时，把多个 Buffer 逻辑上组合成一个（类似数据库视图），而不是物理拷贝拼接；
FileChannel.transferTo()：文件传输直接在内核空间完成，不经用户态缓冲区。

2.6 背压（Backpressure）：让快生产者等一等慢消费者

flowchart LR
    subgraph 生产者
        P1["消息生产者 A<br/>写入缓存队列"]
        P2["消息生产者 B<br/>写入缓存队列"]
    end
    P1 & P2 --> Q["TCP 链路"]
    Q -->|"背压"| C["消费者<br/>I/O 读取放入缓存队列"]
    C -.->|"消费速率 < 生产速率时<br/>TCP 窗口缩小 → 通道阻塞<br/>→ 生产者降速"| P1

机制链条：消费者消费变慢 → TCP 接收缓冲区满 → TCP 滑动窗口变小 → 生产者发送缓冲区写不进去 → 生产者降速。书中还以 Flink 为例讲了它的应用：Flink 基于 Netty 实现了 credit-based（基于信用额度）的反压机制，下游告诉上游"我还能收多少"，从根本上防止快生产慢消费把系统压垮。

三、分布式 RPC：把 Netty 组装成一个 Dubbo（第 3 章）

这一章是全书第一个大项目：手写一套分布式 RPC。目标是业务方用起来像 SpringMVC/Dubbo 一样——引个 jar 包就行，不用关心 Netty 底层；服务端可动态扩容，不用写死 IP 端口。

flowchart TD
    subgraph 客户端
        A["业务代码<br/>像调用本地方法一样调用"] --> B["动态代理<br/>拦截方法调用"]
        B --> C["协议封装<br/>类名/方法名/参数 + 请求id"]
    end
    subgraph 网络层
        C --> D["Netty 长连接<br/>自定义协议 + Kryo 序列化"]
    end
    subgraph 服务端
        D --> E["Netty Server Handler<br/>解码出调用信息"]
        E --> F["Java 反射<br/>调用 Spring 容器中的实现类"]
    end
    subgraph 注册中心["Zookeeper 注册中心"]
        G["服务启动时注册<br/>IP/端口/权重"]
        H["客户端订阅服务列表<br/>负载均衡选择节点"]
    end
    F --> G
    C --> H

三个关键技术点：

协议设计：自定义协议头（魔数 + 长度 + 请求 id）+ 序列化内容，配合 LengthField 解码器解决粘包；
Java 反射解耦：服务端 Handler 解析出"类名 + 方法名 + 参数类型 + 参数值"，从 Spring 容器找到实现类反射调用——业务代码和 Netty 的 Handler 逻辑完全解耦；
服务注册与发现：引入 Zookeeper（对比了 Consul/ETCD/Eureka），服务端启动注册临时节点，客户端监听节点变化做动态感知和负载均衡（可按权重）。这一层替代了传统 Nginx/LVS 的硬负载方案。

四、核心组件源码剖析（第 4 章，全书的硬核部分）

4.1 NioEventLoopGroup 与 NioEventLoop：Netty 的发动机

NioEventLoopGroup 就是线程池，NioEventLoop 是里面的每条线程，每条线程一个 Selector，绑定一堆 Channel。核心在它的 run() 方法——一个永不退出的循环：

flowchart TD
    A["run() 死循环开始"] --> B["select() 轮询 I/O 事件<br/>（带超时，防止空轮询 bug）"]
    B --> C{"有就绪事件？"}
    C -- 是 --> D["处理 SelectionKey<br/>OP_ACCEPT / OP_READ / OP_WRITE"]
    C -- 否 --> E["跳过 I/O 处理"]
    D --> F["执行异步任务队列<br/>（用户提交的任务 + 定时任务）"]
    E --> F
    F -->|"ioRatio 控制 I/O 与任务的时间配比<br/>默认各 50%"| A
    B -.->|"连续空轮询超过阈值<br/>→ rebuildSelector() 重建 Selector<br/>（规避 JDK epoll 空轮询 bug）"| B

源码里的几个精妙优化，作者都点了出来：

SelectedSelectionKeySet：用数组替换 JDK Selector 内部的 HashSet，遍历就绪事件从哈希遍历变成数组遍历，更快；
Selector 重建：JDK epoll 有著名的"空轮询 bug"（select 立刻返回但无事件，CPU 100%），Netty 的解法是统计空轮询次数，超阈值就新建一个 Selector 把所有 Channel 迁过去；
ioRatio：I/O 处理与异步任务执行的时间比例可调，默认 50:50。

4.2 Channel 的继承体系：每层抽象都有明确职责

flowchart TD
    A["Channel 接口<br/>id/eventLoop/pipeline/config"] --> B["AbstractChannel<br/>模板方法：bind/connect/read/write<br/>持有 Unsafe 和 Pipeline"]
    B --> C["AbstractNioChannel<br/>对接 NIO：SelectionKey<br/>interestOps/readInterestOp"]
    C --> D["AbstractNioByteChannel<br/>字节流读写（TCP 数据通道）"]
    C --> E["AbstractNioMessageChannel<br/>消息读写（接收连接用）"]
    D --> F["NioSocketChannel<br/>客户端连接通道<br/>doRead/doWrite 具体实现"]
    E --> G["NioServerSocketChannel<br/>服务端监听通道<br/>doReadMessages = accept 新连接"]

读源码时最值得体会的设计：I/O 操作全部收敛到内部类 Unsafe 里，把"Netty 的 Channel API"和"JDK 底层的 Socket 操作"隔离开；doXxx() 抽象方法留给子类实现，AbstractChannel 用模板方法串起流程。书中还点名了 Netty 的性能优化手段：JDK 的 Unsafe、乐观锁、对象池等。

4.3 ByteBuf：比 NIO ByteBuffer 好用得多的缓冲区

JDK 的 ByteBuffer 只有一个 position 指针，读写模式要 flip() 来回切换，极易出错。Netty 的 ByteBuf 用读写分离的双指针：

flowchart LR
    subgraph ByteBuf["ByteBuf 内部结构"]
        A["[0, readerIndex)<br/>已读区域（可丢弃）"] --> B["[readerIndex, writerIndex)<br/>可读区域 readableBytes"]
        B --> C["[writerIndex, capacity)<br/>可写区域 writableBytes"]
    end

继承体系（每层干一件事）：

AbstractByteBuf：读写索引维护、边界检查；
AbstractReferenceCountedByteBuf：引用计数（retain()/release()），配合 ReferenceCountUpdater 用 CAS 乐观锁更新计数；
CompositeByteBuf：多个 Buffer 的逻辑组合（零拷贝场景 2）；
PooledByteBuf：池化缓冲区，用完归还对象池复用，是第 6 章内存管理的入口。

4.4 内存泄漏检测：弱引用 + 采样的巧思

堆外内存不归 GC 管，忘了 release() 就泄漏。Netty 的 ResourceLeakDetector 机制：

每个 ByteBuf 创建时（按级别采样，不是全量——开销可控）包装成弱引用/虚引用，记录创建时的调用栈；
ByteBuf 被 GC 时，若引用计数没归零，说明泄漏了；
从引用队列中捞出泄漏记录，打印带调用栈的告警日志。

这个机制本身就是一节生动的 JVM 引用类型教学课——书中还配了弱引用的 JUnit 测试用例帮助理解。

五、读/写请求源码剖析：一次 I/O 的完整旅程（第 5 章）

5.1 ServerBootstrap 启动过程

bind() 背后是：反射创建 NioServerSocketChannel → 初始化 Pipeline（插入 ServerBootstrapAcceptor）→ 注册到 Boss EventLoop → 绑定端口 → 监听 OP_ACCEPT。

5.2 接入与读写：两个 Unsafe 的分工

sequenceDiagram
    participant Client as 客户端
    participant Boss as Boss线程(NioMessageUnsafe)
    participant Acceptor as ServerBootstrapAcceptor
    participant Worker as Worker线程(NioByteUnsafe)
    participant Handler as 业务Handler链

    Client->>Boss: 发起 TCP 连接
    Boss->>Boss: 监听到 OP_ACCEPT<br/>accept 出 SocketChannel
    Boss->>Acceptor: fireChannelRead(新连接)
    Acceptor->>Worker: 设置 options/attrs<br/>注册到 Worker 的 Selector
    Client->>Worker: 发送数据
    Worker->>Worker: 监听到 OP_READ<br/>分配 ByteBuf 循环读
    Worker->>Handler: fireChannelRead(msg)<br/>沿 Pipeline 传播

Boss 侧用 NioMessageUnsafe（读出来的是"一条消息"= 一个新连接）；Worker 侧用 NioByteUnsafe（读出来的是字节流）——这就是第 4 章两个 AbstractNio 子类分工的实际体现；
OP_READ 是循环读：一次事件里反复读直到读空，每轮用 RecvByteBufAllocator 预测该分配多大的缓冲区（第 6 章细讲）；
写操作先进 ChannelOutboundBuffer 链表（Entry 节点用完回收进对象池），flush0() 时交给 NioSocketChannel.doWrite() 批量写（合并成 NIO_BUFFERS 数组一次 writev），写不完（TCP 缓冲区满）则注册 OP_WRITE 等可写时再续写——这就是写半包的处理。

六、内存管理：jemalloc 思想在 Java 的落地（第 6 章，最难也最值）

为什么 Netty 要自己管内存？堆外内存的 malloc/free 系统调用很贵，频繁申请释放是性能杀手。Netty 把 jemalloc 的分配思想搬到了 Java 里，三层结构：

flowchart TD
    subgraph 三层结构["内存分配的三层结构"]
        A["① PoolThreadCache<br/>本地线程缓存<br/>每个 I/O 线程一个，免锁"]
        B["② PoolArena<br/>分配区（arena）<br/>管理一组 PoolChunk"]
        C["③ 系统内存<br/>堆外/堆内直接申请"]
    end
    A -->|"缓存命中就直接用<br/>不命中向下申请"| B
    B -->|"没有可用 chunk 才申请"| C
    D["PoolChunk（默认 16MB）<br/>= 2048 个 page（8KB）"] -.属于.- B
    E["PoolSubpage<br/>把 page 再切成 tiny/small 小块"] -.切分.- D

分配策略（申请一块内存时）：

先查当前线程的 PoolThreadCache，命中直接返回——无线程竞争，无锁；
不命中则找 PoolArena 分配：大于等于 8KB 走 PoolChunk 按 page 分配；小于 8KB 走 PoolSubpage 把一个 page 切成更小的块（tiny/small 规格）；
Arena 也分不到，才向系统申请新 chunk（默认 16MB），用完放回 Arena 重复利用；
超大内存（超过 chunk 大小）不池化，直接申请、用完直接回收。

PoolChunk 内部用完全二叉树管理 2048 个 page：分配 ≥8KB 时在树上找深度合适的连续节点；PoolSubpage 用位图（bitmap）记录小块占用。PoolArena 里维护按使用率分档的 chunk 链表（qInit/q000/q025/q050/q075/q100），让分配尽量集中在少数 chunk 上，提高内存利用率。

最后一块拼图是 RecvByteBufAllocator（配合第 5 章的 OP_READ 循环读）：AdaptiveRecvByteBufAllocator 会自适应预测——这次实际读了多少，下次就按这个量级分配缓冲区（默认从 1KB 起步，在 64B ~ 64KB 之间动态调整），避免"每次固定分配 64KB 却只读到 16B"的浪费。

学习建议（书中原话）：这部分涉及大量多线程并发和位移与或非操作，把难以理解的代码贴到测试类里单独调试是最有效的办法。

七、时间轮高级应用：从心跳检测到 10 亿级任务监控（第 7 章）

7.1 HashedWheelTimer 的原理

IM 系统里有成千上万甚至百万条长连接链路，Netty 自带的心跳检测是给每条链路创建 ScheduledFutureTask 定时任务——链路多了定时任务就爆炸。时间轮（HashedWheelTimer）是另一种方案：只用一条额外的 Worker 线程，像钟表一样每隔一个 tick 走一格，只把当前格子的任务捞出来执行，没到的根本不碰。

flowchart TD
    subgraph 时间轮["时间轮（wheelSize 个刻度）"]
        direction LR
        T0["刻度 0<br/>task 链表"] --- T1["刻度 1<br/>task 链表"] --- T2["..."] --- TN["刻度 N-1<br/>task 链表"]
    end
    P["指针（tick）<br/>每 tickDuration 走一格"] --> T0
    W["Worker 线程<br/>tick++<br/>落格 = tick & (wheelSize-1)"] -.驱动.- P

先思考三个问题（书中的引导方式很好）：

指针走一轮是多久？ tickDuration × wheelSize；
用什么容器存任务？ 每个刻度（bucket）一条链表；
任务时间晚于一轮终点放哪？ 照样按落格公式放进去，任务上记录 round 数（还要等几圈），指针扫到它时 round 减 1，减到 0 才真正执行。

7.2~7.4 实战：外卖订单超时监控系统

书中设计的应用场景非常接地气：外卖平台每天上千万订单，用户下单后在规定时间内无人处理就要告警（超时要被投诉、要赔偿）。类似的还有优惠券过期提醒、医院预约提醒——凡是"与未来一段时间相关"的业务都能用。

但 10 亿级任务放内存里必然溢出，于是引出改造方案：

flowchart LR
    A["业务系统<br/>（外卖订单等）"] -->|"上报监控数据"| K["Kafka 数据源<br/>（处理能力弱时数据留在 Kafka，削峰）"]
    K --> B["时间轮计算服务<br/>（分布式部署，每分钟百万级吞吐）"]
    B <--> R["Redis<br/>任务数据按 时间轮节点wheel + 刻度idx 存储"]
    B -->|"到期且未处理（isOver=0）"| C["告警输出<br/>回调 callBackUrl / 通知相关人员"]

设计要点：

数据源选 Kafka：数据量大、要监控"是否被及时处理"，Kafka 天然削峰；
任务数据外置 Redis：内存里只放时间轮的调度结构，任务内容放 Redis，用"时间轮节点名称 wheel + 刻度编号 idx"做 key 映射，还能直接从 Redis 捞数据做问题定位；
监控数据通用化设计：dataId（唯一标识）、sysCode（系统来源）、detectionTime（检测时间）、isOver（是否结束，相当于任务取消）、isCycle/cycleTime（支持周期性调度监控）、callBackUrl（到期回调）——这套字段设计可以直接抄到自己的项目里。

八、问题分析与性能调优（第 8 章）

8.1 Linux 部署

把第 3 章的 RPC 服务部署到 Linux：分环境配置文件（server.properties：服务名、端口、Zookeeper 地址、权重，开发/测试/生产各一份）+ PropertyUtil 工具类加载 + shell 启动脚本。

8.2 JMeter 秒杀压测

普通 JMeter TCP 脚本只能压一台服务器，也不用为此加 Nginx/LVS——书中选择的方式是把 RPC 客户端打成 jar 包嵌入 JMeter（实现 AbstractJavaSamplerClient），直接模拟长连接高并发调用分布式服务，观察 TPS、并发用户数、平均响应耗时。

8.3 常见生产问题排查（实战中真能救命的套路）

症状	排查方法
内存溢出一定会出现（跑一段时间就炸）	`jmap -histo` 排序观察，看哪些对象增长快且不释放
内存溢出偶尔出现（很久才发生）	启动参数加 `-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/xxx.hprof`，溢出时自动快照，用 Eclipse MAT 分析
无溢出但响应慢、TPS 极低	`top -H -p pid` 找到 CPU 最高的线程 id → 转 16 进制小写 → `jstack -l pid \| grep '线程id'` 定位运行栈

8.4 性能调优三大方向

Linux 系统参数：压测常见的"文件句柄数过多"——全局改 /etc/sysctl.conf 加 fs.file-max=1000000（支持百万连接），sysctl -p 生效；局部改 /etc/security/limits.conf 加 * hard/soft nofile 1000000；
TCP 参数：缓冲区大小、 backlog 队列等内核参数调整；
Netty 应用层：理解第 6 章后大胆用内存池减少堆外分配次数；用第 7 章的时间轮替换默认心跳检测，减轻 I/O 线程负担。

书中一个坦诚的结论值得记住：无复杂业务逻辑时，Netty 不调优性能也已经很好——调优的价值在于真实业务（数据库操作、远程调用混入 Service 层）出现瓶颈时，你知道从哪里下手。

九、全书知识地图与结语

把全书浓缩成一张图：

mindmap
  root((Netty))
    应用层
      长连接通信（第1章）
      分布式RPC（第3章 协议+反射+ZK）
      时间轮（第7章 心跳/10亿级任务监控）
    原理层
      多路复用器 epoll/select
      Reactor线程模型 Boss/Worker
      编解码与粘包拆包
      序列化 Protobuf/Kryo
      零拷贝
      背压 TCP窗口/Flink
    源码层
      NioEventLoop run（）循环
      Channel继承体系/Unsafe
      ByteBuf 双指针/引用计数
      内存泄漏检测 弱引用+采样
      读写流程 accept/read/write半包
    内存层
      PoolThreadCache 线程缓存
      PoolArena/PoolChunk 16MB
      PoolSubpage 小块位图
      AdaptiveRecvByteBuf 自适应预测
    运维层
      Linux部署与句柄调优
      JMeter长连接压测
      jmap/MAT/jstack排查三板斧

最后给新人的学习路径建议（也是作者的阅读建议）：先跑通第 1 章的长连接示例和第 3 章的 RPC，建立"会用"的信心；再反复啃第 4~6 章源码（作者建议源码至少读 3 遍，直到对 Channel、Handler、NioEventLoop、ByteBuf 的各个方法都了如指掌）；最后用第 7、8 章的实战项目把知识串起来。Netty 涉及多线程、复杂数据结构与内存管理模型，读完它对并发编程能力的提升是肉眼可见的。

设计模式全景图：六大原则、23 种 GoF 模式与 J2EE 模式

Tue, 28 May 2019 14:00:00 +0800

设计模式全景图：六大原则、23 种 GoF 模式与 J2EE 模式

设计模式是面向对象设计中反复出现问题的可复用解决方案。掌握它们能够帮助我们写出更易扩展、更易维护、更清晰的代码。本文从六大设计原则出发，完整梳理 GoF 23 种设计模式以及 8 种 J2EE 模式，并配合类图、意图说明和 JDK/Spring 中的典型应用，帮助建立系统性的知识地图。

一、设计模式的六大原则

1. 开闭原则（Open Close Principle）

对扩展开放，对修改关闭。

当程序需要新增功能时，应通过增加新代码实现，而不是修改已有代码。核心手段是抽象化：使用接口和抽象类。

graph LR
    A[业务调用方] --> B[抽象接口]
    B --> C[旧实现]
    B --> D[新实现]
    style D fill:#e1f5e1

2. 里氏代换原则（Liskov Substitution Principle）

任何基类可以出现的地方，子类一定可以出现。子类替换基类后，程序功能不应受影响。

classDiagram
    class Animal { +eat() }
    class Dog { +eat() }
    class Cat { +eat() }
    Animal <|-- Dog
    Animal <|-- Cat

3. 依赖倒转原则（Dependence Inversion Principle）

高层模块和低层模块都应依赖抽象；要针对接口编程，而不是针对实现编程。

4. 接口隔离原则（Interface Segregation Principle）

使用多个职责单一的接口，优于使用一个庞大臃肿的接口，降低类之间的耦合。

graph TD
    A[大接口] -->|拆分为| B[接口A]
    A -->|拆分为| C[接口B]
    A -->|拆分为| D[接口C]
    B --> E[实现类1]
    C --> F[实现类2]
    D --> G[实现类3]

5. 迪米特法则 / 最少知道原则（Demeter Principle）

一个实体应尽量少地与其他实体发生直接交互，降低模块耦合，提高独立性。

6. 合成复用原则（Composite Reuse Principle）

优先使用组合/聚合来复用功能，而不是继承。组合更灵活，耦合更低。

classDiagram
    class Car { -Engine engine; +run() }
    class Engine { +start() }
    Car *-- Engine : 组合

二、设计模式分类概览

设计模式通常分为三大类：创建型、结构型、行为型。J2EE 模式则专注于企业应用和表示层。

mindmap
  root((设计模式))
    创建型模式 5种
      工厂模式
      抽象工厂模式
      单例模式
      建造者模式
      原型模式
    结构型模式 8种
      适配器模式
      桥接模式
      过滤器/标准模式
      组合模式
      装饰器模式
      外观模式
      享元模式
      代理模式
    行为型模式 13种 
      责任链模式
      命令模式
      解释器模式
      迭代器模式
      中介者模式
      备忘录模式
      观察者模式
      状态模式
      空对象模式
      策略模式
      模板模式
      访问者模式
    J2EE模式 8种 
      MVC模式
      业务代表模式
      组合实体模式
      数据访问对象模式
      前端控制器模式
      拦截过滤器模式
      服务定位器模式
      传输对象模式

三、创建型模式（Creational Patterns）

创建型模式关注对象的创建过程，隐藏创建逻辑，使程序在判断需要创建哪些对象时更灵活。

1. 工厂模式（Factory Pattern）

定义一个创建对象的接口，让子类决定实例化哪一个类。工厂方法使类的实例化延迟到子类。

classDiagram
    class Product { <<interface>> +use() }
    class ConcreteProductA { +use() }
    class ConcreteProductB { +use() }
    class Creator { +factoryMethod() Product }
    class ConcreteCreatorA { +factoryMethod() Product }
    class ConcreteCreatorB { +factoryMethod() Product }
    Product <|.. ConcreteProductA
    Product <|.. ConcreteProductB
    Creator <|-- ConcreteCreatorA
    Creator <|-- ConcreteCreatorB
    Creator ..> Product
    ConcreteCreatorA ..> ConcreteProductA
    ConcreteCreatorB ..> ConcreteProductB

JDK 应用： java.text.DateFormat.getDateInstance()、KeyGenerator.getInstance()。

2. 抽象工厂模式（Abstract Factory Pattern）

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

classDiagram
    class AbstractFactory { <<interface>> +createProductA() +createProductB() }
    class ConcreteFactory1 { +createProductA() +createProductB() }
    class ConcreteFactory2 { +createProductA() +createProductB() }
    class AbstractProductA
    class AbstractProductB
    AbstractFactory <|.. ConcreteFactory1
    AbstractFactory <|.. ConcreteFactory2
    ConcreteFactory1 ..> AbstractProductA
    ConcreteFactory1 ..> AbstractProductB
    ConcreteFactory2 ..> AbstractProductA
    ConcreteFactory2 ..> AbstractProductB

3. 单例模式（Singleton Pattern）

确保一个类只有一个实例，并提供一个全局访问点。

classDiagram
    class Singleton {
        -static Singleton instance
        -Singleton()
        +static getInstance() Singleton
    }

JDK 应用： Runtime.getRuntime()。Spring 应用： 默认 Bean 作用域为单例。

4. 建造者模式（Builder Pattern）

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

classDiagram
    class Product { +partA +partB +partC }
    class Builder { <<interface>> +buildPartA() +buildPartB() +getResult() }
    class ConcreteBuilder { +buildPartA() +buildPartB() +getResult() }
    class Director { +construct(builder) }
    Builder <|.. ConcreteBuilder
    ConcreteBuilder ..> Product
    Director ..> Builder

5. 原型模式（Prototype Pattern）

通过复制现有对象来创建新对象，而不是新建实例。适用于创建成本较高的对象。

classDiagram
    class Prototype { <<interface>> +clone() }
    class ConcretePrototype { +clone() }
    Prototype <|.. ConcretePrototype

JDK 应用： Object.clone()、Cloneable 接口。

四、结构型模式（Structural Patterns）

结构型模式关注对象之间的组合和关系，解决如何构建灵活且可复用的类和对象结构。

1. 适配器模式（Adapter Pattern）

将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的类可以协同工作。

classDiagram
    class Target { <<interface>> +request() }
    class Adapter { +request() }
    class Adaptee { +specificRequest() }
    Target <|.. Adapter
    Adapter --> Adaptee

JDK 应用： Arrays.asList()、InputStreamReader。

2. 桥接模式（Bridge Pattern）

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

classDiagram
    class Abstraction { -Implementor impl +operation() }
    class RefinedAbstraction { +operation() }
    class Implementor { <<interface>> +operationImpl() }
    class ConcreteImplementorA { +operationImpl() }
    class ConcreteImplementorB { +operationImpl() }
    Abstraction <|-- RefinedAbstraction
    Abstraction o-- Implementor
    Implementor <|.. ConcreteImplementorA
    Implementor <|.. ConcreteImplementorB

3. 过滤器模式 / 标准模式（Filter / Criteria Pattern）

使用不同的标准来过滤一组对象，并通过逻辑运算以解耦的方式把它们连接起来。常用于集合筛选。

classDiagram
    class Criteria { <<interface>> +meetCriteria(list) }
    class CriteriaMale { +meetCriteria(list) }
    class CriteriaFemale { +meetCriteria(list) }
    class AndCriteria { +meetCriteria(list) }
    class OrCriteria { +meetCriteria(list) }
    Criteria <|.. CriteriaMale
    Criteria <|.. CriteriaFemale
    Criteria <|.. AndCriteria
    Criteria <|.. OrCriteria
    AndCriteria --> Criteria
    OrCriteria --> Criteria

4. 组合模式（Composite Pattern）

将对象组合成树形结构以表示"部分-整体"的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

classDiagram
    class Component { +operation() }
    class Leaf { +operation() }
    class Composite { -children +add() +remove() +operation() }
    Component <|-- Leaf
    Component <|-- Composite
    Composite o-- Component

JDK 应用： java.awt.Container 与 Component。

5. 装饰器模式（Decorator Pattern）

动态地给一个对象添加一些额外的职责，比生成子类更灵活。

classDiagram
    class Component { <<interface>> +operation() }
    class ConcreteComponent { +operation() }
    class Decorator { -Component component +operation() }
    class ConcreteDecoratorA { +operation() }
    class ConcreteDecoratorB { +operation() }
    Component <|.. ConcreteComponent
    Component <|.. Decorator
    Decorator <|-- ConcreteDecoratorA
    Decorator <|-- ConcreteDecoratorB
    Decorator o-- Component

JDK 应用： Java IO 流 BufferedInputStream、DataInputStream、ZipOutputStream。

6. 外观模式（Facade Pattern）

为子系统中的一组接口提供一个一致的入口，定义了一个高层接口，使子系统更容易使用。

classDiagram
    class Facade { +simplifiedOperation() }
    class SubSystemA { +operationA() }
    class SubSystemB { +operationB() }
    class SubSystemC { +operationC() }
    Facade --> SubSystemA
    Facade --> SubSystemB
    Facade --> SubSystemC

7. 享元模式（Flyweight Pattern）

运用共享技术有效地支持大量细粒度对象，减少内存占用。

classDiagram
    class FlyweightFactory { -pool +getFlyweight(key) }
    class Flyweight { <<interface>> +operation() }
    class ConcreteFlyweight { +operation() }
    FlyweightFactory o-- Flyweight
    Flyweight <|.. ConcreteFlyweight

JDK 应用： Integer.valueOf() 缓存（-128-127）、String 常量池。

8. 代理模式（Proxy Pattern）

为其他对象提供一种代理以控制对这个对象的访问。

classDiagram
    class Subject { <<interface>> +request() }
    class RealSubject { +request() }
    class Proxy { -RealSubject real +request() }
    Subject <|.. RealSubject
    Subject <|.. Proxy
    Proxy --> RealSubject

JDK 应用： JDK 动态代理 Proxy.newProxyInstance()。Spring 应用： AOP 使用 JDK 动态代理和 CGLIB。

五、行为型模式（Behavioral Patterns）

行为型模式关注对象之间的通信和交互，解决对象之间的责任分配和算法封装。

1. 责任链模式（Chain of Responsibility Pattern）

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求。

classDiagram
    class Handler { <<interface>> +setNext(handler) +handle(request) }
    class ConcreteHandlerA { +handle(request) }
    class ConcreteHandlerB { +handle(request) }
    Handler <|.. ConcreteHandlerA
    Handler <|.. ConcreteHandlerB
    Handler --> Handler : next

2. 命令模式（Command Pattern）

将请求封装为对象，从而可以用不同的请求、队列或日志来参数化其他对象，同时支持可撤销操作。

classDiagram
    class Command { <<interface>> +execute() }
    class ConcreteCommand { -receiver +execute() }
    class Invoker { -command +setCommand() +invoke() }
    class Receiver { +action() }
    Command <|.. ConcreteCommand
    Invoker --> Command
    ConcreteCommand --> Receiver

3. 解释器模式（Interpreter Pattern）

给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

classDiagram
    class AbstractExpression { +interpret(context) }
    class TerminalExpression { +interpret(context) }
    class NonterminalExpression { +interpret(context) }
    AbstractExpression <|-- TerminalExpression
    AbstractExpression <|-- NonterminalExpression
    NonterminalExpression o-- AbstractExpression

JDK 应用： Java 正则表达式 Pattern 与 Matcher。

4. 迭代器模式（Iterator Pattern）

提供一种方法顺序访问一个聚合对象中的各个元素，而又无需暴露该对象的内部表示。

classDiagram
    class Iterator { <<interface>> +hasNext() +next() }
    class ConcreteIterator { +hasNext() +next() }
    class Aggregate { <<interface>> +createIterator() }
    class ConcreteAggregate { +createIterator() }
    Iterator <|.. ConcreteIterator
    Aggregate <|.. ConcreteAggregate
    ConcreteAggregate ..> ConcreteIterator

JDK 应用： java.util.Iterator、java.util.Enumeration。

5. 中介者模式（Mediator Pattern）

用一个中介对象来封装一系列对象交互，使对象不需要显式地相互引用，从而使其耦合松散。

classDiagram
    class Mediator { <<interface>> +send(message, colleague) }
    class ConcreteMediator { +send(message, colleague) }
    class Colleague { -Mediator mediator }
    class ConcreteColleagueA
    class ConcreteColleagueB
    Mediator <|.. ConcreteMediator
    Colleague <|-- ConcreteColleagueA
    Colleague <|-- ConcreteColleagueB
    Colleague --> Mediator
    ConcreteMediator --> ConcreteColleagueA
    ConcreteMediator --> ConcreteColleagueB

6. 备忘录模式（Memento Pattern）

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后恢复。

classDiagram
    class Originator { +createMemento() +restore(memento) }
    class Memento { -state }
    class Caretaker { -mementos }
    Originator ..> Memento
    Caretaker o-- Memento

7. 观察者模式（Observer Pattern）

定义对象间的一对多依赖关系，当一个对象状态发生改变时，所有依赖于它的对象都得到通知并自动更新。

classDiagram
    class Subject { <<interface>> +registerObserver() +removeObserver() +notifyObservers() }
    class ConcreteSubject { -state +notifyObservers() }
    class Observer { <<interface>> +update() }
    class ConcreteObserverA { +update() }
    class ConcreteObserverB { +update() }
    Subject <|.. ConcreteSubject
    Observer <|.. ConcreteObserverA
    Observer <|.. ConcreteObserverB
    ConcreteSubject --> Observer

JDK 应用： java.util.Observer（已弃用）和 Observable。Spring 应用： Spring 事件驱动模型 ApplicationEvent、ApplicationListener。

8. 状态模式（State Pattern）

允许对象在其内部状态改变时改变它的行为，对象看起来好像修改了它的类。

classDiagram
    class Context { -State state +request() }
    class State { <<interface>> +handle() }
    class ConcreteStateA { +handle() }
    class ConcreteStateB { +handle() }
    Context o-- State
    State <|.. ConcreteStateA
    State <|.. ConcreteStateB

9. 空对象模式（Null Object Pattern）

用一个空对象取代 null 检查，提供默认的"什么也不做"的行为，避免空指针异常。

classDiagram
    class Animal { <<interface>> +makeSound() }
    class Dog { +makeSound() }
    class NullAnimal { +makeSound() }
    Animal <|.. Dog
    Animal <|.. NullAnimal

10. 策略模式（Strategy Pattern）

定义一系列算法，把它们一个个封装起来，并且使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户。

classDiagram
    class Strategy { <<interface>> +execute() }
    class ConcreteStrategyA { +execute() }
    class ConcreteStrategyB { +execute() }
    class Context { -Strategy strategy +setStrategy() +executeStrategy() }
    Strategy <|.. ConcreteStrategyA
    Strategy <|.. ConcreteStrategyB
    Context o-- Strategy

JDK 应用： Comparator 接口与 Collections.sort()。

11. 模板模式（Template Pattern）

定义一个操作中的算法骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变算法结构即可重定义该算法的某些特定步骤。

classDiagram
    class AbstractClass { +templateMethod() +primitiveOperation() }
    class ConcreteClass { +primitiveOperation() }
    AbstractClass <|-- ConcreteClass

JDK 应用： Arrays.sort() 配合 Comparable。Spring 应用： RestTemplate、JmsTemplate、JpaTemplate。

12. 访问者模式（Visitor Pattern）

表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。

classDiagram
    class Element { <<interface>> +accept(visitor) }
    class ConcreteElementA { +accept(visitor) }
    class ConcreteElementB { +accept(visitor) }
    class Visitor { <<interface>> +visitA() +visitB() }
    class ConcreteVisitor { +visitA() +visitB() }
    Element <|.. ConcreteElementA
    Element <|.. ConcreteElementB
    Visitor <|.. ConcreteVisitor
    ConcreteElementA ..> Visitor
    ConcreteElementB ..> Visitor

六、J2EE 模式

J2EE 模式专注于企业应用，尤其是表示层和业务层的架构设计。这些模式由 Sun Java Center 鉴定。

1. MVC 模式（MVC Pattern）

将应用程序分为 Model（模型）、View（视图）、Controller（控制器）三层，实现关注点分离。

graph LR
    V[View] --> C[Controller]
    C --> M[Model]
    M --> V

Spring 应用： Spring MVC 是典型实现。

2. 业务代表模式（Business Delegate Pattern）

为表示层提供对业务服务的访问抽象，减少表示层与业务层之间的耦合。

graph LR
    A[Client/Controller] --> B[Business Delegate]
    B --> C[Business Service]
    C --> D[DAO/数据层]

3. 组合实体模式（Composite Entity Pattern）

将一组相关的持久化对象组合成一个粗粒度实体，减少网络调用次数，提高性能。

classDiagram
    class CompositeEntity { -DependentObjectA a -DependentObjectB b +getData() }
    class DependentObjectA
    class DependentObjectB
    CompositeEntity *-- DependentObjectA
    CompositeEntity *-- DependentObjectB

4. 数据访问对象模式（Data Access Object Pattern）

将底层数据访问逻辑与高层业务逻辑分离，提供一个统一的接口访问数据库。

graph LR
    A[Business Object] --> B[DAO Interface]
    B --> C[DAO Implementation]
    C --> D[Data Source/Database]

Spring 应用： Spring Data JPA、MyBatis Mapper 都是 DAO 模式的具体实现。

5. 前端控制器模式（Front Controller Pattern）

提供一个集中的入口点来处理所有请求，通常负责认证、日志、路由等横切关注点。

graph LR
    A[所有请求] --> B[Front Controller]
    B --> C[Dispatcher]
    C --> D[具体 Handler]

Spring 应用： DispatcherServlet 是前端控制器模式的实现。

6. 拦截过滤器模式（Intercepting Filter Pattern）

在请求到达目标处理器之前，通过一系列过滤器链对请求进行预处理（如编码、认证、日志）。

graph LR
    A[Request] --> F1[Filter 1]
    F1 --> F2[Filter 2]
    F2 --> F3[Filter N]
    F3 --> T[Target]
    T --> F3
    F3 --> F2
    F2 --> F1
    F1 --> R[Response]

Spring 应用： Spring 的 HandlerInterceptor、Servlet Filter。

7. 服务定位器模式（Service Locator Pattern）

提供一个中心化的注册表，用于获取服务实例，减少服务依赖的直接查找。

classDiagram
    class ServiceLocator { +getService(name) }
    class Cache { -services }
    class InitialContext { +lookup(name) }
    class Service { <<interface>> +execute() }
    ServiceLocator --> Cache
    ServiceLocator --> InitialContext
    ServiceLocator ..> Service

8. 传输对象模式（Transfer Object Pattern）

通过简单的 POJO 对象在不同层之间传输数据，减少远程调用的网络开销，也称为 DTO（Data Transfer Object）。

classDiagram
    class UserDTO { -id -name -email +getters/setters }
    class UserService { +getUserDTO(id) }
    class UserController { +showUser(dto) }
    UserService ..> UserDTO
    UserController ..> UserDTO

七、JDK、Java IO 与 Spring 中的模式速查

模式	JDK 示例	Spring 示例
工厂模式	`DateFormat.getDateInstance()`、`KeyGenerator.getInstance()`	`BeanFactory`
单例模式	`Runtime.getRuntime()`	默认 Bean 作用域
原型模式	`Object.clone()`、`Cloneable`	`@Scope("prototype")`
适配器模式	`Arrays.asList()`、`InputStreamReader`	MVC 的 Controller 适配器
装饰器模式	`BufferedInputStream`、`ZipOutputStream`	-
代理模式	JDK 动态代理	AOP
组合模式	`java.awt.Container` / `Component`	-
享元模式	`Integer.valueOf()`、`String` 常量池	-
模板方法模式	`Arrays.sort()` + `Comparable`	`RestTemplate`、`JpaTemplate`
策略模式	`Comparator`、`Collections.sort()`	`ResourceLoader` 策略
观察者模式	`Observer` / `Observable`	Spring 事件驱动模型
解释器模式	`Pattern` / `Matcher`	SpEL 表达式
责任链模式	Servlet Filter Chain	`HandlerInterceptor` 链
MVC 模式	-	Spring MVC
DAO 模式	JDBC Template	Spring Data JPA / MyBatis
前端控制器	-	`DispatcherServlet`

Java IO 中使用的模式

Java IO 同时使用了适配器模式和装饰器模式：

适配器模式： InputStreamReader 将 InputStream 字节流适配为 Reader 字符流。
装饰器模式： BufferedInputStream、DataInputStream、ZipOutputStream 等通过包装 InputStream 动态增强功能。

// 装饰器模式：逐层包装
InputStream fis = new FileInputStream("file.txt");
InputStream bis = new BufferedInputStream(fis);     // 增加缓冲
DataInputStream dis = new DataInputStream(bis);      // 增加基本类型读取

// 适配器模式：字节流转字符流
Reader reader = new InputStreamReader(fis, StandardCharsets.UTF_8);

八、如何选择设计模式

设计模式不是越复杂越好。选择时可以从以下角度思考：

问题类型：是对象创建、结构组织，还是行为交互？
变化方向：系统中哪些部分经常变化？把变化的部分封装起来。
开闭原则：新增功能时是否能不修改已有代码？
复杂度收益：不要为了用模式而增加不必要的抽象。

一张简化的决策地图：

flowchart TD
    A[遇到设计问题] --> B{对象创建复杂?}
    B -->|是| C[创建型模式]
    B -->|否| D{对象结构复杂?}
    D -->|是| E[结构型模式]
    D -->|否| F{对象交互复杂?}
    F -->|是| G[行为型模式]
    F -->|否| H[保持简单，遵循原则]

总结

设计模式是前人总结的设计经验，核心目标是让软件更易扩展、更易维护、更易理解。掌握它们的关键不是背诵每个类图，而是：

理解六大原则，它们是选择模式的判断依据；
熟悉 23 种 GoF 模式和 J2EE 模式的适用场景；
多读优秀源码（JDK、Spring），在真实代码中感受模式的应用；
避免过度设计，合适才是最好的。

从 BeanFactory 到 DispatcherServlet，从 Java IO 的装饰器到 Spring AOP 的代理，设计模式无处不在。理解这些模式，能帮助我们在面对复杂系统时做出更清晰的结构选择。

参考：

菜鸟教程 - 设计模式

dailyprogrammer - JDK 类库常用的设计模式

Design Patterns: Elements of Reusable Object-Oriented Software (GoF)

jphotoshop：用 Java Swing 手写一个 Photoshop——架构与算法全解析

Fri, 18 May 2018 10:00:00 +0800

jphotoshop：用 Java Swing 手写一个 Photoshop——架构与算法全解析

把多年前的一个练手项目整理开源了：jphotoshop，一个用纯 Java Swing 手写的 Photoshop 模拟器。不写不知道，写一个"简化版 PS"几乎把计算机图形学、数据结构和设计模式都过了一遍，这篇文章既是功能介绍，也是一次技术复盘。

开源地址：https://gitee.com/soulnew/jphotoshop
技术栈：Java + Swing（Swing Application Framework / JSR-296），NetBeans Ant 工程
规模：197 个 Java 文件，约 1.8 万行（自研约 1.4 万行），开发周期约半年

一、功能概览：一个"简化版 PS"能做什么

UI 形态上和老版 PS 一致：MDI 多文档界面——每张图片一个内部编辑窗口，图层面板、导航缩放面板都是可拖动的浮动内窗。

1.1 图层系统

多图层编辑：图像图层、文字图层、浮动选区层（拖动选区内容时的临时层）；
图层面板带 40×30 实时缩略图，支持拖拽换序（基于 Swing TransferHandler 的 DnD）、复制粘贴为新图层；
透明区域用经典的灰白棋盘格打底。

1.2 选区工具（7 个）

工具	说明
魔棒	容差可调（默认 23），支持多连通区域一次选中
色彩范围	全图相似色选取
多边形套索	逐点勾勒
自由套索	鼠标轨迹勾勒
磁性套索	局部窗口内吸附边缘（完成度不高）
贝塞尔选区	双击闭合时自动做曲线拟合，生成平滑选区
移动工具	把选区内容提成浮动层，拖动实时合成，松手落回底层

选区还支持：羽化（可调半径）、反选、平移/缩放（AffineTransform）、以及标志性的蚂蚁线动画。

1.3 滤镜（24 个，分 5 大类）

模糊：均值平滑、高斯模糊（3×3 高斯核 {1,2,1;2,4,2;1,2,1}/16）、中值滤波；
锐化：Sharpen / SharpenMore（拉普拉斯卷积核 {0,-1,0;-1,5,-1;0,-1,0}）；
艺术：曝光过度、冰晶、熔岩、暗调（平方衰减）、漫画等 8 种风格化效果；
简单：反色、怀旧（sepia 矩阵 0.393/0.769/0.189...）、灰度；
扭曲：挤压、球面化、正/反旋转、正弦波浪、摩尔纹——扭曲类全部带多段滑块实时预览，取消可还原。

1.4 图像调整与文字

HSB 调整：先把整图 RGB 转成 HSB 三维 float 数组，色相/饱和度/亮度三个滑块实时调节再转回 RGB；
对比度调整；
文字工具：点击图片任意位置就地出现透明输入框 + 字体选择面板，完成后生成为独立的文字图层。

1.5 文件与工程

打开 jpg / png / gif / bmp；
自定义 .jps 工程格式（类似 PSD）：整个图层模型实现 Serializable，用 ObjectOutputStream 套 GZIPOutputStream 序列化保存，可以随时回来继续编辑；
复制 / 剪切 / 粘贴、导航缩放窗口、中文界面。

二、架构总览

graph TD
    A["JPhotoShop 入口<br/>EDT 中构建主窗口"] --> B["JDesktopPane MDI 主框架"]
    B --> C["EditFrame 编辑窗口<br/>每张图一个"]
    B --> D["LayerControl 图层面板"]
    B --> E["ViewSizeFrame 导航/缩放"]
    C --> F["EditModel<br/>像素模型 + MemoryImageSource 渲染"]
    F --> G["ImageModel<br/>LinkedList 图层栈"]
    G --> H["ImagePaintLayer / TextPaintLayer / TempImageLayer"]
    H --> I["LayerPlug 混合样式<br/>Alpha 合成"]
    C --> J["ToolManager<br/>工具代理/状态切换"]
    J --> K["Tool 抽象类<br/>魔棒/套索/贝塞尔/移动/文字..."]
    C --> L["FilterManager<br/>properties + 反射装配"]
    L --> M["PicFilter 滤镜即 Action"]
    M --> N["Math 包<br/>CoverOp 卷积 / FeatherSide 羽化<br/>FindSide 轮廓追踪 / PointConnection 并查集"]

整体分四层：UI 层（MDI 窗口与面板）、模型层（图层栈与像素数据）、工具/滤镜层（操作入口）、算法层（jphotoshop.Math 包）。工具和滤镜都通过 properties 配置 + 反射装配，下面详细说。

三、技术亮点

3.1 自绘像素管线：int[][] + MemoryImageSource

核心存储没有用 BufferedImage，而是直接操作 int[][] ARGB 二维数组——所有算法（卷积、混合、羽化）都在裸数组上做，直观且没有额外封装开销。

显示侧用了一个当年很典型的 Swing 高性能技巧：MemoryImageSource + setAnimated(true)，像素变化后调 newPixels() 增量刷新屏幕图像，避免每次重绘都重建整个 Image 对象。编辑、拖选区、调滤镜滑块时的实时反馈都靠它撑着。

3.2 链式图层合成缓存

多图层合成是最频繁的操作，朴素实现是每次重绘把所有层从头合一遍。这里的做法是给每个图层挂一个"本层与下面所有层合成结果的缓存 cacheData"，层与层之间用 backLayer 引用连成链：

graph LR
    BG["背景层<br/>棋盘格"] -->|"合成"| L1["图层1<br/>cacheData"]
    L1 -->|"合成"| L2["图层2<br/>cacheData"]
    L2 -->|"合成"| L3["图层3<br/>cacheData"]
    L3 --> OUT["最终显示图像"]
    style L2 fill:#f96
    L2 -. "仅从此层向上重建" .-> L3

某一层像素变化时，只从该层向上依次 reBuild，下面的层缓存不动。层数多、图大时，这个收益非常明显。

3.3 手写 Alpha 混合

AlphaLayerStyle 实现了逐像素的经典混合公式 C = α·Cf + (1-α)·Cb，并且处理了任意偏移（含负坐标裁剪）——浮动选区拖到画布边缘外也能正确合成。羽化后的选区掩码是 short 型 alpha 权重，抠图粘贴时按权重衰减，边缘不会出现生硬的锯齿。

3.4 魔棒：一条完整的算法链

魔棒是整个项目里算法含量最高的功能，完整链路分三步：

graph TD
    A["用户点击图片某点"] --> B["Flood Fill 泛洪填充<br/>8邻域 + 容差判断<br/>ΔR+ΔG+ΔB ＜ range"]
    B --> C["PointConnection 并查集<br/>id 数组 + sz 数组按秩合并<br/>分离多个互不连通的区域"]
    C --> D["FindSide 8方向轮廓追踪<br/>沿区域边界走一圈<br/>每3步抽稀路径点"]
    D --> E["GeneralPath 选区路径"]
    E --> F["蚂蚁线动画<br/>Timer 500ms 切换两条相位差3的虚线"]

几个细节：

泛洪填充用 LinkedList 当队列，容差判断用曼哈顿距离（|ΔR|+|ΔG|+|ΔB|），比欧氏距离省开方；
一次点击可能选中多个互不连通的区域（比如图片里分散的几块蓝天），用并查集把连通域分组，每个域独立生成轮廓；
轮廓追踪把面状的 boolean 掩码转成线状的路径点列，这一步直接决定蚂蚁线的平滑程度；
蚂蚁线动画是两条相位差为 3 的虚线 BasicStroke 用 500ms 的 Timer 交替绘制——朴素但效果完全对味。

3.5 通用卷积引擎 CoverOp

所有卷积类滤镜（模糊、锐化背后是同一个引擎 CoverOp，提供三种重载：

全图卷积；
掩码限定区域卷积——滤镜只在选区内生效，这是 PS 的基本体验；
short alpha 掩码卷积——配合羽化选区做渐变处理。

RGB 三通道分离卷积 + 边界 clamp，滤镜类只需要给一个卷积核就完事。新增一个模糊变体的成本是十几行代码。

3.6 贝塞尔选区：Schneider 曲线拟合

自由手绘的选区轨迹是抖动的折线，直接当选区很难看。贝塞尔选区工具在双击闭合时调用 JHotDraw 的 Bezier.fitCurve（Schneider 的经典拟合算法），把鼠标点列拟合成平滑的三次贝塞尔曲线段——这就是 PS 里"钢笔工具"的底层原理。

3.7 声明式装配：properties + 反射的原始"插件化"

工具和滤镜都不写死在代码里，而是从 properties 读类名、Class.forName 反射实例化：

# resource/filters.properties
filters.Kinds=模糊,锐化,艺术效果,简单,扭曲
模糊=Smooth,GaussBlur,Median

加一个新滤镜 = 写一个类 + 改一行配置，菜单自动按分类分组生成。工具栏同理（ToolManager.initTool）。项目里还专门有一个 plug 包在探索真正的外部插件机制（虽然只是个雏形）。在 2007 年没有 OSGi、没有 IoC 框架依赖的纯 Swing 工程里，这是最务实的可扩展方案。

3.8 工具架构：Proxy + State 的混合

Tool 抽象类把底层 MouseEvent 翻译成语义化回调（click / pressed / dragged / release / rightClick / clickDouble / move），子类只关心语义。ToolManager 本身也是 Tool 的子类，作为代理把事件转发给当前激活的工具——选中哪个工具，事件流就切到哪个状态机上。每个工具还可以自带 getPlugPanel() 参数面板，选中时挂到选项栏上，和 PS 的交互完全一致。

3.9 扭曲滤镜的"预览-取消"模式

扭曲类滤镜（球面、旋转、波浪……）都是坐标重映射：对每个目标像素做逆极坐标变换，找它在原图的取样点。为了支持滑块实时预览又能取消还原，ContortFilter 在打开对话框时先备份 tempData，滑块每次变化都在备份基础上重算，点取消直接把备份拷回——一个廉价的 Memento 模式。配套的 MultiSlider 多段滑块控件也是自绘的。

3.10 滤镜即 Action

PicFilter extends AbstractAction，滤镜本身就是可以挂进菜单/工具栏的 Action：actionPerformed 里自动取当前窗口、当前图层、当前选区掩码，还处理了选区坐标系到图层坐标系的换算（start -= layerStart），执行完触发 rePaintEdit 刷新。框架把脏活都干了，滤镜作者只需要关注像素算法。

四、诚实的复盘：留下了什么遗憾

开源的代码就是当年的样子，包括未完成的部分，如实列出：

撤销/重做是空架子：UndoRedoManager 的骨架搭好了，但 propertyChange 三个分支全是空的——这是当时没啃下来的硬骨头，现在看应该用 Command 模式重做，而不是当初设想的 property 监听方案；
历史面板、通道面板、外部插件机制都只有雏形；
磁性套索完成度不高；
若干小 bug，比如 FindSide 里找最近点写成了找最远点（if (temp > MinLength) 应为 <）、"undo".endsWith(...) 应为 startsWith、几处类名 typo（WaveFiler、getSize 拼写）——权当留给读者的"考古彩蛋"。

五、写在最后

写 jphotoshop 的半年收获远超预期：并查集、轮廓追踪、卷积、贝塞尔拟合这些算法不再是教科书上的名词，而是要亲手调到能跑的东西；合成缓存、声明式装配、Action 抽象这些设计，也都是被真实需求逼出来的。如果你也想扎实练一次"算法 + 工程"的综合功，手写一个图像编辑器是我能想到的最好题目之一。

源码在 https://gitee.com/soulnew/jphotoshop，欢迎 Star、Fork，更欢迎把那个空着的 UndoRedoManager 补上。

Java 高并发编程实战：同步工具、锁与线程池

Wed, 28 Mar 2018 14:00:00 +0800

Java 高并发编程实战：同步工具、锁与线程池

高并发程序的核心不是“让线程跑得多快”，而是让多个线程在共享可变状态下安全、可预期地协作。JDK 的 java.util.concurrent（JUC）包已经为我们提供了大量经过打磨的同步工具，善用它们比手写 wait/notify 要可靠得多。

一、高层次思想：并发编程在解决什么问题？

并发编程的本质是约束：当多个线程访问同一组可变资源时，通过某种机制保证以下三件事至少满足其一：

互斥：同一时刻只有一个线程能访问临界区。
可见性：一个线程修改的状态，其他线程能正确看到。
有序性：指令不会被编译器或 CPU 乱序到破坏程序语义。

graph TD
    A[共享可变状态] -->|互斥| B[锁 / 信号量]
    A -->|可见性| C[volatile / happens-before]
    A -->|有序性| D[内存屏障 / 同步原语]
    B --> E[正确的并发程序]
    C --> E
    D --> E

首选策略金字塔（从推荐到不推荐）：

graph LR
    A[不可变对象 & 线程封闭] --> B[JUC 并发集合 / 线程池]
    B --> C[高级同步工具 CountDownLatch Semaphore 等]
    C --> D[ReentrantLock & Condition]
    D --> E[synchronized]
    E --> F[手写 wait/notify]

避坑指南 #1：不到万不得已不要手写 wait/notify，极容易写出遗漏 notify、虚假唤醒、持锁休眠等问题。JUC 工具类已经帮你封装好了。

二、线程状态与原语对照

方法	调用者	是否释放锁	进入状态	唤醒条件
`Thread.sleep(ms)`	当前线程	否	`TIMED_WAITING`	时间到
`Thread.yield()`	当前线程	否	`RUNNABLE`（让出 CPU）	OS 调度
`t.join()` / `t.join(ms)`	当前线程等 t	否	`WAITING` / `TIMED_WAITING`	t 结束或超时
`obj.wait()`	当前线程	是	`WAITING`	`notify/notifyAll` 或超时
`obj.notify()`	当前线程	否	—	唤醒一个等待线程

stateDiagram-v2
    [*] --> 新建: new Thread()
    新建 --> 就绪: start()
    就绪 --> 运行: 调度
    运行 --> 就绪: yield / 时间片到
    运行 --> 阻塞: 等待锁
    阻塞 --> 就绪: 获得锁
    运行 --> 等待: wait / join / await
    等待 --> 就绪: notify / 超时 / 被等待线程结束
    运行 --> 超时等待: sleep / wait(timeout)
    超时等待 --> 就绪: 时间到
    运行 --> 终止: 执行完毕

避坑指南 #2：sleep 不释放锁，若在 synchronized 块内 sleep，其他线程会被长时间阻塞。需要“让出锁去等”时，用 wait/Condition.await。

三、多用 JUC 同步类，少用 wait/notify

3.1 Semaphore（信号量）

信号量维护一组“许可”，控制同时访问某资源的线程数量。

Semaphore semaphore = new Semaphore(3); // 最多 3 个线程并发

try {
    semaphore.acquire();
    // 访问受限资源
} finally {
    semaphore.release();
}

graph LR
    A[线程1] -->|acquire| S[许可池 3]
    B[线程2] -->|acquire| S
    C[线程3] -->|acquire| S
    D[线程4] -->|acquire 阻塞| S
    S -->|release| S

避坑指南 #3：release() 一定要放在 finally 里，否则异常会导致许可泄漏，最终所有线程都拿不到许可。

3.2 CountDownLatch 与 CyclicBarrier

特性	CountDownLatch	CyclicBarrier
方向	一个线程等待其他线程	多个线程互相等待
可复用	否（一次性）	是（可 reset）
计数归零后	门闩打开，直接退出	所有线程同时继续

graph LR
    subgraph CountDownLatch
        M[主线程 await] -.->|计数=0| M2[继续执行]
        W1[工作线程1] -->|countDown| C[计数器]
        W2[工作线程2] -->|countDown| C
    end

    subgraph CyclicBarrier
        T1[线程A await] --> B[屏障]
        T2[线程B await] --> B
        T3[线程C await] --> B
        B -->|全部到达| Go[一起继续]
    end

避坑指南 #4：不要把 CountDownLatch 当循环栅栏用，计数到 0 后无法重置；需要循环同步用 CyclicBarrier。

3.3 Exchanger

Exchanger 让两个线程在某个同步点交换数据，适合生产者-消费者配对场景，但使用频率较低。

四、volatile：可见性与有序性，但不保证原子性

volatile 的三条语义：

可见性：写操作会刷入主内存，读操作会从主内存刷新。
有序性：禁止指令重排序（happens-before）。
不保证原子性：复合操作（如 i++）仍需要锁或原子类。

graph LR
    A[线程A 写 volatile flag=true] -->| happens-before | B[线程B 读 flag]
    B --> C[线程B 看到 flag 之前所有写入]

// 错误示例：volatile 不能保证 i++ 原子
private volatile int count = 0;
public void increment() {
    count++; // 读-改-写，非原子
}

// 正确做法
private final AtomicInteger count = new AtomicInteger(0);
public void increment() {
    count.incrementAndGet();
}

避坑指南 #5：只有在单次写、多次读、且不依赖前值的场景下才用 volatile（如状态标志 volatile boolean running = true）。

五、死锁：原因与破解

5.1 典型死锁

graph LR
    T1[线程1] -->|持有 A 锁| B[等待 B 锁]
    T2[线程2] -->|持有 B 锁| A[等待 A 锁]
    B --> T2
    A --> T1

// 错误：锁顺序不一致
devoid transfer(Account a, Account b, int amount) {
    synchronized(a) {
        synchronized(b) { ... }
    }
}

5.2 常见诱因

不一致的加锁顺序：两个线程以不同顺序获取多把锁。
在同步块内调用外部同步方法：引入了不可控的锁依赖。
持锁等待 I/O / 网络 / 用户输入：放大了死锁窗口。

5.3 破解方案

全局统一锁顺序：先按对象哈希值排序再加锁。
使用 tryLock 超时获取锁，失败则回退并重试。
减少锁粒度，避免在同步块内调用外部方法（Open Call）。

// 使用 ReentrantLock 的 tryLock 避免死锁
if (lockA.tryLock(1, TimeUnit.SECONDS)) {
    try {
        if (lockB.tryLock(1, TimeUnit.SECONDS)) {
            try {
                // 执行业务
            } finally { lockB.unlock(); }
        }
    } finally { lockA.unlock(); }
}

避坑指南 #6：死锁往往不是锁本身的问题，而是锁的顺序和依赖关系的问题。设计阶段先画锁依赖图，能发现大部分隐患。

六、公平锁 vs 非公平锁

ReentrantLock fairLock = new ReentrantLock(true);   // 公平
ReentrantLock unfairLock = new ReentrantLock(false); // 非公平（默认）

graph LR
    subgraph 公平锁
        Q[等待队列 T1→T2→T3] -->|按顺序| L[锁]
    end
    subgraph 非公平锁
        N[新线程] -->|插队尝试| L2[锁]
        Q2[队列 T1→T2] -.->|可能继续等待| L2
    end

公平锁：按请求顺序分配锁，减少饥饿，但上下文切换多、吞吐低。
非公平锁：允许“插队”，若锁恰好可用，新线程可直接获取，减少唤醒延迟；但老线程可能长时间等待。

避坑指南 #7：默认选非公平锁即可，性能更好。除非业务明确要求严格的调度公平性（如资源分配器），否则不必打开公平模式。

七、Condition：比 wait/notify 更精确的线程协作

一个 ReentrantLock 可以创建多个 Condition，分别管理不同的等待队列。

graph TD
    L[ReentrantLock] --> C1[Condition A 队列]
    L --> C2[Condition B 队列]
    L --> C3[Condition C 队列]
    C1 -->|signal| W1[唤醒指定线程]

public class PrintABC {
    private final Lock lock = new ReentrantLock();
    private final Condition a = lock.newCondition();
    private final Condition b = lock.newCondition();
    private final Condition c = lock.newCondition();
    private volatile int index = 0;

    private void print(String name, int expect, Condition wait, Condition next) {
        new Thread(() -> {
            lock.lock();
            try {
                while (index != expect) {
                    wait.await();
                }
                System.out.print(name);
                index = (expect + 1) % 3;
                next.signal();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                lock.unlock();
            }
        }).start();
    }

    public static void main(String[] args) {
        PrintABC p = new PrintABC();
        p.print("A", 0, p.a, p.b);
        p.print("B", 1, p.b, p.c);
        p.print("C", 2, p.c, p.a);
    }
}

避坑指南 #8：Condition.await/signal 与 wait/notify 一样，必须在持有锁的线程中调用，且 await 要用 while 循环而不是 if，防止虚假唤醒。

八、线程池：不要裸开线程

8.1 常见工厂方法

方法	特点	隐患
`newSingleThreadExecutor`	单线程，按提交顺序执行	无界队列，任务堆积会 OOM
`newFixedThreadPool(n)`	固定线程数	同样使用无界队列
`newCachedThreadPool`	线程可复用、可无限创建	高并发下线程数爆炸
`newScheduledThreadPool`	支持定时/周期任务	注意任务异常终止

8.2 ThreadPoolExecutor 核心参数

graph LR
    T[提交任务] -->|核心线程数未满| C[创建核心线程]
    T -->|队列未满| Q[进入阻塞队列]
    T -->|队列满且线程数<max| M[创建非核心线程]
    T -->|队列满且线程数=max| R[拒绝策略]
    C --> E[执行]
    Q --> E
    M --> E

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4,                      // 核心线程数
    8,                      // 最大线程数
    60L, TimeUnit.SECONDS,  // 非核心线程空闲存活时间
    new ArrayBlockingQueue<>(100), // 有界队列
    new ThreadFactoryBuilder().setNameFormat("biz-pool-%d").build(),
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);

避坑指南 #9：

生产环境尽量直接创建 ThreadPoolExecutor，不要用 Executors 的便捷工厂（无界队列/无限线程是 OOM 元凶）。

任务抛异常会导致线程被回收重建，建议任务内部 try/catch 并记录。

应用关闭前调用 shutdown() 或 shutdownNow()，否则 JVM 可能不会退出。

九、阻塞队列

队列	有界性	实现	特点
`ArrayBlockingQueue`	有界	数组 + ReentrantLock	高吞吐、需要指定容量
`LinkedBlockingQueue`	可选有界	链表 + 两把锁（take/put）	默认无界，小心 OOM
`PriorityBlockingQueue`	无界	堆	按优先级出队
`DelayQueue`	无界	堆	元素到延迟时间才能出队
`SynchronousQueue`	零容量	无缓冲区	一手交钱一手交货
`LinkedTransferQueue`	无界	无锁 CAS	支持 transfer 直接传递
`LinkedBlockingDeque`	无界	双向链表	支持两端操作

graph LR
    P[生产者 put] --> Q[阻塞队列]
    Q --> C[消费者 take]
    P -.->|队列满| W1[阻塞]
    C -.->|队列空| W2[阻塞]

避坑指南 #10：无界阻塞队列在生产者快、消费者慢时会把内存撑爆。优先使用 ArrayBlockingQueue 或指定容量的 LinkedBlockingQueue。

十、自旋锁、ReentrantLock 与 synchronized

10.1 自旋锁

public class SpinLock {
    private final AtomicReference<Thread> owner = new AtomicReference<>();

    public void lock() {
        Thread t = Thread.currentThread();
        while (!owner.compareAndSet(null, t)) {
            // 自旋等待，不进入内核态
        }
    }

    public void unlock() {
        Thread t = Thread.currentThread();
        owner.compareAndSet(t, null);
    }
}

graph LR
    A[互斥锁 sleep] -->|上下文切换| B[内核阻塞]
    C[自旋锁 CAS] -->|用户态循环| D[CPU 忙等]

优点：没有线程上下文切换开销。
缺点：持锁时间长会浪费 CPU；同一线程不可重入，递归调用会死锁。

10.2 ReentrantLock 与 synchronized 对比

能力	synchronized	ReentrantLock
可重入	是	是
可中断	否	`lockInterruptibly()`
超时获取	否	`tryLock(timeout)`
公平锁	否	可选
多条件队列	一个 wait set	多个 Condition
性能	JDK6+ 优化后接近	接近

避坑指南 #11：ReentrantLock 必须显式 unlock()，否则即使异常也会死锁；务必放在 finally 中。synchronized 则由 JVM 保证自动释放。

10.3 偏向锁

偏向锁是 JVM 对无竞争同步的优化：第一次获取锁时把线程 ID 记录到对象头，之后同一线程再进入无需 CAS。

注意：JDK 15 开始偏向锁默认禁用（-XX:+UseBiasedLocking 已废弃），因为现代应用中锁竞争更频繁，撤销偏向锁的开销反而可能大于收益。

十一、线程安全的 Singleton

11.1 饿汉式（类加载时初始化）

public class Singleton {
    private static final Singleton INSTANCE = new Singleton();
    private Singleton() {}
    public static Singleton getInstance() { return INSTANCE; }
}

借助类加载机制保证线程安全，简单可靠；若实例创建开销大且未必使用，则浪费资源。

11.2 静态内部类（推荐）

public class Singleton {
    private Singleton() {}
    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }
    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

graph LR
    A[调用 getInstance] -->|首次触发| B[加载 Holder 类]
    B --> C[初始化 INSTANCE]
    C --> D[返回唯一实例]

延迟加载 + 类加载保证线程安全，是大多数场景下的最佳实践。

11.3 双重检查锁（DCL）+ volatile

public class Singleton {
    private Singleton() {}
    private static volatile Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // 禁止指令重排
                }
            }
        }
        return instance;
    }
}

避坑指南 #12：DCL 必须加 volatile，否则 new Singleton() 的指令重排会导致其他线程读到未构造完成的对象。

十二、synchronized 的底层行为

synchronized 可以修饰方法或代码块，锁对象分别是：

实例方法：当前实例 this。
静态方法：类的 Class 对象。
代码块：括号里指定的对象。

graph TD
    O[对象头 Mark Word] -->|无锁| A[无锁状态]
    A -->|第一个线程获取| B[偏向锁]
    B -->|出现竞争| C[轻量级锁 CAS]
    C -->|竞争加剧| D[重量级锁 操作系统 Mutex]

避坑指南 #13：不要把 synchronized 当成“只要包住就安全”的万金油。锁的对象要选对，锁的粒度要尽量小，避免锁住整个方法或无关代码。

十三、避坑速查表

不要这样做	推荐做法
手写 `wait/notify` 做复杂协调	用 `CountDownLatch`、`CyclicBarrier`、`Semaphore`
用 `volatile` 做 `i++`	用 `AtomicInteger` 或 `LongAdder`
裸 `new Thread()`	用 `ThreadPoolExecutor`
`Executors.newFixedThreadPool` 无脑用	自定义有界队列 + 拒绝策略
在锁里调外部同步方法 / 阻塞 I/O	缩小锁范围，使用 Open Call
不一致的加锁顺序	全局排序或使用 `tryLock`
DCL 不加 `volatile`	必须加 `volatile`，或改用静态内部类
自旋锁里递归加锁	使用可重入锁 `ReentrantLock`
忽略 `InterruptedException`	恢复中断标志 `Thread.currentThread().interrupt()`
线程池任务吞掉异常	任务内部 `try/catch` 或使用 `Future.get()`

十四、总结

Java 高并发编程的演进路径，其实是从“手动管理线程和锁”走向“使用高层抽象”。牢记下面三句话：

能不变就不变：优先使用不可变对象、线程封闭和 JUC 并发集合。
能用高层就不用底层：用 Semaphore、CountDownLatch、Executor 替代 wait/notify。
锁是最后手段：如果必须用锁，确保加锁顺序一致、粒度最小、持有时间最短。

把这三点落地到代码里，配合上面的图例和示例，就能避开大多数并发陷阱。

参考与延伸阅读

《Java 并发编程实战》（Java Concurrency in Practice）
《Java 并发编程的艺术》
JDK 文档：java.util.concurrent

JVM 内功修炼：运行时数据区、GC 演进与现代调优实践

Wed, 28 Mar 2018 14:00:00 +0800

JVM 内功修炼：运行时数据区、GC 演进与现代调优实践

JVM 是 Java 程序员逃不掉的「操作系统」。懂它不是为了背八股，而是为了在 OOM、Full GC、CPU 飙升时，能一眼定位根因并给出调优方案。

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

JVM 的核心职责可以抽象成三件事：

一次编译，到处运行：通过字节码 + 解释/编译执行，屏蔽底层 OS 与硬件差异。
自动内存管理：让开发者专注于业务，而不是像 C/C++ 那样手动 malloc/free。
运行时优化：JIT 编译、逃逸分析、内联、锁消除等，把「解释执行」慢慢优化成「本地机器码执行」。

graph LR
    A[.java 源码] -->|javac| B[字节码 .class]
    B -->|类加载子系统| C[方法区/Metaspace]
    C -->|解释器| D[逐行解释执行]
    C -->|JIT 编译器| E[本地机器码]
    D --> F[执行引擎]
    E --> F
    F --> G[操作系统]

避坑指南 #1：不要只把 JVM 当「黑盒」。线上 90% 的 Java 性能问题，根源都在堆外内存泄漏、GC 停顿过长、Metaspace 膨胀、线程栈溢出这四类。

二、运行时数据区：新版 JDK 的版图

不同虚拟机的运行时数据区实现略有差异，但都遵循《Java 虚拟机规范》。现代视角下，区域可划分为「线程私有」和「线程共享」两类：

graph TD
    subgraph 线程私有
        A[程序计数器 PC Register]
        B[虚拟机栈 JVM Stack]
        C[本地方法栈 Native Method Stack]
    end
    subgraph 线程共享
        D[堆 Heap]
        E[方法区 Method Area / Metaspace]
        F[直接内存 Direct Memory]
    end
    A --> G[线程执行上下文]
    B --> G
    C --> G
    D --> H[几乎所有对象实例]
    E --> I[类元数据/常量/静态变量]
    F --> J[NIO / 堆外内存]

2.1 程序计数器（Program Counter Register）

当前线程执行字节码的行号指示器。
分支、循环、跳转、异常处理、线程恢复都依赖它。
线程私有，生命周期与线程一致。
唯一一个在《Java 虚拟机规范》中没有规定 OOM 的区域。

2.2 Java 虚拟机栈（JVM Stack）

每个方法执行时创建一个栈帧（Stack Frame）。
栈帧里包含：局部变量表、操作数栈、动态链接、方法返回地址。
局部变量表中的基本数据类型和对象引用在编译期大小就确定。

graph TD
    A[JVM Stack] --> B[栈帧 Frame 1]
    A --> C[栈帧 Frame 2]
    A --> D[栈帧 Frame 3]
    B --> B1[局部变量表]
    B --> B2[操作数栈]
    B --> B3[动态链接]
    B --> B4[方法返回地址]

避坑指南 #2：-Xss 设置线程栈大小。递归过深、方法调用链过长会抛出 StackOverflowError；如果线程创建太多，总栈空间超过限制，会抛出 OutOfMemoryError: unable to create new native thread。

2.3 本地方法栈（Native Method Stack）

与虚拟机栈作用相同，只是为 Native 方法服务。
HotSpot 中把虚拟机栈和本地方法栈合二为一了。

2.4 Java 堆（Java Heap）

JVM 管理的最大一块内存，被所有线程共享。
几乎所有对象实例和数组都在这里分配。
现代 GC 基本都采用分代收集，逻辑上分为新生代、老年代。

graph LR
    A[Java Heap] --> B[Young Generation 新生代]
    A --> C[Old Generation 老年代]
    B --> D[Eden 区]
    B --> E[Survivor From]
    B --> F[Survivor To]

避坑指南 #3：不要把「堆」和「栈」对立记忆。对象在堆里，引用在栈里；但 HotSpot 的逃逸分析 + 标量替换会把未逃逸的小对象直接分配在栈上，减轻 GC 压力。

2.5 方法区（Method Area）与 Metaspace

存储类信息、常量、静态变量、JIT 编译后的代码缓存。
JDK 7 之前：方法区在 PermGen（永久代）中，大小固定，-XX:MaxPermSize。
JDK 8 及以后：PermGen 被移除，方法区使用本地内存中的 Metaspace，默认只受限于系统内存，用 -XX:MaxMetaspaceSize 控制。

版本	实现	配置参数	常见问题
JDK 7-	PermGen	`-XX:PermSize` / `-XX:MaxPermSize`	动态生成类过多导致 `OutOfMemoryError: PermGen space`
JDK 8+	Metaspace	`-XX:MetaspaceSize` / `-XX:MaxMetaspaceSize`	类加载器泄漏导致 Metaspace 持续增长

避坑指南 #4：Metaspace 默认无上限，服务运行久了可能把容器内存撑爆。线上建议显式设置 -XX:MaxMetaspaceSize，配合监控告警。

2.6 直接内存（Direct Memory）

不属于 JVM 堆，但会被 JVM 直接使用，常见于 NIO 的 DirectByteBuffer。
分配和回收成本较高，但读写 I/O 时避免了堆内外内存拷贝（Zero Copy）。
默认大小约等于 -Xmx，可用 -XX:MaxDirectMemorySize 控制。

避坑指南 #5：Netty、RocketMQ、Elasticsearch 等中间件大量使用堆外内存。出现 OutOfMemoryError: Direct buffer memory 时，先检查是否有 ByteBuf / DirectByteBuffer 未释放，而不是盲目加堆内存。

三、垃圾回收：从算法到收集器演进

3.1 判断对象是否存活

引用计数法：Python 用，但 Java 不用，因为解决不了循环引用。
可达性分析（Reachability Analysis）：从 GC Roots 出发，不可达则回收。

常见 GC Roots：

虚拟机栈中局部变量表引用的对象。
方法区中类静态属性、常量引用的对象。
本地方法栈中 JNI 引用的对象。
被同步锁持有的对象。

graph TD
    A[GC Roots] --> B[栈帧局部变量]
    A --> C[静态变量]
    A --> D[常量]
    A --> E[JNI 引用]
    A --> F[锁持有对象]
    B --> G[可达对象]
    C --> G
    D --> H[不可达对象<br/>等待回收]

3.2 四种基础 GC 算法

算法	思想	优点	缺点
标记-清除	标记无用对象，然后清除	简单，不需要移动对象	效率低，产生内存碎片
复制	内存分两块，活着的对象复制到另一块	无碎片，回收效率高	内存利用率只有一半
标记-整理	标记后把存活对象移到一端，清理边界外	无碎片，内存利用率高	移动对象开销大
分代收集	按对象存活周期分代，不同代用不同算法	兼顾吞吐与停顿	需要维护复杂的跨代引用

3.3 经典垃圾收集器

收集器	工作区域	算法	特点	适用场景	状态
Serial	新生代	复制	单线程，简单高效	客户端模式 / 单核	可用
ParNew	新生代	复制	Serial 的多线程版	配合 CMS	随 CMS 移除
Parallel Scavenge	新生代	复制	吞吐量优先	后台计算	可用
Serial Old	老年代	标记-整理	单线程	客户端模式	可用
Parallel Old	老年代	标记-整理	多线程吞吐量优先	后台计算	可用
CMS	老年代	标记-清除	低停顿，并发收集	互联网低延迟服务	JDK 14 已移除
G1	整堆	标记-整理 + 复制	可控停顿， region 化	大堆、低延迟	JDK 9-22 默认
ZGC	整堆	标记-复制/整理	亚毫秒停顿，TB 级堆	极低延迟	JDK 23+ 默认（分代）
Shenandoah	整堆	标记-复制/整理	低停顿，独立于分代	低延迟	可用，JDK 24 实验分代

graph LR
    A[Serial] --> B[ParNew]
    B --> C[Parallel Scavenge]
    C --> D[G1]
    D --> E[ZGC / Shenandoah]
    style E fill:#f9f,stroke:#333

3.4 分代模型的工作流程

新生代默认占堆的 1/3，老年代占 2/3。新生代内部 Eden:From Survivor:To Survivor 默认约为 8:1:1。

sequenceDiagram
    participant Eden
    participant From as Survivor From
    participant To as Survivor To
    participant Old as Old Generation
    Note over Eden,Old: Minor GC 触发
    Eden->>To: 存活对象复制到 To
    From->>To: 存活对象复制到 To
    From->>Old: 年龄超过阈值的对象晋升
    Note over Eden,From: 清空 Eden 和 From
    To->>From: To 变 From，From 变 To

避坑指南 #6：不要把 Survivor 区看作「两个对称缓存区」。它们在一次 Minor GC 后会交换身份，始终有一个是空的，用于下一次复制目标。

3.5 G1 收集器：里程碑式的设计

G1（Garbage First）把堆划分为多个大小相等的 Region，每个 Region 动态扮演 Eden、Survivor 或 Old 角色。

graph TD
    A[G1 Heap Regions] --> B[Eden Region]
    A --> C[Survivor Region]
    A --> D[Old Region]
    A --> E[Humongous Region<br/>大对象]
    A --> F[Free Region]

G1 的核心优势：

可预测的停顿时间模型：通过 -XX:MaxGCPauseMillis 设定目标停顿。
整体基于标记-整理，局部基于复制：不会产生大面积内存碎片。
回收优先级按垃圾最多的 Region 来：Garbage First 名字来源。

避坑指南 #7：G1 的 -XX:MaxGCPauseMillis 不是越小越好。设得太低（如 50ms）会导致回收 Region 太少、GC 频率飙升，反而降低吞吐。通常建议 100-200ms。

3.6 现代低延迟 GC：ZGC 与 Shenandoah

特性	ZGC	Shenandoah
设计目标	亚毫秒级停顿，支持 TB 级堆	低停顿，独立于分代
并发能力	标记、转移、重定位几乎都并发	并发标记、并发压缩
着色指针	使用	不使用
分代	JDK 21 引入分代 ZGC，JDK 23 起为默认	JDK 24 引入实验性分代 Shenandoah
适用版本	JDK 11+（生产推荐 JDK 17+）	OpenJDK 12+

graph LR
    A[传统 GC<br/>Serial/Parallel/CMS/G1] -->|停顿目标 ms~百 ms 级| B[G1]
    B -->|停顿目标 < 10ms| C[ZGC / Shenandoah]
    C -->|JDK 21+| D[分代 ZGC]
    D -->|JDK 23+| E[分代 ZGC 默认]
    C -->|JDK 24+| F[分代 Shenandoah 实验]

高性能建议 #1：如果应用对延迟敏感（如金融交易、在线游戏、实时推荐），JDK 17 下优先考虑 G1；JDK 21+ 可直接启用 分代 ZGC（-XX:+UseZGC -XX:+ZGenerational），在吞吐和延迟之间取得更好平衡；升级到 JDK 23+ 后分代 ZGC 已是默认，无需额外参数。

3.7 JDK 21/22/23/24 的 GC 演进大事记

JDK 版本	GC 相关变化	影响
JDK 21	JEP 439 正式发布分代 ZGC	默认仍是 G1，但可显式启用 `-XX:+ZGenerational` 获得更低延迟
JDK 22	JEP 423 G1 Region Pinning	G1 在 JNI 临界区内无需禁用 GC，降低延迟毛刺
JDK 23	JEP 474 分代 ZGC 成为默认；非分代 ZGC 废弃	新默认 GC 从 G1 切换到分代 ZGC，亚毫秒级停顿更易获得
JDK 23	JDK-8322630 ZGC 延迟优化	减少 GC 根节点扫描抖动
JDK 24	JEP 490 移除非分代 ZGC	简化 ZGC 维护，统一使用分代模式
JDK 24	JEP 404 分代 Shenandoah（实验性）	Shenandoah 也走向分代，未来低延迟 GC 竞争更激烈
JDK 24	JEP 475 G1 Late Barrier Expansion	优化 G1 写屏障，提升编译和运行时性能

timeline
    title GC 默认与里程碑
    section JDK 8
        默认 : Parallel Scavenge + Parallel Old
    section JDK 9
        默认 : G1
    section JDK 11
        ZGC 实验性
    section JDK 15
        ZGC 生产可用
    section JDK 17
        G1 默认，ZGC/Shenandoah 成熟
    section JDK 21
        分代 ZGC 正式发布（仍非默认）
    section JDK 23
        分代 ZGC 成为默认 GC
    section JDK 24
        非分代 ZGC 移除；分代 Shenandoah 实验

避坑指南 #7.5：网上有说法称 “JDK 21 默认 GC 是 ZGC”，这是错误的。JDK 21 默认仍是 G1；分代 ZGC 只是正式发布，需要显式开启。真正的默认切换发生在 JDK 23。

四、引用类型：不只是强引用

引用类型	回收时机	使用场景
强引用	永不回收，即使 OOM	普通对象
软引用 SoftReference	内存不足前回收	缓存，如图片缓存
弱引用 WeakReference	下一次 GC 时回收	防止内存泄漏，如 `WeakHashMap`
虚引用 PhantomReference	随时可能被回收，必须配合 ReferenceQueue	跟踪对象被回收的事件，做资源后置清理

graph LR
    A[强引用] -->|最强| B[不会被回收]
    C[软引用] -->|内存紧张| D[回收]
    E[弱引用] -->|下次 GC| F[回收]
    G[虚引用] -->|无法获取对象| H[仅回收通知]

避坑指南 #8：不要把软引用当「万能缓存」。在内存紧张时软引用会被批量回收，导致缓存命中率骤降。高并发缓存建议用 Caffeine 等带 TTL 和淘汰策略的专业缓存框架。

五、类加载机制：双亲委派与破坏

5.1 类加载器层次

graph TD
    A[自定义类加载器] -->|委托| B[应用程序类加载器 AppClassLoader]
    B -->|委托| C[平台类加载器 PlatformClassLoader]
    C -->|委托| D[启动类加载器 BootstrapClassLoader]

注意：JDK 9 引入模块化系统后，原来的 Extension ClassLoader 被改名为 Platform ClassLoader，负责加载平台模块（如 java.sql、java.xml 等）。

5.2 双亲委派模型

类加载器收到加载请求，先不自己加载。
向上委托给父加载器。
父加载器无法加载时，子加载器才尝试加载。

避坑指南 #9：Tomcat、SPI、OSGi 都破坏了双亲委派。如果你的项目出现 NoSuchMethodError / ClassCastException: cannot cast to the same class，很可能是同一个类被不同类加载器加载了两次。

六、JIT 编译与执行优化

Java 代码先被解释器执行，热点代码会被 JIT 编译成本地机器码。

6.1 HotSpot 的两层编译器

编译器	别称	特点
C1	Client Compiler	编译快，优化简单，适合启动速度和 GUI
C2	Server Compiler	编译慢，激进优化，适合长期运行的服务端

JDK 7 引入分层编译（Tiered Compilation），JDK 8 默认开启：

0: 解释执行
1~3: C1 编译，带简单/复杂优化
4: C2 编译，激进优化

6.2 常见 JIT 优化

优化	说明
方法内联	把短方法体直接嵌入调用处，减少栈帧开销
逃逸分析	判断对象是否逃出方法/线程作用域
标量替换	把对象拆成基本类型分配在栈上
锁消除	确认对象只被单线程访问时去掉同步锁
锁粗化	把相邻的同步块合并，减少加解锁次数

高性能建议 #2：不要过度纠结「每个对象都在堆上分配」。现代 JVM 的逃逸分析已经很强，写代码时优先保证对象作用域最小化、避免无意义的全局引用，让 JIT 有优化空间。

七、现代 JVM 前沿特性（JDK 21+）

除了 GC，JDK 21 及之后版本还在内存模型、执行模型和 Native 互操作上做了大量演进，这些也会间接影响 JVM 调优思路。

7.1 虚拟线程（Virtual Threads，JEP 444 / JDK 21）

虚拟线程是 JVM 管理的轻量级线程，由 JVM 调度到少量平台线程（Carrier Thread）上运行。
创建成本极低（KB 级栈），适合高并发 I/O 密集型应用。
对 JVM 数据区的影响：虚拟线程的栈帧仍存在于 Java 堆中（作为 Continuation 对象），而不是传统的线程栈。

graph LR
    A[平台线程 Platform Thread] -->|1:N 映射| B[虚拟线程 Virtual Thread]
    B -->|挂载| C[Carrier Thread]
    C -->|运行在| D[OS 线程]

避坑指南 #9.5：虚拟线程虽好，但不要和 synchronized 块、本地方法、文件 I/O 混用导致 “Pinning”，会让载体线程被卡住，降低并发收益。优先使用 ReentrantLock 和异步 I/O。

7.2 Foreign Function & Memory API（JEP 454 / JDK 22）

正式替代 sun.misc.Unsafe 进行堆外内存操作。
通过 Arena 管理堆外内存生命周期，更安全、更可移植。
对直接内存调优的影响：未来 DirectByteBuffer 的底层实现会逐步迁移到 FFM API。

7.3 Project Lilliput：压缩对象头

目标是把 HotSpot 的对象头从 96/128 bit 压缩到 64 bit。
可以显著降低内存占用，提升缓存命中率。
JDK 24 起部分功能已集成（如 64-bit object headers）。

7.4 Project Valhalla：值类型（Value Classes / Primitive Classes）

引入 “值对象”，避免对象头和引用开销。
未来 int[] 和 Integer[] 之间的性能鸿沟会缩小。
目前处于预览阶段，持续关注即可。

7.5 Project Leyden：Java 静态镜像

目标是通过 “静态图像” 加速 Java 启动时间。
类似 GraalVM Native Image，但保持完整 Java 语义和 JVM 运行时能力。
对 Serverless、CLI 工具、云原生场景意义重大。

八、避坑指南：线上常见问题

8.1 慎用 `System.gc()`

只是「建议」JVM 进行 Full GC，不保证执行。
很多框架（如某些老版本 JDBC）会调用它，导致不可控停顿。
线上建议关闭：-XX:+DisableExplicitGC。

8.2 finalize() 已过时

JDK 9 起标记为 @Deprecated。
对象回收前不保证一定执行 finalize()，且执行顺序不确定。
资源清理用 try-with-resources 或 Cleaner。

8.3 大对象与 Humongous

G1 中超过 Region 大小一半的对象叫 Humongous Object，直接进老年代，增加 GC 负担。
避免一次性创建超大数组或字符串。

8.4 动态代理与 CGLIB 的 Metaspace 泄漏

Spring AOP、MyBatis、Dubbo 大量生成代理类。
如果 ClassLoader 没释放，代理类元数据会持续占用 Metaspace。
常见于热部署、OSGi、动态脚本场景。

8.5 大堆 + Full GC 的雪崩

堆内存越大，G1 的 Mixed GC、CMS 的 Full GC 停顿越长。
超过 32GB 时，指针压缩会失效，对象头变大，反而浪费内存。
建议堆大小控制在 16GB-32GB 之间，再大的堆考虑横向拆分服务或换 ZGC。

九、高性能调优建议

9.1 选择 GC 与 JDK 版本

场景	推荐配置
通用 Web 服务，JDK 17-22	`-XX:+UseG1GC -XX:MaxGCPauseMillis=200`
通用 Web 服务，JDK 23+	默认已是分代 ZGC，一般无需改动
延迟敏感，JDK 21-22	`-XX:+UseZGC -XX:+ZGenerational`
延迟敏感，JDK 23+	默认分代 ZGC，无需显式开启
批处理/大数据，吞吐优先	`-XX:+UseParallelGC` 或 G1
容器环境	显式设置 `-Xmx`、`-Xms`、`-XX:MaxMetaspaceSize`，并开启 `-XX:+UseContainerSupport`

9.2 参数模板

JDK 17-22 通用 Web 服务（G1）

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -jar app.jar

JDK 23+ 通用 Web 服务（默认分代 ZGC）

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

说明：JDK 23 起默认就是分代 ZGC，不需要 -XX:+UseZGC。如果仍想显式启用，可保留；如果想用回 G1，使用 -XX:+UseG1GC。

9.3 监控与诊断三板斧

工具	用途
`jstat -gcutil <pid> 1000`	实时查看 GC 频率与内存占比
`jmap -dump:format=b,file=... <pid>`	生成堆快照，MAT 分析内存泄漏
`jstack <pid>`	打印线程栈，排查死锁与 CPU 热点
GC 日志 / `-Xlog:gc*`	分析 GC 原因与停顿时间
`async-profiler`	低开销 CPU/内存/锁分析

高性能建议 #3：调优前一定先定目标——是降低停顿？提高吞吐？还是减少内存？没有目标的调优就是瞎调。先用 GC 日志和监控找到瓶颈，再改参数，而不是反向操作。

十、JVM 问题排查实战：发现 → 定位 → 修复

线上 JVM 问题通常表现为：服务卡顿、响应 P99 飙高、CPU 打满、内存持续增长、频繁 OOM。解决它们的核心思路是：先量化，再猜测。

10.1 问题发现的四层入口

graph TD
    A[业务层] -->|接口超时/P99 飙升| B[应用层]
    B -->|Full GC 频繁/GC 时间长| C[JVM 层]
    C -->|堆/栈/Metaspace 异常| D[系统层]
    D -->|容器 OOMKilled/CPU 限流| E[基础设施层]

入口	典型现象	常见根因
业务监控	接口 RT 上涨、错误率增加	GC 停顿、线程阻塞、锁竞争
APM / Trace	某段链路偶发耗时几百 ms	Full GC、Metaspace 扩容、类加载
容器监控	Pod 内存触顶被 OOMKilled	堆外内存泄漏、堆太大、Metaspace 无上限
GC 日志	GC 频率异常、停顿时间超标	收集器选择不当、堆大小不合理、大对象过多
JVM 告警	Heap 使用率 > 85%、FGC 次数突增	内存泄漏、流量突增、缓存失控

10.2 排查工具箱

10.2.1 命令行工具（适合快速止血）

命令	场景	输出重点
`jps -lvm`	找到 Java 进程 PID	主类名、启动参数
`jstat -gcutil <pid> 1000`	实时监控 GC 与内存	S0/S1/E/O/M 各区使用率、YGC/FGC 次数
`jmap -heap <pid>`	查看堆配置与概览	新生代/老年代大小、收集器
`jmap -histo <pid>`	查看对象直方图	哪个类实例数/占用最多
`jmap -dump:format=b,file=... <pid>`	生成堆 dump	配合 MAT / JProfiler 分析
`jstack <pid>`	打印线程栈	死锁、CPU 热点线程、Blocked 线程
`jcmd <pid> VM.native_memory summary`	查看 Native Memory Tracking	堆外内存、Metaspace、Symbol 区占用

10.2.2 可视化 / 专业工具

工具	适用场景	特点
MAT (Eclipse Memory Analyzer)	分析堆 dump	大对象、内存泄漏、支配树、Leak Suspects
JProfiler / YourKit	全链路 JVM 分析	CPU、内存、线程、GC 一体化
async-profiler	生产环境火焰图	低开销，适合线上持续采样
GCViewer / GCEasy	解析 GC 日志	可视化 GC 事件、停顿分布
Prometheus + Grafana	长期监控与告警	自定义 JVM 指标大盘
Arthas	线上实时诊断	无需重启，支持 trace、watch、thread、heapdump

10.3 典型问题排查流程

场景 1：CPU 飙升

# 1. 找到 CPU 占用最高的线程
ps -mp <pid> -o THREAD,tid,time | sort -rn

# 2. 把 tid 转成十六进制
printf "%x\n" <tid>

# 3. 用 jstack 查看对应线程栈
jstack <pid> | grep -A 30 <hex_tid>

常见根因：

死循环或复杂正则
Young GC 过于频繁
JIT 编译器 C2 线程忙碌（启动期正常）
大量 ThreadLocal 未清理

场景 2：内存持续增长 / OOM

# 1. 确认哪个区域增长
jstat -gcutil <pid> 1000

# 2. 开启 Native Memory Tracking
jcmd <pid> VM.native_memory baseline
jcmd <pid> VM.native_memory summary.diff

# 3. 触发堆 dump（若还能响应）
jmap -dump:live,format=b,file=/tmp/heap.hprof <pid>

常见根因：

堆：缓存无淘汰、大对象、集合只增不减
Metaspace：动态代理/CGLIB 类加载器泄漏
堆外：Netty ByteBuf 未释放、NIO DirectBuffer 堆积

场景 3：接口偶发卡顿 / P99 高

打开 GC 日志，看是否有 长停顿。
用 jstack 抓取卡顿时刻线程栈，看是否有大量 BLOCKED。
用 async-profiler 采集 CPU 火焰图，定位热点方法。
检查是否有 System.gc()、Metaspace 扩容、类加载抖动。

10.4 JVM 监控告警建议

建议把以下指标接入 Prometheus + Grafana，并设置合理阈值：

指标	告警阈值建议	说明
`jvm_memory_used_bytes / jvm_memory_max_bytes`	> 85%	堆/非堆内存使用率
`jvm_gc_pause_seconds_sum`	P99 > 200ms	GC 停顿时间
`jvm_gc_memory_allocated_bytes_total` 增长率	突增 2 倍以上	对象分配速率异常
`jvm_classes_loaded_total`	持续增长	类泄漏嫌疑
`process_cpu_usage`	> 80% 持续 5min	CPU 压力
`jvm_threads_live`	突增或接近上限	线程泄漏
容器维度 `container_memory_working_set_bytes`	> 90% limit	容器 OOMKilled 预警

graph LR
    A[应用埋点] -->|Micrometer| B[Prometheus]
    C[GC 日志] -->|Loki / Filebeat| D[日志平台]
    B --> E[Grafana 大盘]
    D --> E
    E -->|阈值触发| F[AlertManager]
    F -->|通知| G[钉钉/企业微信/Slack]

十一、不同场景的 JVM 配置策略

11.1 配置前的通用原则

先压测，再调优：没有真实流量数据，调参都是拍脑袋。
Xms = Xmx：避免运行时堆扩容带来的 GC 抖动。
Metaspace 必须设上限：容器环境下尤其重要。
GC 日志一定要开：-Xlog:gc*（JDK 9+）成本很低，信息无价。
容器环境开启 Container Support：-XX:+UseContainerSupport（JDK 8u191+/10+ 默认开启）。
不要堆内存无限大：超过 32GB 指针压缩失效，性价比骤降。

11.2 场景一：高并发 Web / API 服务

特征：QPS 高、对象生命周期短、响应延迟敏感。

目标：降低 GC 停顿、控制 P99。

推荐配置（JDK 17-22，G1）：

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=100 \
  -XX:InitiatingHeapOccupancyPercent=35 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

推荐配置（JDK 23+，默认分代 ZGC）：

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

调优要点：

新生代尽量大，让短生命周期对象在 Young GC 回收。
-XX:MaxGCPauseMillis 根据业务容忍度设置，100-200ms 常见。
监控 jvm_gc_pause_seconds_sum，若频繁触发 Mixed GC，考虑增大 -XX:InitiatingHeapOccupancyPercent。

11.3 场景二：高流量 / 削峰填谷（消息队列消费者）

特征：突发流量、消息处理批量化、吞吐优先、允许一定延迟。

目标：提高吞吐，避免 OOM 和 Full GC。

推荐配置：

java \
  -Xms8g -Xmx8g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=300 \
  -XX:G1HeapRegionSize=16m \
  -XX:InitiatingHeapOccupancyPercent=40 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar consumer.jar

调优要点：

堆可以比 Web 服务稍大，因为要缓冲突发消息。
批量消费时注意控制单次拉取消息数，避免一次创建过多对象。
如果业务允许更高延迟，可考虑 -XX:+UseParallelGC 追求极致吞吐。

11.4 场景三：低延迟金融 / 交易 / 实时推荐

特征：P99 要求 < 10ms，任何 GC 停顿都可能导致业务损失。

目标：亚毫秒级 GC 停顿。

推荐配置（JDK 21+）：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseZGC \
  -XX:+ZGenerational \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar trading.jar

JDK 23+ 可简化为（默认就是分代 ZGC）：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar trading.jar

调优要点：

堆 > 16GB 时 ZGC 优势更明显。
避免大对象（Humongous），ZGC 对大对象分配路径不如小对象高效。
监控 jvm_gc_pause_seconds_max，正常应在 1ms 以内。

11.5 场景四：大数据 / 批处理 / ETL

特征：长时间运行、对象存活久、吞吐优先、延迟不敏感。

目标：最大化吞吐，减少总 GC 时间。

推荐配置：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=512m \
  -XX:MaxMetaspaceSize=1g \
  -XX:+UseParallelGC \
  -XX:ParallelGCThreads=8 \
  -XX:+UseLargePages \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar etl.jar

调优要点：

Parallel GC 在纯吞吐场景下通常优于 G1。
大堆 + 大页（LargePages）减少 TLB miss。
如果批处理任务会频繁 Full GC，考虑分阶段释放引用或使用堆外缓存。

11.6 场景五：容器 / K8s 微服务

特征：资源受限、弹性伸缩、多实例共享节点。

目标：稳定、不 OOMKilled、启动快。

推荐配置：

java \
  -XX:+UseContainerSupport \
  -XX:InitialRAMPercentage=70.0 \
  -XX:MaxRAMPercentage=70.0 \
  -XX:MetaspaceSize=128m \
  -XX:MaxMetaspaceSize=256m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=50m \
  -jar service.jar

调优要点：

用 -XX:MaxRAMPercentage 替代固定 -Xmx，适配不同 Limit。
容器 memory limit 要预留 10%-20% 给堆外内存、Metaspace、线程栈、JVM 自身。
不要把 -Xmx 设成容器 limit 的 100%，否则容易被 OOMKilled。
JDK 23+ 在容器里可直接用默认分代 ZGC。

11.7 场景六：Spring Boot / 微服务网关

特征：启动时大量类加载、反射多、动态代理多。

目标：启动快 + 运行稳。

推荐配置：

java \
  -Xms2g -Xmx2g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=150 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Dspring.backgroundpreinitializer.ignore=true \
  -jar gateway.jar

调优要点：

Spring Boot 启动时 Metaspace 会快速上涨，初始值不要设太小。
如果启动慢，可用 -XX:+TieredCompilation 配合 -XX:TieredStopAtLevel=1 加速启动（牺牲峰值性能）。
网关避免在请求路径创建大对象，优先复用对象和缓冲区。

十二、一句话总结

内存：堆内分代、堆外 Direct、Metaspace 存类元数据；虚拟线程栈帧在堆中。
GC：Serial → Parallel → CMS → G1 → 分代 ZGC；JDK 21 分代 ZGC 正式发布，JDK 23 起成为默认 GC。
引用：强 > 软 > 弱 > 虚，缓存别滥用软引用。
性能：JDK 17-22 优先 G1；JDK 23+ 默认分代 ZGC；延迟极致用 ZGC，吞吐优先用 Parallel。
排查：监控先行 → 日志定位 → 工具分析 → 压测验证 → 持续观察。
场景：Web 服务控延迟、消息队列保吞吐、金融交易用 ZGC、批处理用 Parallel、容器环境留余量。

JVM 调优没有银弹，但有方法论：理解数据区 → 选对收集器 → 设定合理目标 → 用日志验证 → 持续监控。把这套流程跑熟，面试八股和线上救火就都不慌了。

参考

《深入理解 Java 虚拟机》（第三版）周志明
OpenJDK HotSpot Virtual Machine Garbage Collection Tuning Guide
JEP 333: ZGC
JEP 439: Generational ZGC
JEP 474: ZGC Generational Mode by Default
JEP 490: Remove the Non-Generational ZGC Mode
JEP 404: Generational Shenandoah (Experimental)
JEP 444: Virtual Threads
JEP 454: Foreign Function & Memory API
Project Lilliput

Java on 方糖猫Blog

C 端 IPTV 产品的 Java 高并发架构设计：高可用、高性能、零信任与缓存一致性

C 端 IPTV 产品的 Java 高并发架构设计：高可用、高性能、零信任与缓存一致性

一、先搞清楚对手：C 端 IPTV 的流量模型

二、总体架构：一张图看清全貌

三、高并发：把流量挡在离用户最近的地方

3.1 网关层：第一道削峰闸

3.2 热点接口：播放鉴权链接的缓存设计

3.3 多级缓存：L1 + L2

3.4 写路径异步化：MQ 削峰

四、高可用：假设一切依赖都会挂

4.1 熔断、降级与兜底重试

4.2 多租户隔离：分库就是隔舱

4.3 依赖解耦：订阅模式

4.4 混沌工程：轻量版就够

五、高性能：把钱花在读路径上

六、缓存一致性与缓存高可用

6.1 一致性策略：先写 DB，后删缓存

6.2 缓存三大经典问题的组合拳

6.3 缓存自身的高可用

七、零信任安全与必要防御

7.1 零信任：永不信任，始终验证

7.2 一次真实的安全整改：网盘密码泄露

7.3 接口消息体加密：HTTPS 之上的第二道锁

7.4 必要防御：防攻击清单

7.5 DRM：内容安全的最后一道门

八、可观测性：没有度量就没有高可用

九、总结：一张 checklist

我开发的keCache：面向 Spring Boot 3 的 L1 + L2 两级缓存框架

一、keCache 是什么

1.1 整体架构

二、开源地址

三、为什么需要 keCache？与纯 Redis / 纯 Caffeine 的对比

3.1 相比纯 Caffeine 的好处

3.2 相比纯 Redis 的好处

3.3 方案选型速查

3.4 一句话总结

四、核心能力速览

4.1 读取流程

4.2 写入与集群失效广播流程

五、快速开始

5.1 引入 Starter

5.2 启用缓存

5.3 基础配置

5.4 声明式使用示例

5.5 编程式使用

六、模块结构

七、关键约定（写代码前必读）

八、使用注意点与避坑指南

8.1 Redis 是硬性依赖

8.2 集群一致性是“最终一致”，不是实时一致

8.3 空值保护是把双刃剑

8.4 序列化类型变更要兼容

8.5 注意 Key 的命名空间隔离

8.6 @LocalCacheable.Multi 的 result 引用要判空

8.7 AOP 自调用不会生效

8.8 谨慎使用 @LocalCacheClear

8.9 校准任务不是开箱即用的

8.10 当前 Redis 部署模式限制

8.11 关注 Caffeine 内存与统计

九、许可证

十、总结

我开发的KE Reliable Executor：基于 Redis/MySQL 的 Spring Boot 可靠任务执行框架

我开发的KE Reliable Executor：基于 Redis/MySQL 的 Spring Boot 可靠任务执行框架

一、为什么需要这个工具？

适合什么场景？

不适合什么场景？

二、与竞品的对比

2.1 与 Kafka / RocketMQ 对比

2.2 与 Spring @Scheduled + 数据库轮询对比

2.3 与 XXL-JOB / PowerJob 对比

三、整体架构

3.1 模块解构图

3.2 两层锁模型

3.3 队列设计

3.4 任务状态机

四、核心设计要点

4.1 Lua 原子转移

4.2 Double-Check

4.3 双存储后端

8.6 `@LocalCacheable.Multi` 的 `result` 引用要判空

8.8 谨慎使用 `@LocalCacheClear`

2.2 与 Spring `@Scheduled` + 数据库轮询对比

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

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