追风笔记

Dubbo 总体架构与核心概念

Tue, 25 Aug 2026 00:00:00 +0000

Dubbo 的核心竞争力在于清晰的职责分层与高度可插拔的扩展机制。理解分层与 Invoker 抽象，是读懂 Dubbo 源码与排查线上问题的基础。

分层架构

Dubbo 自顶向下可分为若干逻辑层，每一层只依赖其下层的接口而非实现：

service / config 层：面向用户的 API 与配置层，@DubboService、@DubboReference 以及 ReferenceConfig、ServiceConfig 在此落地。
proxy 层：生成服务接口的动态代理，让远程调用对业务代码透明。
registry 层：封装服务注册与订阅，感知 provider/consumer 的上线下线。
cluster 层：将多个 Invoker 封装为「集群 Invoker」，负责负载均衡、容错与路由。
protocol 层：封装 RPC 调用，是 Invoker 暴露与引用的核心。
filter 链：贯穿调用的拦截器，可用于日志、鉴权、限流等横切逻辑。

Invoker 与 SPI

Invoker 是 Dubbo 的通用领域模型，代表「一个可执行且可描述的调用」，抽象了本地、远程、集群等不同类型的调用。URL 则作为贯穿各层的配置总线，几乎所有扩展点都通过 URL 传递参数。

Dubbo 的扩展机制基于改进版的 JDK SPI，通过 @SPI 注解声明扩展接口，@Adaptive 生成自适应实现，META-INF/dubbo/ 下以接口全限定名命名的文件登记实现类：

@SPI("dubbo")
public interface Protocol {
 @Adaptive
 <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;
 @Adaptive
 <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;
}

一次同步调用的链路

当 consumer 发起一次同步调用时，请求大致经历以下步骤：

Kafka 存储与消费模型

Tue, 25 Aug 2026 00:00:00 +0000

Kafka 的高性能依赖于「分区日志 + 顺序写 + 批量拉取」的设计。理解存储与消费模型，才能合理配置并行度与避免重复消费。

Topic 与 Partition

topic 是逻辑主题，partition 是物理并行单位，消息只追加写入分区末尾。
每个分区是一个有序、不可变的日志，由多个 segment 文件组成，并维护 offset（分区内唯一递增）。
分区数决定了消费的并行上限：一个分区同一时刻只被 group 内一个消费者消费。

Offset 与消费位移

消费者处理完消息后提交的位移称为 offset，Kafka 将其保存在内部 topic __consumer_offsets 中：

Producer -> [partition-0: 0,1,2,3 ...]
 ^
 | committed offset (group A)
Consumer group A 从 offset=4 继续拉取

位移提交方式影响可靠性：

自动提交：间隔提交，可能丢失（提交后未处理崩溃）或重复（处理中崩溃未提交）。
手动提交：处理成功后再提交，配合幂等可实现至少一次/精确一次。

Consumer Group 与 Rebalance

同一 group 内的消费者共同消费 topic 的全部分区，分区在成员间均衡分配。当成员加入/退出时触发 rebalance，重新分配分区。频繁 rebalance 会暂停消费，应控制 session.timeout 与 heartbeat.interval 并避免消费耗时过长。

MySQL 索引原理与最佳实践

Tue, 25 Aug 2026 00:00:00 +0000

索引是 MySQL 查询性能的决定性因素。理解 InnoDB 的 B+Tree 索引结构，才能写出真正命中索引的 SQL。

B+Tree 与聚簇索引

InnoDB 使用 B+Tree 组织索引，其特点是非叶子节点只存索引键用于导航，所有数据都落在叶子节点，且叶子节点通过双向链表串联，非常适合范围扫描。

InnoDB 的主键索引是聚簇索引，叶子节点直接存放整行数据；二级索引的叶子节点存放「索引键 + 主键值」。因此通过二级索引查询非索引列时，需要再用主键回表查聚簇索引。

回表与覆盖索引

当查询的列都在二级索引中时，无需回表，称为覆盖索引，性能更好：

-- idx_user_age 为 (name, age) 的联合索引
-- 仅取索引列，命中覆盖索引
SELECT name, age FROM user WHERE name = 'tom';

若 SELECT * 还需要 phone 等额外列，则会触发回表。高频查询应优先设计为覆盖索引。

最左前缀原则

联合索引 (a, b, c) 能生效的条件是查询从最左列开始连续匹配：

WHERE a = ? 可用
WHERE a = ? AND b = ? 可用
WHERE b = ? 无法使用该联合索引（断开了最左前缀）

避免索引失效

常见导致索引失效的写法：

Redis 数据结构与底层实现

Tue, 25 Aug 2026 00:00:00 +0000

Redis 对外暴露五种常用类型，但底层有多种编码（encoding）。根据数据规模自动在不同编码间转换，是它兼顾内存与性能的关键。

核心底层结构

SDS（简单动态字符串）：相比 C 字符串记录长度、预分配空间，避免缓冲区溢出并支持二进制安全。
ziplist / listpack：连续内存的紧凑列表，节省空间，适合小数据量。
linkedlist：双向链表，元素多时替代 ziplist。
dict（字典）：哈希表，使用链地址法解决冲突，渐进式 rehash 避免阻塞。
skiplist（跳表）：多层有序链表，结合 dict 实现 zset，范围查询高效。

各类型的编码与转换

类型	小数据编码	大数据编码	转换阈值（示意）
string	int / embstr	raw	长度 > 44 字节转 raw
hash	ziplist/listpack	hashtable	元素数或单个值超阈值
list	quicklist（ziplist 片段）	quicklist	—
set	intset	hashtable	含非整数或元素过多
zset	ziplist	skiplist+dict	元素数或值长度超阈值

以 zset 为例，小数据使用 ziplist 紧凑存储（member 与 score 相邻），当元素数量或单个 member 长度超过阈值时转为 skiplist + dict，保证有序遍历与按 member 查找都为 O(1)/O(log n)。

zset 小: [member1, score1, member2, score2, ...] (ziplist)
zset 大: dict(member->score) + skiplist(score->member)

理解这些阈值有助于解释「为什么小哈希比单独 key 省内存」，也提醒我们避免让单个 key 堆积过多元素，否则编码升级或操作耗时都会陡增。

ZooKeeper 数据模型与 ZAB 协议

Tue, 25 Aug 2026 00:00:00 +0000

ZooKeeper 的可靠性来源于其简洁的数据模型与强一致的 ZAB 协议。理解二者是正确使用 ZK 的前提。

数据模型 znode

ZK 维护一棵类似文件系统的层级树，每个节点称为 znode，可同时承载数据与子节点。其类型决定了生命周期与并发语义：

持久节点 / 临时节点：临时节点随 session 断开自动删除，是分布式锁、选主的基础。
普通节点 / 顺序节点：顺序节点创建时自动追加单调递增序号。
每个 znode 带有 version、cversion、aversion，修改时版本自增，提供乐观锁语义。

Session 与 Watcher

客户端与服务器建立 session，通过心跳保活，session 超时则服务器清理其临时节点。客户端可对节点注册 Watcher，节点发生变化（数据写、子节点变）时收到一次性通知，需重新注册才能继续监听。

ZAB 协议

ZAB（ZooKeeper Atomic Broadcast）是为 ZK 设计的崩溃恢复原子广播协议，保证所有事务以相同顺序被所有副本应用。

崩溃恢复与选主

集群启动时或 Leader 宕机进入恢复阶段：选举产生新 Leader，并让各 Follower 补齐到与 Leader 相同的状态。选主依赖 zxid（事务 id）与 myid，zxid 越大代表数据越新，优先当选。

消息广播

正常阶段采用类似 2PC 的广播：Leader 为每个写请求分配递增 zxid 并发起提议，Follower 写本地日志后 ACK，Leader 收到多数派 ACK 即提交并通知应用。

数据治理：从资产目录到口径统一

Sat, 08 Aug 2026 00:00:00 +0000

很多银行的数据治理项目，最后都沦为「补元数据、填责任表、交汇报 PPT」。运动一过，元数据过期、口径继续打架、下游照样不敢用这份数据。治理之所以失效，是因为它被当成了一份额外的「填表工作」，而不是数据生产流水线本身的属性。真正有效的治理，是让目录、血缘、口径和质量规则内建到系统里，而不是靠人肉维护。

治理为什么总做成运动

根本原因是把「治理」和「生产」割裂了。业务系统吐数据，治理团队在下游追着补标签、对口径。一旦人员变动或项目结项，治理成果立刻失真。

治理的目标不是「漂亮的报告」，而是让下游系统敢用这份数据。如果一份数据没人敢用来做决策，它就算被打了满分标签，也还是负债。

要扭转这个局面，得从三件最实在的事入手：盘清家底（资产目录）、追清来路（元数据血缘）、对齐说法（口径统一）。

资产目录：先盘清家底

资产目录回答的是「我们到底有哪些数据、归谁管、能不能用」。它不是 Excel 清单，而是带权属和分级的结构化注册表。

