上篇讲了内存化系统的设计思路，这篇是一次真实落地的案例，聊聊对账怎么做内存化，以及它在吞吐量、成本和工程复杂度上带来了什么。
很多系统里，对账就是：两张表、一条 JOIN、一个定时任务。
流水量小的时候没问题。但量上来之后，JOIN 越来越慢，跨周期的逻辑越来越绕，锁、事务、补偿代码层出不穷。
根子在哪？对账不是 CRUD，是一个持续推进的状态机。
它有几个特点：流水量大，但生命周期有限；同一条流水只能处理一次；顺序和确定性很关键。这几点加在一起，恰好是内存化最合适的场景。
MySQL 做结果存档没问题，但对账需要的是过程计算：
流水到千万级，对账系统就变成了一堆 SQL 在和时间赛跑。
先说结论：Flink 做对账不是不行，是有点重。
Flink 的优势在于来源多、乱序严重、迟到数据多的场景。用 keyBy + state + watermark 处理乱序，确实优雅。
但对账的真正瓶颈往往不是"能不能算出来"，而是吞吐够不够、成本能不能接受、复杂度能不能长期维护。
落地下来，Flink 的问题集中在三块：
所以 Flink 做对账是能用，但单位资源能跑多少流水，比内存化差不少。
先说一个常见误解：内存化不是"为了快，把数据库换成内存"。它改变的是状态管理方式。
内存就是状态机。 对账状态只在内存里，内存里有什么，系统当前就是什么状态。没有"内存一份、数据库又一份"的数据冗余。
单写入者，顺序执行。 同一个对账任务只有一个线程在写，所有变更按顺序发生。不需要锁，不需要事务，也不需要对"并发写同一条流水"做任何处理。
可重建，而不是不能丢。 内存数据可以丢，但丢了之后要能重新建出来。这是后面"对账文件当 WAL 用"能成立的前提。
对账场景有个常被忽略的事实：对账文件本身就是天然的 WAL。
文件记录的是已经发生的事，顺序固定、可重放，不需要再设计额外的日志系统。
快照不是全量流水的备份，而是一个或多个对账周期结束后，内存里还没对平的那部分流水。
恢复流程：加载最近快照，然后从对账文件里继续往后推进。就这两步。
对账流程分几个阶段：
数据获取。 来源可以是对账文件、数据库导出、FTP 或 HTTP 上传，具体形式不重要。核心是拿到某个对账周期（1 分钟、1 小时、1 天）内的数据截断。
预处理（可选）。 多文件合并、按业务时间排序、处理上游乱序。上游已经有序的话，这步直接跳过。
读取。 顺序读每个业务方的对账文件，生成流水唯一 ID，写入各自的内存队列。把外部数据稳定地变成内存事件。
对账。 从一个队列里取数据，去另一个队列里找匹配。对平了就从两个队列里都删掉，没对平就放回队列尾部等后续流水。
持久化。 每个周期结束后，把内存里还没对平的数据存成快照；单边账写入数据库；配置和周期相关数据用单独的表维护。
运行流程：
读取线程往队列尾部写流水，对账线程从头部取流水去匹配。能对平的直接删，不能对平的放回尾部。循环往复，队列里的数据慢慢被消化掉。
内存里剩下的就是当前系统状态，也是快照的内容。重启后，从最新快照恢复内存，再从快照点之后的对账文件重新开始对账。
不同系统生成的对账文件，同一条业务流水的时间戳可能不同，有时候会落到不同的对账周期里。
所以一个周期内没匹配上，不代表是异常。当前周期的未对平流水会留下来，下个周期继续尝试。连续多个周期都没对平，才判定为异常。这样可以避免因为周期边界问题产生大量误报。
队列模型能跑起来，两边的流水得大致有序。
严重乱序的话，大量数据长期无法匹配，队列消不掉，内存就会一直涨，最终把对账任务撑死。实际工程里要么在预处理阶段排序，要么对上游提顺序约束。
对账任务和所有来源任务必须在同一个周期里。对账还在处理 9 月 15 日，某个来源任务已经在读 9 月 16 日的数据，状态就乱了。
对账系统通常不太在意单条延迟，更关心同样机器资源下一分钟能对多少流水。
| 方案 | 单机吞吐量量级 | 主要限制因素 |
|---|---|---|
| MySQL | 万级 / 分钟 | IO、索引、锁 |
| Flink | 十万级 / 分钟 | State、Checkpoint |
| 内存化 | 百万级 / 分钟 | 内存容量与带宽 |
Flink 的绝对吞吐量不差，但资源花在了通用性和分布式能力上。内存化方案只解决对账这一件事，相同资源下算力更集中，吞吐通常高一个数量级，延迟分布也更稳定。
说说缺点。
状态全在内存里，风险也集中。设计阶段要克制，分区方式直接决定系统上限。
但对账场景顺序明确、状态可回收，这两点恰好是内存化最能发挥的地方。
内存化对账没什么神秘的，是一个务实的工程选择。
数据乱序、周期错位、系统崩溃，这些都会发生。内存化的方式是通过顺序执行和可重放的输入，把复杂性限制在它该在的地方处理，而不是扩散到整个系统。
如果你的对账系统吞吐量撑不住、成本压不下来、逻辑越来越乱，内存化不一定是激进方案，可能只是换了个更直接的路。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。