一、做市库存数据一致性概述
做市交易这个领域，我干了快十年了。刚入行那会儿，带我的老大哥跟我说过一句话，我到现在都记得——「做市商的核心竞争力，不是策略多牛逼，而是你的账能不能算清楚」。当时我不太理解，直到自己踩过坑，才明白这句话的分量。
今天咱们就来聊聊，做市库存数据一致性到底是个什么事儿。说白了，就是你的系统里记录的库存，跟实际交易所那边的持仓，是不是对得上。
1.1 为什么需要数据一致性
你想想看，做市商每天都在干嘛？不停地挂单、撤单、吃单。一秒钟可能几十笔交易。如果库存数据不准，后果是什么？
- 风控失效：你以为自己还有1000个BTC，实际上已经卖超了。交易所那边直接给你强平，那损失可不是小数目。
- 策略误判：库存数据是策略的输入。数据错了，策略就是瞎指挥。我见过一个团队，因为库存少记了200个ETH，策略以为仓位轻，疯狂加仓，结果爆仓了。
- 对账困难：每天收盘后对账，发现差了几百个币，查日志查到凌晨三点。这种事，我干过不止一次。
核心观点：数据一致性不是锦上添花，而是做市系统的生命线。没有一致性，一切都是空中楼阁。
1.2 库存数据不一致的典型场景
我在项目中遇到过不少奇葩情况。这里列几个最常见的，你看看有没有共鸣。
| 场景 | 描述 | 后果 |
|---|---|---|
| 订单状态丢失 | 订单已成交，但系统没收到成交回报 | 库存多记，以为还有货，实际已卖光 |
| 重复处理 | 同一笔成交被处理了两次 | 库存少记，以为没货了，实际还有 |
| 网络延迟 | 成交回报延迟到达，导致时序错乱 | 库存计算出现短暂偏差 |
| 系统重启 | 重启后未恢复未完成订单状态 | 库存数据永久性丢失 |
| 多数据源冲突 | 交易所API和本地数据库数据不一致 | 不知道信哪个，决策瘫痪 |
嗯，这里要注意。上面这些场景，很多时候不是单一发生的。往往是几个问题叠加在一起，那才叫一个酸爽。我曾经有一次，因为网络抖动加上消息队列积压，导致库存差了3000多个USDT。查了整整一个周末才定位到问题。
1.3 一致性保障的核心目标
聊完了问题，咱们说说目标。做市库存数据一致性保障，说白了就是要做到三件事：
- 实时准确：系统里的库存，跟交易所的实际持仓，误差在可接受范围内。我个人习惯是控制在0.1%以内。
- 可追溯：每一笔库存变动，都能查到来源。谁改的、什么时候改的、为什么改的，清清楚楚。
- 自动修复：出现不一致时，系统能自动检测并修复，而不是等着人工介入。
我的经验：不要追求100%的实时一致性。在分布式系统里，最终一致性往往更现实。关键是你能容忍多大的偏差，以及多久能修复。
你可能会问，这三个目标哪个最重要？我个人觉得，可追溯性是最容易被忽视的。很多团队只盯着实时准确，结果出了问题根本查不到原因。我建议从一开始就把日志和审计机制设计好，不然后面补起来，成本高得吓人。
知识体系总览
下面这张图，是我自己梳理的做市库存数据一致性的核心逻辑。你可以把它当作本章的思维导图。
避坑指南：我曾经犯过一个错误——一开始只关注了实时准确，忽略了可追溯性。结果有一次库存对不上，日志里啥也没有，只能靠猜。后来我花了整整两周，才把审计日志补上。这个教训告诉我，设计阶段就要把可追溯性考虑进去，不然后面补，成本翻倍。
好了，这一章的内容就到这里。记住一句话：数据一致性不是技术问题，而是设计问题。只要你在架构设计阶段就把它当回事，后面能省很多麻烦。