资产类型	例子	治理关注点
贴源表	核心系统流水	来源系统、更新频率
派生表	客户宽表	加工逻辑、依赖
指标	月活、不良率	口径定义、负责人
文件/接口	监管报送文件	敏感度、共享范围

目录必须和真实的元数据打通，否则就会出现「目录里说有、库里早就删了」的尴尬。一个可行的做法是：目录条目由采集任务自动生成，人工只补充业务语义，而不是反过来手工录入。

元数据与血缘：字段从哪来、到哪去

元数据解决「这个字段是什么」，血缘解决「它怎么变来的、又被谁用了」。两者合起来，才能做影响分析和溯源。

血缘怎么采

血缘最好自动采集，而不是靠文档口述。主流方式有两种：

静态解析：扫描 SQL、ETL 脚本、Spark/DAG 定义，提取表与字段级的输入输出关系。
运行时采集：在任务执行时记录实际读写的上下游，准确率最高但侵入性较强。

影响分析

有了血缘，一次核心系统字段口径变更，能立刻列出受影响的下游报表和指标。没有血缘，这类变更只能靠「老员工记忆」，风险极高。

血缘的价值不在炫技，而在于把「改一个字段要通知谁」从玄学变成可查询的图。它是治理能规模化的前提。

指标口径统一：最难的最后一公里

银行里「不良率」「活跃客户」「存款日均」这类指标，不同部门算出来常常不一样。根因不是谁算错，而是口径没有单一可信来源。

口径冲突的例子

「月活客户」可能被定义为：

渠道侧：当月登录 App 即算活跃；
零售侧：当月有动账交易才算活跃；
监管侧：按监管文件口径，且需去重。

三个数字放在一起对比，结论自然矛盾。更糟的是，没人说得清哪个是「官方版本」。

指标字典与单一来源

解决思路是建立指标字典：每个指标一条定义，包含口径 SQL、维度、过滤条件、负责人和生效时间。下游统一从字典取数，禁止各自重写逻辑。

-- 指标字典中「存款日均」的口径定义（单一来源）
SELECT cust_id,
 SUM(balance) / COUNT(DISTINCT cal_date) AS avg_daily_balance
FROM dwd_account_daily
WHERE cal_date BETWEEN :start AND :end
 AND balance_type = 'SAVING'
GROUP BY cust_id;

口径变更要走版本管理，旧口径保留可追溯，新口径标注生效日，避免历史报表被悄悄改义。

聚合根与领域事件：DDD 战术建模

Sun, 15 Mar 2026 00:00:00 +0000

银行核心系统里最容易被低估的概念，是「聚合」。很多人把 DDD 战术设计理解成「给实体加几个注解」，结果聚合越写越大，事务越来越长，最后把数据库和团队都拖垮。本文把聚合根和领域事件放回它们本来的位置：一致性边界的设计工具，以及领域向外界发声的窗口。

为什么需要聚合

领域模型不是一张 ER 图。ER 图关心「数据怎么存」，聚合关心「哪些数据必须在同一个事务里保持一致」。这两件事经常错位，而错位的代价在金融场景里格外昂贵——账务不平、状态错乱，往往不是因为算法错，而是因为一致性边界划错了。

一致性边界

聚合的第一性原理是：在边界之内，用强一致性保证业务规则不被破坏；在边界之外，用最终一致性传递变化。一个账户余额不能为负，这条规则必须在一个事务内被满足，所以它属于聚合内部。而「账户余额变动后通知风控」，则属于边界之外，交给领域事件。

经验法则：如果两条业务规则必须同时为真，它们大概率属于同一个聚合；如果可以接受短暂的不一致，它们就分属不同聚合。

聚合不是「大对象」

最常见的反模式，是把「客户」做成包含地址、联系人、合同、账户、画像的超级对象。它在概念上很完整，但在工程上是个灾难：每次改一个手机号，都要加载半个数据库，还要锁住一堆根本无关的数据。

聚合的边界应以事务一致性而非业务概念大小来划。概念上属于「同一个东西」的数据，未必需要在同一个事务里。

聚合根的设计原则

聚合根是聚合对外的唯一入口。外部只能持有聚合根的引用，不能直接操作聚合内部的实体或值对象。

引用靠 ID，不靠对象

跨聚合的关联，永远用标识符，而不是对象引用。聚合 A 不应直接持有聚合 B 的对象，否则两个聚合会被悄悄绑进同一事务。

public class Account {
 private final AccountId id; // 聚合根标识
 private final CustomerId ownerId; // 跨聚合引用：只存 ID
 private final Money balance;
 private final List<DomainEvent> pendingEvents = new ArrayList<>();

 public void withdraw(Money amount) {
 if (balance.isLessThan(amount)) {
 throw new InsufficientBalanceException(id);
 }
 balance = balance.subtract(amount);
 pendingEvents.add(new MoneyWithdrawn(id, amount, now()));
 }

 public List<DomainEvent> drainEvents() {
 var copy = new ArrayList<>(pendingEvents);
 pendingEvents.clear();
 return copy;
 }
}

工厂与仓储

复杂聚合的创建交给工厂，避免调用方掌握内部构造细节；聚合的持久化交给仓储，且仓储只按聚合根 ID 加载整个聚合，不存在「只查一半」的仓储方法。

支付清算全流程拆解

Tue, 10 Feb 2026 00:00:00 +0000

普通人眼里的「转账」是一个瞬间动作：输金额、点确认、余额变了。但背后的资金流动要经过支付、清分、结算三个阶段，跨过多个系统，才可能真正「钱到了」。理解这套链路，是做银行支付系统的前提，也是排查「钱怎么少了」「为什么还没到账」的地图。

一笔转账背后发生了什么

当你在 App 上给朋友转 1000 元，这笔指令从你的银行出发，要穿越自己的核心系统、跨行清算通道、对方银行的核心系统，最后落到对方账户。中间任何一环的状态错位，都会让这笔钱「卡在半路」。所以支付系统设计的第一个原则，是把每个阶段的状态显式建模，而不是用一个「已转账」含糊带过。

支付系统最危险的 bug，不是算错金额，而是状态机说不清一笔钱现在到底在哪：是已扣、已发、已清算、已结算，还是已退回。

三个阶段：支付、清分、结算

这是整条链路的主干，三者的边界必须划清。

支付：机构内部的记账

付款方银行收到指令后，先校验账户状态、余额、限额、风控，然后在自己的核心账本上记一笔「待清算」的借贷。这一步完全发生在单个机构内部，还没有任何人把钱真正挪动。

清分：轧差与净额

清分是交易双方机构把彼此的借贷指令汇总、计算净额的过程。它有两种模式：

全额清分：每一笔借贷都单独计算，资金流与业务流一一对应，安全但占用流动性。
净额清分（轧差）：把一段时间内的多笔借贷相互抵扣，只交差额。比如 A 欠 B 100 万、B 欠 A 80 万，净额就是 A 再付 B 20 万。

结算：资金的真实位移

结算是资金在央行或清算机构的账户上真正转移，借贷最终平衡。只有结算完成，这笔钱才算「落地」。在此之前，它只是账面上的债权。

阶段	发生位置	是否动真实资金	关键产物
支付	付款方银行内部	否（仅记账）	支付流水、待清算挂账
清分	清算机构/双方对账	否（算差额）	净额头寸、清分文件
结算	央行/清算账户	是	准备金账户余额变动

清分算的是「谁欠谁多少」，结算做的是「把钱真正挪过去」。只清不分或只分不结，都会让账面悬空。

大小额与网银清算系统

中国人民银行的大小额支付系统，是跨行资金流动的主动脉。不同系统对应不同的金额、时效与成本取舍。

系统	处理方式	金额与时效	适用场景
大额支付系统（HVPS）	逐笔实时全额	大额、实时、营业时间	对公大额、同业头寸调拨
小额支付系统（BEPS）	批量净额轧差	小额、定时撮合	日常零售、代收付
网上支付跨行清算	逐笔/批量	7x24、准实时	网银、手机银行跨行

大额走全额是为了安全和实时，小额走净额是为了降低流动性占用和通道成本。设计路由时，按金额和时效要求分流，而不是一刀切全走大额。

PageFly

Mon, 01 Jan 0001 00:00:00 +0000

项目主页见上方卡片链接，点击直接跳转至 https://fly.882680.xyz。

Kafka 可靠性与精确一次

Tue, 25 Aug 2026 00:00:00 +0000

Kafka 的可靠性需要在 producer、broker、consumer 三端协同配置。下面从「不丢、不重、有序」三个目标展开。

Producer 端的可靠性

通过 acks 控制写入持久化级别：

acks=0：发完即认为成功，可能丢消息，吞吐最高。
acks=1：leader 写入即成功，leader 宕机可能丢。
acks=all：ISR 全部同步才成功，最安全，配合 min.insync.replicas 防单点。

开启重试（retries）可应对瞬时失败，但会带来重复：网络抖动导致 producer 未收到 ack 而重试，同一条消息被写两次。

幂等 Producer 与事务

