设计数字钱包

一句话

你以为设计数字钱包是设计一张余额表，其实这一章从头到尾在做一件事：把「余额」这个可变字段拆掉。它从 Redis 里的一个数字出发，被三条需求（跨分区原子、100 万 TPS、可复现审计）一路逼到终局——不可变事件日志 + 确定性状态机 + Raft 复制 + 分片后跨组 TC/C。读完你拿到的不是一套钱包方案，而是一条思路：正确性靠可重放，不靠可信任。

Glossary · 术语表

坐标

本章是 Vol 2 的倒数第二章，紧接 Ch11「支付系统」：Ch11 处理的是钱跨出公司边界（对接第三方支付服务商、超时既不是成功也不是失败）；Ch12 转身向内，处理同一个系统内部两个账户之间的划拨。它又下启 Ch13「证券交易所」——把「单线程确定性处理 + 可重放」这同一套思路推到微秒级。现实对应：PayPal 余额、支付宝零钱、券商资金账户、交易所的用户余额、游戏内货币。

这章要解决什么

题面只有一句：支持钱包 A 给钱包 B 转 1 元。难度全在三条非功能需求上——转账必须原子、系统要扛住 100 万 TPS、账目必须可复现（可审计）。

三条各砍一刀。原子性那一刀最直接：A 和 B 大概率落在不同分区，跨机器的「要么全成要么全不成」是分布式系统里最贵的东西之一。100 万 TPS 那一刀砍掉了「每笔都写数据库」——关系数据库的解析、索引维护、行锁与事务日志撑不到这个量级。

可复现那一刀最容易被忽略，却是真正的分水岭：只存「现在余额是多少」，「上周二 21:00 余额是多少、被哪几笔改成这样的」就永远答不了。于是对账对不上时没有第二份口径可比，用户投诉时举不出证，逻辑改错了也没法拿历史数据回放验证。钱这件事上，「说不清」和「算错了」一样致命。

核心内容，讲透

一、第一版：Redis 里的一个数字，撑不过三行需求

书里先给最直观的方案：钱包服务做成无状态的一层，余额按 userId 哈希分片放进内存键值存储（如 Redis 集群），转账就是两次加减。它逐条失守：Redis 跨节点没有事务，A 减了 B 没加的窗口真实存在；内存里的余额一断电就没了；而且它只记得「现在」，不记得「为什么」。先啃最硬的原子性。

二、2PC：把锁一直攥到最后一刻

两阶段提交（two-phase commit, 2PC）是教科书答案：准备阶段协调者问每个参与者「能提交吗」，参与者锁住相关行、写好重做日志、回答 yes；提交阶段协调者统一下令提交或回滚。

两条硬伤正好卡在钱包场景上。其一，锁的持有时间等于整个协议的时长——两轮网络往返，同机房毫秒级、跨机房几十毫秒级，热点账户上足以把吞吐锁死。其二，协调者在两阶段之间崩溃，参与者就吊在那儿：锁不敢放、数据不敢动，恢复之前谁也过不去。它语义干净，但对一个目标 100 万 TPS 的系统太重。

三、TC/C：把两阶段搬到应用层

Try-Confirm/Cancel 和 2PC 长得像，关键差别只有一句：每个阶段都是一次立刻提交的本地事务，锁在毫秒内就放掉了。

• Try：A 分区把 1 元从「可用」挪到「冻结」，本地事务立即提交；B 分区预留一个入账位。
• Confirm：A 把冻结的 1 元真正扣掉，B 真正入账。
• Cancel：A 解冻，B 撤销预留。

代价是它把三件本来由数据库兜底的事推给了你自己：

• 幂等：协调者会重试，每个 Try / Confirm / Cancel 都必须可重复调用而只生效一次。做法是每个分区建一张相位状态表（phase status table），以全局事务 ID 为主键记录该事务走到哪一步，并和业务表的改动放进同一个本地事务提交——「钱改了但状态没记上」在物理上就不可能发生。
• 空回滚：Try 的包丢了，Cancel 先到。分区必须能识别「我压根没 Try 过」，记一条空记录直接返回成功，而不是去解冻一笔不存在的钱。
• 悬挂：迟到的 Try 在 Cancel 之后才抵达。分区必须查状态表、发现已取消并拒绝它——否则那笔冻结再没人来解。

还有一条概念上的代价，面试里常被追问：Confirm 之前的中间态对外可见。A 的可用余额已少了 1、B 还没多 1——这 1 块钱短暂地「不在任何人账上」。严肃的账务系统会把它显式建模成在途资金科目，而不是假装这个窗口不存在。

四、Saga：一串本地事务 + 反向补偿

Saga 走另一条路：把转账拆成顺序执行的一串本地事务 T1, T2, …，每个配一个补偿事务 C1, C2, …；中途失败就反向依次跑补偿。协调方式两种——编排（orchestration）由一个协调者发号施令，全链路状态看得见、好排障；编舞（choreography）各服务订阅事件自行反应，耦合最低，但没有任何一处拿得到全局进度。

和 TC/C 的分水岭是一句话：Saga 是「一路做完再往回撤」，TC/C 是「先都预留、最后一起落定」。Saga 的 T1 一提交钱就真动了；TC/C 多付一次 RPC 和一张状态表的开发量，换来「落定前还能整体取消」和各分支可并行。取向也直白：延迟敏感、步骤少 → TC/C；长流程、跨多团队服务 → Saga。

五、事件溯源：把余额从「存的」变成「算的」

原子性解决了，可复现还欠着。事件溯源（event sourcing）的四件套要一次认清：

