← 返回索引 · 2026-02-17 · 0011

撮合引擎中的精度之殇：从浮点数陷阱到定点数救赎（摘要）

原文首发于 TechNova： 撮合引擎中的精度之殇：从浮点数陷阱到定点数救赎

承接页（解决方案）：https://technologynova.org/solution/

1. 为什么这事会把系统搞“死”

在金融交易系统里，数值表示方式直接决定了：订单簿索引能不能命中、成交金额能不能对账、主备切换能不能严格一致。 经典示例是 0.1 + 0.2 输出 0.30000000000000004。这不是“打印格式问题”，而是 IEEE754 的二进制表示天然无法精确表达很多十进制小数。

• 匹配失败：订单簿以价格为关键索引时，0.3 与 0.1+0.2 的二进制表示不同，可能导致“看起来相等、实际上不等”。
• 账目不平：乘法/加减累计误差会在高频交易中不断放大，最后清算出现“解释不清”的差额。
• 确定性丢失：主备节点或不同 CPU/FPU 实现对浮点计算的细微差异，可能让回放后的状态分叉（灾难级）。

2. 根因：IEEE754 的“合理但不适合金融”

IEEE754 用符号位 + 指数 + 尾数表示浮点数，能覆盖很大范围，但尾数本质是二进制小数。 十进制里常见的 0.1、0.2 在二进制下是无限循环小数，只能用“最接近的可表示值”近似。 这意味着：误差从“存进去那一刻”就已经存在。

3. 两条路：BigDecimal/DECIMAL vs 定点数（Fixed-Point）

3.1 BigDecimal（或数据库 DECIMAL）：正确性优先，但不适合撮合热路径

• 优点：十进制精确；舍入模式可控；对账/报表/清算更顺手。
• 代价：对象与大整数运算带来显著 CPU/内存开销；在撮合循环里容易把性能与尾延迟拖垮。

3.2 定点数：用整数承载价格与数量

核心思想：统一缩放因子（scale），把小数转成整数存储与计算。 例如价格保留 4 位：price_int = price * 10^4；数量保留 8 位：qty_int = qty * 10^8。 内部只做整数加减乘除（或在中间计算用更宽位宽），保证确定性与性能。

4. 适用场景：什么时候“必须定点数”

• 撮合引擎/订单簿/风险校验处于高吞吐热路径，需要 µs 级稳定尾延迟。
• 系统要求可回放、可审计、主备完全一致（事件溯源/日志回放）。
• 多资产、多精度并存，需要在架构层面建立统一的精度与舍入规范。

---