Kafka 提供 幂等 producer（enable.idempotence=true），broker 用 producerId + 序列号 去重，保证单分区内不重不漏。需要跨分区、跨系统的原子写入时，使用事务（transactional.id）将多次 produce 与 offset 提交纳入一个事务：

producer.initTransactions();
producer.beginTransaction();
producer.send(record1);
producer.send(record2);
producer.commitTransaction(); // 要么都成功，要么都不可见

消费端去重与幂等

即使 producer 幂等，consumer 在 rebalance 或位移提交时机不当时仍可能重复消费。消费端应保证业务幂等：

用唯一键（订单号等）做去重表/唯一索引。
将「处理 + 提交位移」放在同一事务（如消费写 DB 同时记录 offset）。

分区顺序性

Kafka 只保证单分区内有序。需要全局顺序只能单分区（牺牲并行）；需要业务顺序则按 key（如用户 id）分区，使同一 key 落到同一分区，从而在该 key 维度保持顺序。精确一次（EOS）正是幂等 + 事务 + 消费幂等三者叠加的结果。

MySQL 事务与锁机制

Tue, 25 Aug 2026 00:00:00 +0000

并发场景下，事务与锁共同保证了数据的一致性。InnoDB 通过 MVCC 与锁的协同，在性能与隔离性之间取得平衡。

ACID 与隔离级别

事务的 ACID 由不同机制保障：原子性靠 undo log，持久性靠 redo log，隔离性靠 MVCC 与锁，一致性是最终目标。

SQL 标准定义四种隔离级别，InnoDB 默认 REPEATABLE READ：

READ UNCOMMITTED：可能脏读
READ COMMITTED：避免脏读，可能不可重复读
REPEATABLE READ：避免不可重复读（InnoDB 额外避免幻读）
SERIALIZABLE：完全串行，性能最低

MVCC 与日志

MVCC（多版本并发控制）让读不加锁、读写不阻塞。每行记录隐含 trx_id 与 roll_pointer，通过 undo log 构建历史版本，配合 ReadView 判断某版本对当前事务是否可见。

undo log：记录数据修改前的镜像，用于回滚与构建旧版本。
redo log：记录物理页修改，保证崩溃后已提交事务不丢失（WAL 机制）。

行锁、间隙锁与 Next-Key Lock

InnoDB 默认使用行锁，但「锁的是索引记录」而非行本身。在 REPEATABLE READ 下，为解决幻读引入：

行锁（Record Lock）：锁住具体索引记录。
间隙锁（Gap Lock）：锁住索引记录之间的间隙，阻止插入。
Next-Key Lock：行锁 + 间隙锁，锁定左开右闭的区间。

-- 在 (10, 20] 区间加 Next-Key Lock，阻止其他事务插入 id=15
SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE;

死锁成因与排查

死锁通常由两个事务以相反顺序获取锁引起。排查手段：

Redis 缓存设计

Tue, 25 Aug 2026 00:00:00 +0000

引入缓存能显著降低数据库压力，但设计不当会引入穿透、击穿、雪崩等经典问题。下面逐一拆解成因与对策。

三大经典问题

缓存穿透：查询不存在的数据，缓存与数据库都查不到，请求每次都打到 DB。应对：缓存空值（短过期）、布隆过滤器拦截非法 key。
缓存击穿：某个热点 key 过期瞬间，大量并发同时回源 DB。应对：互斥锁（只放一个线程重建）、逻辑过期（异步刷新）、热点 key 不过期。
缓存雪崩：大量 key 同一时刻集中失效，或 Redis 整体不可用，DB 被冲垮。应对：过期时间加随机抖动、多级缓存、Redis 高可用（哨兵/集群）。

Cache-Aside 与一致性

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

读: 先读缓存 -> 命中返回; 未命中读 DB -> 写入缓存
写: 先更新 DB -> 再删除缓存 (而非更新缓存)

「先更新 DB 再删缓存」可降低并发下读到旧值的概率；极端不一致可通过延迟双删或订阅 binlog（如 Canal）补偿。注意：不要盲目「更新缓存」，否则并发写可能产生脏数据。

大 key 与热 key

大 key：如包含百万元素的 hash/list，删除或序列化会阻塞主线程。应对：拆分、分批删除（unlink）、定期清理。
热 key：单个 key 访问极高，单节点成为瓶颈。应对：本地缓存副本、key 打散到多个副本、Redis 集群分片。

过期与淘汰策略

Redis 提供主动 + 惰性两种过期删除，内存不足时按 maxmemory-policy 淘汰：

ZooKeeper 分布式协调实战

Tue, 25 Aug 2026 00:00:00 +0000

ZooKeeper 提供原语级的协调能力，几乎所有分布式协调需求都可基于「临时节点 + 顺序节点 + Watcher」组合实现。

选主（Master Election）

每个候选者在 /election 下创建临时顺序节点，序号最小的即成为 Master。非最小节点监听其前一个节点，前驱消失时重新判断自己是否最小，从而实现故障自动转移：

/election
 ├── /n_0000000001 (master)
 ├── /n_0000000002 (watch 001)
 └── /n_0000000003 (watch 002)

配置中心

将配置写入持久节点，客户端读取并注册 Watcher，配置变更时收到通知后热更新，无需重启应用。注意配置节点应控制体积，避免单次推送过大。

分布式锁

基于「临时顺序节点 + 监听前驱」实现公平排他锁，比简单 create 抢锁更健壮、可避免惊群。

羊群效应（Herd Effect）

若所有客户端都监听同一个锁节点，释放时会被同时唤醒并争抢，产生大量无效请求。正确做法是只监听比自己序号小的前一个节点，形成链式唤醒，将 O(N) 通知降为 O(1)。

临时节点的坑

客户端 GC 停顿或网络抖动可能导致 session 超时，临时节点被误删而锁提前释放。需结合合理的 sessionTimeout 与心跳。
持锁方崩溃后锁自动释放，但业务未提交，需保证操作幂等。

与 etcd 的取舍

etcd 基于 Raft，提供更强一致与租约（lease）、Watch 增量推送，API 更简单，云原生场景（Kubernetes）更主流；ZK 生态成熟、客户端丰富，但在超大规模 Watch 下存在性能瓶颈。新项目可优先考虑 etcd，存量 Dubbo/Hadoop 体系仍常用 ZK。

服务注册与发现实战

Tue, 25 Aug 2026 00:00:00 +0000

服务注册与发现是微服务架构的基石。Dubbo 将注册中心抽象为 Registry 接口，因此可以在 ZooKeeper、Nacos、Consul 等实现之间平滑切换，业务代码无需改动。

注册中心接入

以 Nacos 为例，只需在配置中声明注册中心地址与协议即可。Dubbo 在启动时自动完成服务导出（export）与订阅（subscribe）：

dubbo:
 application:
 name: order-service
 registry:
 address: nacos://127.0.0.1:8848
 protocol:
 name: dubbo
 port: 20880

Provider 启动后会在注册中心写入自身元数据（接口、IP、端口、权重等）；Consumer 启动后订阅接口节点，拿到可用 Provider 列表并缓存到本地，后续调用直接走本地缓存，降低注册中心压力。

健康检查与上下线

注册中心侧健康：基于临时节点（ZooKeeper）或心跳（Nacos）感知进程存活，进程宕机时节点被摘除，Consumer 收到 unregister 通知后剔除实例。
应用侧优雅下线：收到 SIGTERM 时先取消注册、拒绝新请求、等待在途请求处理完毕再退出，避免调用方打到已下线的实例。

不停机发布

滚动发布时常见问题是「刚下线就又有流量」。推荐组合拳：

下线前通过注册中心将实例权重置 0，使其不再接收新流量。
等待预热期与在途请求排空（如 10s）。
再执行实际进程关闭。

配合 Consumer 端的失败重试与 Cluster 容错（如 Failover），可基本实现调用方无感知的版本迭代。需要注意：注册中心通知存在网络延迟，Consumer 本地缓存与重试机制是兜底关键。

计息与限额：算得清才能管得住

Mon, 22 Jun 2026 00:00:00 +0000

银行系统里最容易「看起来很简单、做起来全是坑」的两件事：计息和限额。它们一个决定「钱怎么生钱」，一个决定「钱不能出什么事」。两者共同的特点是：规则必须可被验证，结果必须可被复核。

计息：口径比公式重要

公式 本金 × 利率 × 天数 / 基数 人人会写，难的是口径统一。

计息基数：是每日余额、还是日均余额？贷款多用实际天数，存款各有约定。
闰年与节假日：一年按 365 还是 360？结息日遇节假日顺延还是提前？
利率变动：固定利率、浮动利率重定价日如何衔接，分段计息怎么切。

BigDecimal interest = dailyBalance
 .multiply(rate)
 .multiply(BigDecimal.valueOf(days))
 .divide(BigDecimal.valueOf(360), 6, RoundingMode.HALF_UP);

计息 bug 最可怕的结局，不是算错一笔，而是「每天错一点点，半年后对不上，却找不到从哪天开始错」。所以计息必须有可复现的逐日明细。

限额：控制点要前置