• 命令（command）：一个意图——「把 1 元从 A 转给 B」。可以被拒绝（余额不够）。
• 事件（event）：一个已经发生的事实，不可变、不可拒绝。这里是本章最硬的一条约束：事件必须是确定性的——不能藏 now()、随机数或外部调用，否则重放会算出不同结果，整套机制当场作废。
• 状态（state）：所有事件按序作用之后的结果，也就是余额。
• 状态机（state machine）：唯一的那台机器，逐条读命令 → 校验 → 生成事件 → 追加进事件日志 → 更新状态。命令必须走 FIFO 队列、由一台状态机串行消费——顺序本身就是语义：「先转出 100 再存入 50」和反过来，结果完全不同。

读怎么办？余额查询若也去打这台状态机，写路径立刻被拖死。CQRS（命令查询职责分离）把读拆出去：另起一批进程消费事件流、物化成读侧视图，查询只打视图。代价必须写明：读侧是最终一致的，用户可能在转账后的几十到几百毫秒内看到旧余额——所以成功页通常直接回显状态机算出的结果，而不去读视图。

而「可复现」是白给的：从某个快照出发把之后的事件依次喂回，就得到那一刻的余额，以及它被哪几笔改成这样。对账、投诉举证、拿新版本逻辑回放昨天的真实流量做验证——全靠这一条性质。

六、跑快、跑稳、扩上去

单台状态机离 100 万 TPS 差得远，书里分三步补齐。

跑快——把数据库换掉。事件日志只需要一个动作：往末尾追加，这恰恰是磁盘最擅长的；而关系数据库为了通用性要付解析、索引维护、行锁、事务日志的多重代价。改成直接追加本地文件、状态常驻内存后，单节点吞吐能上一个量级。粗算就知道瓶颈不在盘上：一条事件按 100 字节计，100 万条/秒也只有约 100 MB/s，而 NVMe SSD 的顺序写带宽在 GB/s 量级。快照负责重启——不必从创世事件重放。

跑稳——单节点内存加本地文件，机器一没就全没。用 Raft 把状态机复制成 3 或 5 副本：leader 把日志条目发给 follower，多数派落盘才算提交；leader 挂了，follower 选出新 leader，日志一模一样，接着跑。这就是复制状态机——确定性逻辑 + 相同的输入序列 = 相同的状态。事件溯源和 Raft 是天生一对，因为两者的核心是同一样东西：一条有序的、不可变的日志。

扩上去——一个 Raft 组的吞吐终究受限于它那个 leader。按钱包 ID 哈希分成多个 Raft 组，组内串行、组间完全并行，要更高吞吐就加组。于是跨组转账又变回了分布式事务，用前面那套 TC/C 在组间做——绕了一整圈，两条线在这里合上。

关键权衡与选型

表 1 · 三种跨分区事务方案：转 1 元这件事交给谁兜底

表 2 · 余额怎么存：一个可变字段，还是一串不可变事件

还有两个量级选择常被追问。副本数：3 副本容忍 1 台故障、写入等 2 票；5 副本容忍 2 台但要等 3 票、尾延迟更高——同机房部署默认选 3，跨机房才考虑 5。分片数：分片越多并行度越高，但跨分片转账的比例也越高，而每一笔跨分片都要付 TC/C 的全部开销。所以分片键的原则是让尽可能多的转账落在组内——真实系统常按业务域（同一商户、同一地区）聚簇，而非纯随机哈希。

为什么重要 / 落到真实系统

这一章的终局架构不是教学玩具，它几乎是当代分布式数据库的标准形状：数据按键分片，每片是一个共识复制组，跨片写走一个两阶段协议。TiKV、CockroachDB、YugabyteDB 都是这个骨架；区别只在于它们做成了通用数据库，而钱包做成了专用账本。

「不可变日志 + 确定性重放」也不只属于钱包：Kafka 把它做成了基础设施，MySQL 的 binlog、PostgreSQL 的 WAL 本质上是同一件事——先把「发生了什么」顺序写下来，状态永远是它的派生物。这也解释了为什么崩溃恢复、主从复制、CDC（变更数据捕获）三件看似无关的事，用的是同一条日志。

易错点与争议

• 把 TC/C 的 Cancel 当成回滚。回滚是「当作没发生过」，补偿是「再做一笔把它抵消」——中间态真实存在过，可能被人看到、被下游读走。账务上必须把在途资金显式建模。
• 让事件不确定。事件里调了 now()、随机数或外部接口，重放就会算出另一个结果——而重放正是整套架构的地基。非确定性输入必须在生成事件时固化成字面值。
• 以为事件溯源自带一致的读。CQRS 读侧最终一致，「转完账刷新看到旧余额」是设计的一部分不是 bug；要么成功页回显写路径结果，要么给读请求一个「读己之写」的粘滞路由。
• 低估事件模式演进的代价。事件永不修改，意味着五年前那版结构你得永远能解析：字段只能加不能改语义，重放代码要长期兼容旧版本。这是比存储更贵的长期成本。另有一条法规上的正面冲突——GDPR 之类要求可删除个人数据，而日志的核心承诺是不可变；业界折中是加密擦除（删除时丢弃密钥），是妥协不是解法。
• 把 100 万 TPS 当成普遍需求。这是面试题为逼出架构而设的约束。对照上一章：支付系统那道题只有每秒千级。没有这条约束，一个带审计表的关系数据库就够了——本章大半复杂度都是那个数字逼出来的，照抄到量级不匹配的系统上是典型过度设计。
• 本书体例的局限：面试书不是工程手册，给的是架构骨架与取舍线索，不覆盖风控、多币种、会计科目体系与监管报送——真实钱包里这些的工作量往往不比架构小。

要点