架构 on 追风笔记

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 让长流程可回退，再加独立对账，复杂业务才算立得住。

银行核心系统建模随笔

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, 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 个物理库，扩容时只搬分片区间，不用重新哈希。如果直接按物理库取模，第一次扩容就要迁移全量数据。

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，让分区继续往下走，否则一条脏数据能把整个分区卡死几个小时。

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

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);
}

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

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

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

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

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

为什么银行核心需要 DDD

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

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

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

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

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

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

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

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

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

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

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

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

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

一个反例

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

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

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

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

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

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