限额分好几类：单笔、日累计、月累计、余额上限、渠道限额。关键不在「存一个上限数字」，而在控制点必须前置到交易校验环节，而不是事后统计。

限额类型	控制点	典型场景
单笔限额	交易发起前	防单笔大额盗刷
日累计	交易前累计判断	渠道风控
余额上限	入账后校验	产品合规约束

限额规则要可配置，且变更留痕、可追溯生效时间。
累计类限额必须考虑并发：用原子计数或数据库约束，别靠「先查后扣」。
超限处理要明确：拒绝、转人工、还是降级，不能悄悄放行。

if (dailyUsed.add(amount).compareTo(dayLimit) > 0) {
 throw new LimitExceededException(cardNo, dailyUsed, dayLimit);
}

限额系统宁可「误杀一笔正常交易」，也不能「放过一笔该拦的」。前者是体验问题，后者是风险事件。

CQRS 与 Saga：复杂业务的读写分离与最终一致

Mon, 20 Apr 2026 00:00:00 +0000

很多团队把 CQRS 当成「加个 MQ 同步数据」就完事，结果读模型对了、写模型乱了，长事务更无从下手。CQRS 解决「读写诉求不同」，Saga 解决「业务跨多个聚合却不能开大事务」，两者常一起出现但职责不同。

读写为什么要分家

写模型关心一致性与不变量，是一组小而强的聚合；读模型关心展示与组装，最好能直接查出前端要的 DTO。诉求冲突时强行共用一个模型，两边都不讨好。

account.withdraw(money); // 写侧：只做业务
repository.save(account);
findByCardNo(cardNo); // 读侧：直接投影，无需聚合

不要为了 CQRS 而 CQRS。单表就能满足读写、流量不大的模块，分家只会制造延迟和负担。

Saga 管理长事务

转账、跨境汇款天然跨账户跨系统，不可能用本地事务锁住。Saga 把大事务拆成一串本地事务，每步都有补偿。

模式	思路	适用
编排	中心协调器逐步调用并补偿	需强管控
协同	各服务靠事件触发	去中心低耦合

补偿与幂等

Saga 最怕「补偿自己也失败」，所以每步都要幂等：用业务流水号去重，重试不重复扣款。每步记录状态机 PENDING -> DONE / COMPENSATED，补偿顺序与正向相反，对账做兜底而非第一道防线。

最终一致不是「不管了」，而是把一致性从「即时」换成「可验证」：允许短暂中间态，但必须能收敛到正确态。

落地上，CQRS 让读写各取所需，Saga 让长流程可回退，再加独立对账，复杂业务才算立得住。

消息队列选型：Kafka vs Pulsar vs RabbitMQ

Sat, 28 Feb 2026 00:00:00 +0000

消息队列是分布式系统的神经系统，但 Kafka、Pulsar、RabbitMQ 三者的设计哲学差异极大。选错不是「换个客户端」的事，而是架构重做。下面从几个工程最关心的维度拆开看。

模型差异是根本

RabbitMQ：经典消息代理，面向「消息」和「队列」，支持丰富路由（直连、主题、头部、扇出）。适合任务分发、低延迟小消息。
Kafka：日志型、分区有序、拉取消费，面向「流」和「事件溯源」。适合高吞吐、可重放。
Pulsar：计算存储分离，分层架构，原生多租户和跨地域复制。适合既要 Kafka 的流、又要 RabbitMQ 的队列语义的统一平台。

# Kafka 顺序消费依赖分区
bin/kafka-console-consumer.sh \
 --topic orders --bootstrap-server b1:9092 \
 --partition 0 --offset earliest

关键维度对比

维度	Kafka	Pulsar	RabbitMQ
吞吐	极高	极高	中等
消息模型	流/日志	流+队列	队列
顺序性	分区内有序	分区/Key 有序	队列有序
运维复杂度	中	高（含 BookKeeper）	低
消费模型	拉取、可重放	拉取、可重放	推送

选型思路

事件流、日志、可重放 → Kafka 稳。审计、CDC、行为埋点这类场景它的重放能力几乎是刚需。
统一消息平台、多租户、跨地域 → Pulsar 更合适，但团队要扛得住运维。
任务队列、复杂路由、低延迟 → RabbitMQ 更直接。

// 用消息头做复杂路由（RabbitMQ 风格）
channel.basicPublish("orders.topic",
 "order.created.vip", // routingKey
 props, body);

别用 RabbitMQ 扛日均百亿事件流，也别用 Kafka 做需要复杂路由的任务分发——用对的工具，比用最强的工具重要。

投资顾问系统

Mon, 01 Jan 0001 00:00:00 +0000

项目主页见上方卡片链接。

AML/KYC：合规不是绊脚石

Tue, 14 Jul 2026 00:00:00 +0000

一提 AML/KYC，业务侧往往皱眉：开户变慢、交易被拦。但合规不是外挂的「麻烦」，而是银行必须内建的能力。把它当系统一等公民来设计，风控和体验才能双赢。

KYC：先搞清楚你是谁

KYC 是起点，不是收集证件复印件，而是建立持续可验证的客户画像。

身份核验：证件真实性、活体、工商比对。
风险分级：按行业、地域、业务性质定级。
受益所有人：穿透到最终自然人，防借壳。

customer_risk:
 level: high
 factors: [virtual_asset, high_risk_region, pep: true]

AML：盯着钱往哪走

反洗钱看交易行为与资金路径，而非单次金额大小：名单监控、交易监测（规则+模型打分）、可疑报告（STR）走调查上报流程。

维度	信号	处置
频率	短期多笔等额进出	触发复核
对手方	命中制裁名单	阻断上报
金额	拆分规避限额	合并评估

真正的反洗钱是「识别不合理模式」：规整发工资的小额账户突然集中收款，比一笔大额更可疑。

工程落地要点

名单更新要准实时且对存量重跑；规则先求可解释、可回测；误报率持续度量；告警工单化、可审计。合规做扎实，业务国际化反而少踩坑。

六边形架构在银行核心系统的落地

Mon, 18 May 2026 00:00:00 +0000

银行核心最痛的不是业务复杂，而是业务逻辑和周边技术死死绑在一起：换连接池要改核心，接新渠道要动账务，单测要起一整套中间件。六边形架构（Ports & Adapters）给出干净解法。

核心、端口与适配器

领域核心：纯业务规则，不依赖任何框架、数据库或 HTTP 客户端。
端口：核心暴露（入站）和需要（出站）的接口，用 Java 接口表达意图。
适配器：把端口接到具体技术——REST 控制器是入站适配器，JDBC 仓储是出站适配器。

public interface AccountRepository { // 端口：只定义要什么
 Account load(AccountId id);
 void save(Account account);
}
public class JdbcAccountRepository implements AccountRepository { /* 技术留在外围 */ }

判断架构是否干净的一条硬标准：删掉数据库、MQ、Web 框架，核心业务代码还能原封不动地跑并被测。

在银行核心里怎么切

核心账务、计息、限额放在中心；大小额网关、CBS 接口、短信、风控回调全做成外围适配器。监管规则变了只动核心，接新清算通道只加一个适配器。

层次	内容	依赖框架
领域核心	账务、计息、限额	否
应用层	用例编排	否
适配层	REST/JDBC/MQ	是

收益与代价

收益是可单测、可独立部署、渠道可替换；代价是初期抽象成本与团队纪律。在银行这种长生命周期系统里，核心被技术债锁死的代价远高于前期投入。

架构不是墙上的图，而是写在依赖箭头里的纪律。六边形的价值，是让「技术变了业务不动」成为默认结果。

分库分表策略与热点治理

Mon, 30 Mar 2026 00:00:00 +0000

当单表涨到几亿行、单库连接打满，分库分表就从「可选项」变成「生存项」。但分片一旦定错键，后期重构的代价接近重写。所以策略要在一开始就想清楚。

分片键是第一步，也是最重要的一步

分片键决定数据怎么散、请求怎么走。选错键，要么数据倾斜，要么跨分片查询泛滥。

选高频等值查询字段：比如账户号、客户号，保证大多数请求落单分片。
避免低基数或单调递增：性别这种分片键会制造大分片；自增 ID 做键会集中在最新分片，形成写入热点。
兼顾关联查询：同一客户的账户、交易最好同片，减少跨片 JOIN。

-- 按客户号哈希分 1024 片
SELECT * FROM trans_${hash(cust_id)%1024}
WHERE cust_id = ? AND trans_date >= ?;

扩容：预分片优于临时拆

一开始就按「未来三年规模」定足够多的逻辑分片（如 1024、4096），物理上先少后多。扩容只是把逻辑分片映射到新物理库，数据迁移量远小于重新分片。

策略	优点	缺点
预分片	扩容平滑	初期略冗余
范围分片	易理解	易热点
哈希分片	均衡	范围查询跨片

// 逻辑分片到物理库的映射可配置
String logic = "trans_" + (hash(custId) % 1024);
String phys = routeTable.lookup(logic); // 映射到具体物理库

热点治理

即使哈希均匀，业务上仍会有「明星账户」「大商户」成为单点热点。

认知匹配 / AI 认知画像

Mon, 01 Jan 0001 00:00:00 +0000

项目主页见上方卡片链接。

中文 AI 人味化 skill

Mon, 01 Jan 0001 00:00:00 +0000

项目主页见上方卡片链接。

银行核心系统建模随笔

Sun, 02 Aug 2026 00:00:00 +0000

核心系统的模型看起来很朴素：账户、余额、交易、分录。真正做进去才发现，每一个概念背后都有一堆不能妥协的约束，而这些约束在需求文档里往往一个字都没写。这篇是零散的建模笔记，按我认为重要性排的顺序。

核心系统到底在建模什么

先把定位说清楚。核心系统建模的对象不是"业务流程"，而是会计事实。

客户在手机上点一下转账，这是渠道行为；反洗钱要不要拦、限额够不够，这是风控与协议判断；而核心真正负责的只有一件事：在正确的会计日，把一组借贷平衡的分录准确地记下来，并保证余额永远等于分录累计的结果。

想清楚这一点，很多设计争论会自动消失。比如"转账的营销活动规则要不要放核心"——不放，那不是会计事实。核心的表越少越好，能力越单一越好。

判断一个需求该不该进核心，只问一句：它会改变账务事实吗？不会，就放外围。核心系统膨胀的过程，就是这条边界一次次让步的过程。

账户模型：一棵不能长歪的树

账户号不是主键

这是我见过最多的建模错误。账号是业务标识，有格式规则、会变更、会重开、可能因迁移换号段。用它做物理主键，等到某天要做账号升位或者跨行并库，整个系统的外键关系会一起爆炸。

正确做法是内部 ID 与业务账号分离：

public class Account {
 private final AccountId id; // 内部标识，永不变更，不对外暴露
 private AccountNo accountNo; // 业务账号，可变更，对外展示
 private final CustomerId owner;
 private final ProductCode product;
 private final Currency currency;
 private AccountStatus status;
 private final LocalDate openDate;

 /** 账号变更保留历史，因为凭证和流水引用的是历史账号 */
 public void changeAccountNo(AccountNo newNo, String reason) {
 if (status != AccountStatus.ACTIVE) {
 throw new DomainException("非正常状态账户不允许换号");
 }
 registerEvent(new AccountNoChanged(id, accountNo, newNo, reason));
 this.accountNo = newNo;
 }
}

AccountNoChanged 事件必须落库。半年后有人拿旧账号来查流水，你要能翻译过去。

缓存设计的那些坑

Wed, 08 Jul 2026 00:00:00 +0000

缓存是最容易加的优化，也是最容易埋雷的优化。加的时候只要几行代码，出问题时往往是深夜的数据不一致或者数据库被打穿。

一致性：先更库还是先删缓存

这个问题的正确答案是先更新数据库，再删除缓存（Cache Aside）。但要理解它为什么仍然不完美。

先删缓存再更库的问题很直接：删完缓存到更库完成之间，另一个请求读到旧数据并把它写回缓存，之后缓存里就一直是脏数据。

先更库再删缓存也有极小概率出问题：读请求恰好在缓存失效后读到旧库值，且回写发生在删除动作之后。概率很低，但在高并发下不等于零。

@Transactional
public void updateLimit(String accountNo, Money newLimit) {
 limitRepository.update(accountNo, newLimit); // 1. 先落库
 // 2. 事务提交后再删缓存，避免删除后事务回滚导致缓存空档
 TransactionSynchronizationManager.registerSynchronization(
 new TransactionSynchronization() {
 @Override public void afterCommit() {
 cache.delete(limitKey(accountNo));
 }
 });
}

afterCommit 这一步很关键。在事务内删缓存，如果事务随后回滚，缓存已经被清掉，下一次读会把旧值再加载回来——看起来是对的，但实际上你丢失了一次删除的语义保证。

更重要的判断是：这个数据到底能不能容忍短暂不一致。限额、开关、风控规则这类直接影响资金准入的配置，我们干脆不缓存或者只做几秒的本地缓存，宁可多查一次库。

三大经典故障

穿透：查一个根本不存在的 key，每次都落库。恶意刷不存在的账号就是这么打穿数据库的。做法是缓存空值并设短过期（比如 60 秒），或者前置布隆过滤器。
击穿：热点 key 过期瞬间大量请求同时落库。做法是加互斥锁，只让一个线程去加载，其余等待或返回旧值。
雪崩：大批 key 同时过期，或者 Redis 整体不可用。前者靠给过期时间加随机抖动解决；后者必须有降级预案——限流加返回兜底数据，不能让流量全量透传到数据库。

// 过期时间加抖动，避免批量同时失效
private Duration ttlWithJitter(Duration base) {
 long jitter = ThreadLocalRandom.current()
 .nextLong(base.toSeconds() / 10 + 1); // 上下浮动约 10%
 return base.plusSeconds(jitter);
}

热 key 与大 key

这两个是运维阶段最常见的问题，开发时基本不会注意到。

银行业本体论

Mon, 01 Jan 0001 00:00:00 +0000

项目主页见上方卡片链接。

分库分表不是银弹

Mon, 15 Jun 2026 00:00:00 +0000

分库分表在很多团队是一种默认操作：数据量一大就分。但它换来的收益很窄，付出的代价很宽，而且代价大多在上线半年后才开始显现。

先问要不要分

分库分表真正解决的问题只有两个：单表数据量导致的索引效率下降，以及单库写入的 IOPS 瓶颈。除此之外的问题它都解决不了，甚至会恶化。

在决定分之前，这几件事的性价比更高：

加索引或改查询。慢查询里相当大一部分是索引缺失或者写法导致索引失效，跟数据量无关。
冷热分离。交易流水表里九成查询集中在最近三个月。把历史数据归档到历史库，主表立刻瘦身，成本远低于分表。
读写分离。读多写少的场景加从库就够了。
升配。听起来不体面，但一台高配实例能撑到的量往往超出预期，而且省下的是人力。

我的经验阈值：单表超过两千万行且增长稳定、或者写入已经打满 IO，才考虑分表。仅仅因为"数据量看着挺大"就分，是给自己找活干。

分片键决定生死

分片键选错基本没法补救——除非停机重新迁移全量数据。

选择原则是让高频查询都能带上分片键。交易流水表用账号分片，那么"查某账号最近流水"就是单分片查询，性能很好；但"查某商户当天全部流水"就变成了全分片扫描加内存聚合。

-- 单分片，走得很好
SELECT * FROM txn_flow
 WHERE account_no = '6222...1234'
 AND txn_date >= '2026-06-01'
 ORDER BY txn_date DESC LIMIT 20;

-- 跨全部分片，聚合在应用层做，分片多了就是灾难
SELECT merchant_no, SUM(amount) FROM txn_flow
 WHERE txn_date = '2026-06-14'
 GROUP BY merchant_no;

第二类需求不要靠分片库硬扛，应该走另一条路：同步一份到 OLAP 引擎或数仓。一份数据满足所有查询模式的想法本身就是问题的根源。

另外一定要一次性把逻辑分片数定足。我们定了 1024 个逻辑分片映射到 8 个物理库，扩容时只搬分片区间，不用重新哈希。如果直接按物理库取模，第一次扩容就要迁移全量数据。

我的 AI 工作流：从 Cubox 到 Claude

Sun, 24 May 2026 00:00:00 +0000

试过很多工具组合，绝大多数最后都废了。留下来的这套很简单，只有三个环节：收口、加工、归档。工具会换，环节不会。

输入：Cubox 负责收口

信息源太散是最大的问题——微信文章、技术博客、内部文档、群里的链接。以前我在不同地方存不同来源，结果就是想找时哪儿都找不到。

现在的规则只有一条：所有想读的东西只进一个入口。Cubox 的价值不在功能多，而在它在手机、浏览器、微信里都能一键收藏。

我只用三个标签维度：

状态：待读 / 已读待整理 / 已沉淀
主题：架构 / 银行业务 / AI / 其他
强度：需要精读 / 扫一遍就行

标签体系越简单越可能被坚持。我曾经设过十几个分类，两周后就懒得选了。

收藏不等于阅读，阅读不等于沉淀。我给自己定的比例是每收藏十篇，至少有一篇要走完到沉淀环节。剩下九篇没读完也不内疚——收口的意义就是让它们不再占用注意力。

加工：Claude 负责结构化

这一环是变化最大的。以前读完一篇长文要自己做摘要，成本高到经常跳过。现在的做法是把原文丢给 Claude，用固定的提示词做第一轮结构化：

请阅读以下技术文章，按此结构输出：

1. 核心论点（不超过三句）
2. 作者的关键假设与适用前提
3. 论证中的证据类型（生产数据 / 基准测试 / 个人经验 / 无证据）
4. 与我已有认知可能冲突的点
5. 值得进一步查证的三个问题

要求：不要复述细节，不要评价文笔。若某项在原文中缺失，直接写"原文未提供"。

第 3 项和第 5 项是我加上去之后价值最大的两条。技术文章里很多结论是没有证据的个人经验，明确标出来能避免我把别人的经验当事实用。

对于代码类的材料，我会让它先跑一遍可行性判断，而不是直接接受：

# 让 Claude Code 直接在本地验证文章里的写法能不能跑通
cbc -p "读取 notes/inbox/kafka-idempotent.md 里的示例代码，
在 sandbox/ 下建最小可运行工程验证结论是否成立，
把不成立的地方列出来并说明原因"

能跑通的写法才进笔记，跑不通的记录成"待查证"。这一步过滤掉了不少看起来很对的博客结论。

备考系统架构设计师：我的学习路径

Wed, 06 May 2026 00:00:00 +0000

考这个证的动机说实话不纯粹：一部分是行内职级评定需要，一部分是想系统补一遍自己知识体系里的窟窿。考完回头看，第二个收获比第一个大。

考什么

三门，一天考完，全部及格才算通过：

综合知识（选择题）：覆盖面极广，操作系统、数据库、网络、软件工程、法律法规、数学与经济管理都有。深度不大但广度惊人。
案例分析（简答）：给一段项目背景，回答架构决策类问题。质量属性、架构风格、缓存与数据库设计是高频考点。
论文：从四个题目里选一个，两千五百字左右，要求结合真实项目。

三门里论文的通过率最低，也是唯一没法靠刷题突破的一门。

我的时间分配

总共投入大约四个月，每天一到两小时，周末多一点。分配比例大致是：

综合知识 30%。这门的正确策略是刷题而不是读教材。教材几百页，考点分布极散，直接刷历年真题，错题回教材定位。
案例分析 30%。真题必须动手写，不能只在脑子里过。写完对照答案，重点看答题的结构而不是内容——阅卷看的是有没有踩到关键词。
论文 40%。这个比例是我调整过的，前两个月低估了论文难度。

备考节奏（按月）
第 1 月：通读教材建立地图 + 每天 30 题
第 2 月：真题选择题两轮 + 案例真题每周 2 套
第 3 月：论文四大方向各写一篇 + 案例真题每周 3 套
第 4 月：论文模板背熟 + 全真模拟 3 次（严格计时）

严格计时的模拟必须做。论文两千五百字手写，很多人是没写完而不是写得差。

论文是分水岭

论文的核心不是文采，是能不能在限定时间内把一个真实项目按固定结构讲清楚。我的模板是：

项目背景与我的角色（约 400 字）
相关技术概念简述（约 400 字）
我在项目中如何应用（约 1300 字，这是主体）
遇到的问题与改进（约 400 字）

主体部分要给出具体的数字和取舍：为什么选 A 不选 B，上线后指标变化多少。空谈"提升了系统性能"是低分答案。

《领域驱动设计》读书笔记

Tue, 14 Apr 2026 00:00:00 +0000

这本书我读过三遍。第一遍在工作两年时，只记住了实体、值对象、聚合这几个名词；第二遍在做核心重构时，才发现前面几章才是重点；第三遍是带团队时读的，读出来的东西又不一样。

这本书真正的价值

大部分人把它当模式手册用，翻到"聚合"那一节抄个定义就开始设计。但 Evans 花了整本书篇幅想说的其实是一件事：软件设计的瓶颈是知识，不是技术。

模型不是画出来的，是在和业务专家反复对话中"长"出来的。书里那些模式只是长出来之后用于表达的工具。工具本身不产生知识。

一个团队如果没有和业务专家持续对话的机制，那么它用不用 DDD 的模式都无所谓——反正模型里没有真正的领域知识。

我划重点的三处

第一是统一语言。 这是全书性价比最高的概念，也最容易被跳过。如果业务方说"客户"指的是签约主体，而代码里的 Customer 指的是自然人，那么所有后续设计都建立在一个错位的基础上。我们后来的做法很土：维护一份术语表，中英文对照，明确写出每个词的边界和不包含什么。上线一年下来，它减少的沟通成本比任何架构决策都多。

第二是模型驱动设计的"绑定"要求。 书里强调模型和实现必须绑死——模型改了代码就得改，代码改了模型文档也得改。做不到这一点，模型就退化成挂在墙上的装饰。这也是为什么我不再维护单独的模型图，而是让代码本身成为模型的唯一表达：

// 反例：技术化命名，业务方看不懂，术语在翻译中丢失
public class RuleProcessor {
 public BigDecimal calc(BigDecimal amt, BigDecimal r, int type) { }
}

// 正例：类名与方法名直接采用统一语言中的业务术语
// accrual（计提）不简化成 calc，basis（计息基础）不省略
public class InterestAccrualRule {
 public Money accrue(DailyBalance balance, Rate rate, DayCountBasis basis) { }
}

第三是"深层模型"和重构的关系。 书里说好模型需要经历多次突破，而突破往往来自某次对业务的重新理解。这一点我深有体会：我们的账务模型是在第三次重写时才想清楚"分录是第一公民、交易只是外壳"，前两版都是围着交易类型打转。第一次就设计出好模型的期待本身就不现实。

读完之后我改了什么

需求评审改成建模会。不再让业务方念文档，而是当场画概念、当场确认术语。
术语表进代码仓库。放在 docs/glossary.md，跟代码一起评审，改术语要走 PR。
不再追求完整套用模式。战术模式里我们只常用值对象和聚合，事件溯源、CQRS 一律不用，除非有明确的读写比例失衡问题。
接受模型会被重写。第一版模型的目标是能跑并暴露问题，不是一次做对。

如果只有两小时读这本书，我建议读第一部分和第三部分的第 8 章（突破），跳过所有模式定义。模式的定义随便搜一下都有，而"如何通过对话获得领域知识"这件事，只有认真读原文才能体会到。

Kafka 在交易系统的削峰与解耦

Sat, 28 Mar 2026 00:00:00 +0000

交易系统引入 Kafka 通常出于两个动机：扛住流量尖峰，以及把非核心逻辑从主链路上摘下来。这两件事它都能做，但做法和注意点完全不同。

削峰：把洪峰变成队列

代发工资、批量还款、营销活动这些场景的流量特征是极不均匀——平时每秒几百笔，活动开始瞬间冲到几万笔。数据库扛不住的不是总量，是瞬时并发。

削峰的本质是用延迟换稳定：请求先落 Kafka，下游按自己的处理能力匀速消费。关键是消费端要限速，不能拿到消息就火力全开打数据库。

spring:
 kafka:
 consumer:
 group-id: txn-processor
 enable-auto-commit: false # 必须手动提交
 max-poll-records: 100
 properties:
 max.poll.interval.ms: 300000 # 留足单批处理时间，避免误判掉线
 listener:
 ack-mode: manual
 concurrency: 8 # 与分区数匹配，不要超过

concurrency 超过分区数没有任何收益，多出来的线程只会空转。要提升并行度得先加分区，而分区数一旦加了就减不回去，前期要按峰值容量规划好。

削峰只对"可以延后处理"的业务成立。用户在 App 里点转账等结果的场景不能这么做——那是同步链路，塞消息队列只是把等待转移到了别处。

解耦：从同步调用到事件

主链路上挂着一堆下游是很常见的技术债：转账成功后要发短信、更新积分、推送风控特征、写数仓。每加一个下游，主链路的失败面就大一分。

改成发一条 transfer.posted 事件，各下游自己订阅。主链路只负责记账和发事件，下游挂了不影响交易成功。

需要划清界限的是：哪些下游能异步。判断标准是这个下游失败后，业务上能不能接受"稍后补上"。更新积分可以，扣减额度不行——额度是交易准入条件，必须同步。

几个必须守住的细节

顺序只在分区内保证。同一账户的消息必须用账户号做 key，否则先扣款后入账的顺序可能颠倒。跨账户不需要全局顺序，别为了顺序把分区数设成 1。
消费端必须幂等。Kafka 是至少一次投递，重复是常态。用业务唯一键加唯一索引兜住，不要指望不重复。
先处理成功再提交 offset。自动提交会在处理失败时丢消息。手动提交虽然会带来重复，但重复有幂等兜着，丢了就找不回来了。
积压要能定位到分区。整体 lag 正常但单分区堆积，通常是某个 key 数据倾斜或者某条消息反复失败阻塞了分区。

# 按分区查看消费延迟，定位倾斜与阻塞
kafka-consumer-groups.sh --bootstrap-server "$BROKERS" \
 --group txn-processor --describe

# 排查反复失败的毒消息：从指定 offset 读一条看内容
kafka-console-consumer.sh --bootstrap-server "$BROKERS" \
 --topic txn-events --partition 3 --offset 88213 --max-messages 1

毒消息一定要有出路。处理失败超过阈值就转到死信 topic，让分区继续往下走，否则一条脏数据能把整个分区卡死几个小时。

企业级 Java AI 框架选型：Spring AI vs LangChain4j

Wed, 11 Mar 2026 00:00:00 +0000

去年团队要在 Java 技术栈上落地一批 AI 应用，绕不开这两个框架的选型。当时网上的对比文章基本都是把两边 README 抄一遍，看完还是不知道该选哪个。这篇写我们实际用下来的差异，包括最后为什么两个都在用。

选型的前提：先定义需求

框架选型没有绝对答案，只有对不对得上需求。我们的实际需求是这五条：

必须能接私有化部署的模型。行内模型走内网网关，协议兼容 OpenAI 但不完全一致，鉴权是自研的。
必须能接入现有 Spring Boot 体系。配置中心、链路追踪、指标上报、统一异常处理都已经是现成的。
需要工具调用（function calling），且工具要以真实用户身份调用下游服务。
需要 RAG，但向量库是行内统一提供的，不是 Pinecone 这类云服务。
要能做提示词版本管理和灰度。

注意第 4、5 条：这两条决定了框架自带的"开箱即用"能力对我们价值有限，我们更看重扩展点是否好写。

选型时最该问的不是"哪个功能多"，而是"我要改的那部分，改起来疼不疼"。

Spring AI 的取舍

优势

抽象设计非常 Spring。ChatClient 的流式 API 写起来舒服，和 Spring Boot 的自动配置、RestClient、Micrometer 打通得彻底。

@Service
public class ProductAdvisor {

 private final ChatClient chatClient;

 public ProductAdvisor(ChatClient.Builder builder, VectorStore vectorStore) {
 this.chatClient = builder
 .defaultSystem("你是银行零售产品顾问，只依据检索到的资料回答。")
 .defaultAdvisors(
 new QuestionAnswerAdvisor(vectorStore),
 new MessageChatMemoryAdvisor(new InMemoryChatMemory()))
 .build();
 }

 public String consult(String question, String sessionId) {
 return chatClient.prompt()
 .user(question)
 .advisors(a -> a.param(
 ChatMemory.CONVERSATION_ID, sessionId))
 .call()
 .content();
 }
}

Advisor 这个扩展点设计得不错，本质是拦截器链。我们的护栏、审计留痕、数字接地校验全部实现成 Advisor，一次编写全局生效：

分布式事务在金融场景的取舍

Mon, 23 Feb 2026 00:00:00 +0000

金融系统聊分布式事务，很容易陷入"选哪个框架"的讨论。但真实的约束是：钱不能错，且必须能查清为什么错。这两条决定了方案选择的顺序和别的行业不太一样。

金融场景的真实约束

不允许静默不一致。可以暂时不一致，但必须有机制发现并修复，不能出现谁也不知道差在哪的状态。
必须能人工干预。任何自动补偿机制都有失效的可能，最终要留一条人工处理通道，且要有审计留痕。
联机响应时间有硬指标。核心交易通常要求 100ms 内，多阶段协调的额外网络往返基本吃不下。
补偿不总是可行。已经出账到人民银行的报文没法回滚，只能发反向报文，业务语义完全不同。

最后一条最容易被忽略：很多补偿型方案假设操作可逆，但金融业务里大量操作在真实世界里是不可逆的。

几种方案的适用边界

2PC / XA：强一致，但同步阻塞、协调者单点、锁持有时间长。只在同库多表或同一数据库集群内使用。跨服务用它，第一次网络抖动就会看到大批悬挂事务。
TCC：一致性和性能都不错，代价是每个参与方要写三份逻辑（try / confirm / cancel），且必须自己处理空回滚、悬挂、幂等。开发量大约是普通接口的三倍，适合参与方少且业务确定的核心链路。
Saga：适合长流程、多参与方，比如开户流程里的证件核验、账户开立、卡片制发。要求每步都有语义补偿，且能接受中间态对外可见。
本地消息表 + 可靠投递：把消息写入和业务操作放在同一个本地事务，再由后台任务投递。实现简单、无外部依赖、可靠性靠数据库保证。缺点是只能做最终一致。

我们的默认选择：本地消息表 + 对账

绝大多数场景我们用本地消息表。理由很朴素：它没有引入新的中间件，所有状态都在业务库里，出问题时排查路径最短。

@Transactional
public void transfer(TransferCmd cmd) {
 // 1. 本地账务操作
 Voucher voucher = accountingService.post(cmd.toVoucher());

 // 2. 同一事务内写待发消息，保证原子性
 OutboxMessage msg = OutboxMessage.of(
 "transfer.posted",
 cmd.bizNo(), // 业务唯一键，下游据此幂等
 JsonUtil.toJson(voucher.toEvent()));
 outboxRepository.save(msg);
}

// 独立线程扫描待发消息，投递成功后标记；失败按退避重试
// 超过最大重试次数转入人工处理队列，不允许静默丢弃

配套三件事一个都不能省：

对客 AI Agent 平台建设思路

Mon, 09 Feb 2026 00:00:00 +0000

内部效率类的 AI 应用怎么做都不算太难，做错了也就是员工少用几次。对客不一样：一句话说错可能就是投诉、监管问询甚至赔付。这篇记录我们做对客 Agent 平台时的思路，重点不在模型，在约束。

对客场景的特殊约束

先把约束写清楚，架构自然就出来了。

不能瞎说。产品收益率、费率、期限这类数字，只要模型自由生成就一定会出错。这类回答必须来自系统数据，不能来自模型记忆。
不能越权。查余额要认证到本人，代客操作要有明确授权链路。Agent 调用工具时的身份必须是真实用户身份，不是服务账号。
要能复盘。每一次对话的输入、检索命中、工具调用、最终输出都要能查到，而且要留存到合规要求的期限。
延迟有上限。用户在 App 里等超过三秒基本就退出了。多轮反思、多次检索这些提升准确率的手段，成本是延迟。
要能降级。模型服务不可用时，必须能退回到规则问答或人工客服，不能白屏。

对客 Agent 的技术难点不是让它更聪明，而是让它在不确定的地方老实承认不知道，并且把用户交给正确的下一环节。

平台分层：从模型到业务

我们最后落在四层。分层的目的很实际：业务方只关心自己那层，不用理解底下的模型细节。

网关层

统一的模型接入层，屏蔽底层模型差异。做三件事：

多模型路由与降级（主模型超时自动切备用模型）
配额与限流（按业务方、按用户维度双重限流）
计费与用量统计（按 token 归集到业务方成本中心）

这一层不允许有任何业务逻辑。它唯一的职责是让上层调用模型像调用一个稳定的内部服务。

编排层

Agent 的运行时。定义一个 Agent 需要：系统提示词、可用工具集、知识库范围、护栏规则、降级策略。我们用配置描述而不是写代码，业务方在控制台就能改提示词并灰度发布。

agent:
 code: retail-product-consult
 name: 零售产品咨询助手
 model:
 primary: qwen-max
 fallback: internal-7b
 temperature: 0.2
 timeout_ms: 2500
 autonomy: tool_calling  # 可选 qa_only / tool_calling / multi_step
 max_steps: 3
 knowledge:
 collections: [product-manual, faq-retail]
 top_k: 5
 min_score: 0.62
 tools:
 - code: query_product_rate
 auth: user_token  # 以真实用户身份调用
 - code: query_my_balance
 auth: user_token
 require_mfa: true
 guardrail:
 input: [prompt_injection, sensitive_topic]
 output: [pii_mask, number_grounding, disclaimer_append]
 fallback:
 on_model_error: rule_based_faq
 on_low_confidence: transfer_human

工具层

工具就是被包装成模型可调用形式的业务接口。我们的规范是：工具必须是幂等查询，或者是带确认步骤的操作。没有确认步骤的写操作一律不开放给 Agent。

单元化架构：银行核心的容灾与扩展底座

Mon, 26 Jan 2026 00:00:00 +0000

单元化被讲成"异地多活的银弹"，但它真正解决的问题只有两个：把故障爆炸半径收进一个单元，以及让容量可以按单元横向叠加。理解不了这两点，做出来的往往只是一套更复杂的分库分表。

为什么核心要做单元化

传统主备架构的困境是：备机平时不承载流量，切换时没人敢按那个按钮。因为没人验证过备机在真实压力下能不能扛住。

单元化把这件事变成常态：每个单元都在真实处理流量，每个单元都是完整的业务闭环——接入层、应用层、数据库全套齐备。某个单元挂了，把它的流量按客户维度切到其他单元，其他单元本来就在跑同样的代码和同样的负载模型。

容灾能力不是靠架构图证明的，是靠每月切一次流量证明的。单元化的最大价值是让切换变成一件平常事。

单元怎么切

切分维度只有一个原则：保证绝大多数交易在单元内闭环。

对零售银行来说，客户号是最合适的切分键。同一个客户的账户、协议、流水都在一个单元，查余额、转账（同行同单元）这些高频操作不跨单元。

按客户号切：适合零售，单元内闭环率通常能到 90% 以上
按机构切：适合对公，但容易出现大行倾斜
按账号切：看着均匀，实际会把同一客户的账户打散，跨单元查询暴增

要留一类特殊单元：全局单元。存放客户号生成、产品参数、机构信息这些必须全局唯一或全局一致的数据。全局单元只读为主，写入频率极低，靠单向复制分发到各业务单元。

路由与数据一致性

路由要在尽可能靠前的位置完成。我们的做法是接入层解析出客户号后直接算单元，错误路由的请求由应用层做二次校验并拒绝，绝不允许"就近处理"。

routing:
 shard_key: customer_no
 algorithm: mod  # 客户号后四位取模，共 64 个逻辑单元
 logical_units: 64
 mapping:
 unit-sh-01: [0-15]
 unit-sh-02: [16-31]
 unit-sz-01: [32-47]
 unit-sz-02: [48-63]
 global_unit: unit-global
 strict_check: true # 应用层校验不通过直接拒绝，不做转发

逻辑单元数要一次性定足（我们定了 64），物理单元可以少。扩容时把逻辑单元区间搬到新物理单元，不用改路由算法，也不用重新哈希全量数据。

跨单元的交易（比如两个客户不在同一单元的转账）不要试图做跨单元强一致事务。正确做法是拆成两段本地事务加异步通知，中间状态用"在途"余额表达，配日终对账兜底。

踩过的坑

路由键泄漏到业务逻辑里。有个模块直接按账号查库，没带客户号，单元化后查不到数据。所有 DAO 必须强制要求分片键，缺失就报错，不要默认广播查询。
广播查询滥用。运营后台要查"全行某状态的账户"，图省事写成遍历所有单元。单元多了之后这类查询直接拖垮全部单元。这类需求应该走离线数仓。
忘了单元内的容灾。单元化解决的是单元级故障，单元内部的数据库高可用还得单独做，两者不能互相替代。

单元化的复杂度是实打实的，它换来的是可验证的容灾能力和线性的扩容路径。如果业务量还撑不起这份复杂度，主备加读写分离活得更舒服。

DDD 在银行核心系统的落地实践

Mon, 12 Jan 2026 00:00:00 +0000

银行核心系统是一类很特殊的软件：它的业务规则几十年没怎么变，但承载它的代码每隔七八年就要重写一次。我参与过一次核心的部分重构，也旁观过一次彻底失败的重写。DDD 在这两次里都被提过，但只有一次真的起了作用。这篇把我认为有效的部分和纯属自我感动的部分分开写。

为什么银行核心需要 DDD

老核心的问题从来不是技术栈老。COBOL 写的联机交易照样能扛住每秒几千笔。真正的问题是：业务知识只存在于少数几个人的脑子里，代码里找不到对应的表达。

一段典型的老代码长这样：把交易码、账户类型、产品编号、机构号混在一个几百行的过程里，用几十个 IF 分支区分场景。你想知道"活期账户计息到底怎么算"，只能从头读到尾，然后祈祷没漏掉某个补丁分支。

代码可以重写，业务知识不能。重构核心系统的第一目标不是换语言，而是把散落在分支里的规则重新变成可以被讨论的概念。

这正是 DDD 唯一真正值得投入的地方：它提供了一套让业务专家和工程师用同一套词汇讨论问题的方法。别的都是附加品。

战略设计：先切限界上下文

如果只能做 DDD 的一件事，就做上下文切分。这一步做错，后面所有战术模式都是白费。

以业务能力而非表结构切分

最常见的错误是按数据库表切：账户表归账户服务，交易表归交易服务。结果是每笔转账都要跨三个服务改数据，分布式事务满天飞。

我们最后落在这几个上下文上：

客户与关系：客户主体、关系人、证件、KYC 状态
账户与协议：账号、账户属性、签约关系、限额协议
交易处理：交易受理、要素校验、路由、冲正
账务核算：分录、余额、总账、日终结转
产品参数：利率、费率、期限、计息规则

关键判据是：一次业务动作的强一致性要求是否落在同一个上下文内。转账的"扣款成功且分录平衡"必须强一致，所以账务核算不能再往下拆；而"转账成功后更新客户活跃度"完全可以最终一致，那就是两个上下文。

上下文映射的三种常见关系

关系类型	银行场景举例	集成方式	注意点
共享内核	账户上下文与账务上下文共用币种、金额模型	公共 jar，严格版本管理	只放值对象，禁止放业务逻辑
客户方-供应方	交易处理调用账务记账	同步 RPC，供应方定契约	契约变更必须双版本并行
防腐层	新模块访问老核心账户查询	适配器 + 模型转换	老模型绝不允许穿透进来

一个反例

我们曾经把"限额"单独切成一个上下文。听起来很干净，实际上限额校验必须和交易受理在同一个事务里完成，跨服务调用一下就把联机响应时间从 40ms 拖到 90ms，还引入了新的失败分支。半年后合并回交易处理上下文。

上下文边界的正确性，用一致性要求和调用频次验证，不用概念优雅度验证。

战术落地：聚合、实体与值对象

战术模式在核心系统里的价值远低于战略设计，但用对了确实能减少一批低级 bug。

聚合的粒度取决于一致性边界

账务这块我们的聚合是"分录凭证"（Voucher），不是"账户"。一张凭证包含多条分录，借贷必须平衡，这是不可分割的一致性单元。账户余额是凭证记账的结果，通过事件更新。

开博第一篇：为什么写「追风笔记」

Sat, 15 Aug 2026 00:00:00 +0000

做银行系统架构这些年，踩过的坑、想明白的事，大多散落在笔记本和聊天记录里。开这个站点，是想把它们系统地沉淀下来。

我会写什么

架构专栏：客户信息系统（ECIF）、核心系统、分布式架构，以及领域驱动设计（DDD）在银行场景下的落地。
银行业务专栏：支付清算、计息与限额、账户/卡、反洗钱（AML）/KYC/CRS 等核心业务梳理。
数据专栏：数据治理、加密与安全、分库分表、消息与流处理。

写给谁

同行、想转行做金融科技的工程师，以及任何对「银行系统为什么这么设计」感到好奇的人。

这个站点是示例内容，框架搭好后，真实文章会逐步替换进来。

在银行客户信息系统（ECIF）里落地 DDD 聚合

Wed, 12 Aug 2026 00:00:00 +0000

ECIF 里「客户」的概念极其庞大：个人、对公、同业，各自的属性、关系、生命周期都不同。如果用一个巨大的 Customer 实体硬扛，代码会迅速腐化。

用界限上下文切分

把客户拆成几个界限上下文：

客户主数据（Party）：统一的自然人/机构标识与基础属性。
客户画像（Profile）：风险偏好、营销标签，读写频率高、变化快。
客户关系（Relationship）：持股、担保、集团关系。

聚合根怎么定

每个上下文内部再定聚合根。例如 Party 上下文里，Party 是聚合根，Address、Contact 是其值对象，保证一致性边界内不跨聚合调用。

经验：聚合的边界应以「事务一致性」而非「业务概念大小」来划。ECIF 里最容易犯的错，就是把所有客户信息塞进一个聚合。

这样设计后，主数据服务稳定，画像服务可以独立迭代，互不影响。

一文理清 ECIF：客户信息为什么要「集中」

Mon, 10 Aug 2026 00:00:00 +0000

在没有 ECIF 的年代，网点、网银、信用卡中心各自维护一份客户信息。同一个客户，在不同系统里姓名、证件、联系方式都不一样，营销和风控都无从谈起。

ECIF 解决什么

ECIF（企业客户信息整合）把分散在各业务系统的客户主数据收敛到一处，对外提供唯一客户视图。

唯一标识：用客户号（Party ID）统一自然人/机构，而非证件号。
主次关系：支持一人多户、一户多卡，但主数据唯一。
服务化：其他系统通过接口查询，不再各自落库。

技术上的关键取舍

读写分离：主数据写入强一致，查询可走缓存/只读副本。
变更可溯源：客户信息变更需要留痕，满足监管审计。

ECIF 不是「又一个数据库」，而是银行数字化的最底层地基。

关于

Mon, 01 Jan 0001 00:00:00 +0000

##（页面为 AI 生成，仅供参考）

简介

王鹏，数学学士 + 软件工程硕士（跨专业），从事核心系统后端研发。主要关注分布式架构、单元化部署、银行核心业务建模，以及 AI 在银行业务中的工程化落地。

证书：PMP
技术主线：Java 后端、分布式系统、DDD / CQRS / Saga、企业架构与数据资产
当前重点：对客 AI Agent 平台建设；企业级 Java AI 框架选型（Spring AI 2.0 / LangChain4j / SAA / Embabel）

经历

阶段	内容
教育	数学本科 → 软件工程硕士（跨专业转型）
现任	银行核心系统研发工程师
备考	软考高级「系统架构设计师」

技术栈

Java · Spring Cloud · 分布式事务 · 单元化 · DDD · 数据库（MySQL / 分库分表）· 消息与流（Kafka）· 缓存（Redis）· 协调服务（ZooKeeper）· 微服务治理 · 企业架构

项目与研究

详见项目与技术笔记。近期方向包括：投资顾问系统（AKShare + Supabase + All-Weather）、认知匹配 / AI 认知画像、PageFly 轻量页面托管、中文 AI 人味化、银行业本体论，并计划重启「银行科技 + AI」主题公众号。