开场
在传统互联网公司做了 7 年后端，我以为自己已经见过各种”高并发系统”。
转到交易所做了几年后，才发现交易系统是完全不同的物种。不是简单的”流量更大”，而是从设计思路到工程哲学都不一样。
这篇总结 10 个让我一度惊讶、后来认同的观点。如果你也在做交易相关系统，或者想去做，这些经验可能帮你少走弯路。
这篇讲的是工程哲学层面的差异。如果你想看具体踩过的技术坑，可以配合《做交易所 Web3 后端两年，多链扩展的三个血泪教训》一起读；转型路径本身我写在《从 Web2 转 Web3 后端：一个工程师的生存笔记》。
1. 一致性比可用性更重要
互联网产品的默认逻辑：用户永远对，服务永远在。
交易所的默认逻辑：宁可服务中断，不能数据错误。
原因很简单：
- 互联网产品出错 → 用户刷新一下
- 交易系统出错 → 钱没了，可能是上万上百万美元
实际案例：某次我们发现一个交易数据同步的 bug，可能导致少量用户的余额显示错了。第一反应不是”修补丁 + 继续运行”，而是紧急停机 10 分钟，确认所有受影响数据，一笔笔对账。
对传统后端来说这太”过度反应”，对交易系统来说这是常规操作。
2. 时间比你想的重要
互联网产品：接口 100ms 和 300ms 差别不大，用户感知不到。
交易系统：每一毫秒都是钱。
举例：
- 用户 A 和用户 B 同时下市价单
- 谁的订单先到达撮合引擎 → 谁先成交 → 价格可能差几个点
- 100ms 的延迟对一笔 $100K 的订单可能就是几十到几百美元
所以交易系统的设计里有大量”提前准备”：
- 数据提前加载到内存
- 订单路径上不做任何可避免的 I/O
- 网络延迟敏感到机房位置都要优化
3. 幂等是底线，不是加分项
互联网产品：幂等是”好实践”，没做也能跑。
交易系统：任何不幂等的接口都是定时炸弹。
为什么？
- 用户下单请求超时 → 重试 → 你要保证不会下两次单
- 链上交易广播失败 → 重新构建 → 保证不会双花
- 清算系统查询 pending orders → 重复执行 → 保证结果一致
每一个写操作都必须有 request_id / nonce / idempotency_key，在数据库层面保证唯一性。这不是架构师的偏好，这是活命的基础。
4. 监控的粒度决定了你能不能睡觉
互联网产品：分钟级监控就够了。
交易系统：秒级是基础，毫秒级才是真正需要的。
我们的核心指标：
- 订单延迟 P99.9（不是 P99！）
- 撮合引擎每秒订单数
- 数据库写入 TPS + 最慢查询
- 每个核心服务的内存和 GC 停顿
监控系统本身的延迟都有监控。一切能量化的都要量化。
没有极致的监控，你永远不知道下一次事故会发生在哪。
5. 回滚策略比发布策略更重要
互联网产品：发布失败 → 快速回滚。
交易系统：不能回滚的发布永远不发。
原因：
- 如果回滚意味着数据丢失或错误 → 永不回滚
- 所有 schema 变更必须向后兼容
- 所有代码逻辑必须支持”新旧版本共存”
这意味着发布节奏会慢得多。很多”简单的”优化都因为”不能安全回滚”而放弃。
对追求快速迭代的人来说这是折磨。但对资金安全来说这是必须。
6. 所有异常都要 panic
互联网产品：出异常 → 打个 log，继续处理。
交易系统：任何意外都 panic（或类似机制）。
为什么？
假设一笔交易，某个中间步骤返回了意外的结果。两种处理方式：
- 继续处理 → 可能导致账务错乱，用户损失
- 立即 panic + 告警 → 人工介入处理
在金钱面前，宁可错杀一千，不可放过一个。
这和传统后端”容错”思维完全相反，但是正确的。
7. 冷备不等于高可用
互联网产品：主库挂了 → 切到从库 → 几分钟恢复。
交易系统：切换过程中的每一秒损失都不能接受。
所以交易系统的高可用是：
- 多活（不是主备）
- 数据实时复制（不是异步）
- 切换 < 1 秒（不是几分钟）
做一个真正 5 个 9 可用性的交易系统，成本是普通互联网系统的 10 倍以上。
8. 测试要比代码多
互联网产品：代码和测试 1:1 甚至测试少。
交易系统：测试代码至少是业务代码的 3-5 倍。
为什么？
- 每个核心路径要有单元测试
- 每个异常路径要有单元测试
- 每个组合场景要有集成测试
- 每次性能改动要有压力测试
- 关键业务还要有形式化验证
没有足够的测试，你根本不敢改代码。
9. 限流不是最后的防线，是第一道
互联网产品：业务写好 → 最后在网关加个限流。
交易系统：每一层都有限流。
- API 网关：基础限流
- 业务服务：按用户、按账户、按金额的动态限流
- 撮合引擎：市场级限流
- 风控系统：异常行为限流
- 交易广播：链上操作的限流
没有充分的限流，一个 bug 或一次攻击就能把系统拖垮。
10. 你的最大风险不是技术问题，是人
这是最反直觉的一条。
在传统后端，最大的风险通常是技术问题：bug、硬件故障、流量突增。
在交易系统，最大的风险是人：
- 运维误操作（改错了一行配置）
- 内部人员盗用（key 被泄露）
- 社会工程学（假装客服骗密码）
- 权限滥用（开发环境操作了生产数据）
所以交易系统的安全设计：
- 最小权限原则（每个人只有必要的权限）
- 双人审批（关键操作两个人同时在场）
- 审计日志（所有操作可追溯）
- 定期轮换（防止 key 长期暴露）
技术防护相对容易，防人的漏洞才是最难的。
结论
交易所的工程文化可以总结成一句话：
宁可慢一点、贵一点，也不能出任何不可恢复的错。
这和互联网”快速迭代、容忍小错”的文化完全不同。
对于习惯了互联网的工程师来说，转过来会有一段痛苦的适应期。但一旦你理解并内化了这种工程哲学，你做任何系统的标准都会高一个层次。
这也是为什么很多从交易所出来的工程师，再做互联网反而觉得”太轻松了”。
对你的建议
如果你有机会进入交易系统或想进入：
- 抛弃”用户永远对”的思维 —— 在金融系统里，数据第一
- 习惯更慢的发布节奏 —— 每次上线都要慎之又慎
- 学会看监控 —— 这是你的”感官”，没它就是瞎子
- 理解”金钱的重量” —— 你的代码管着真金白银
这些经验不只对交易所有用，对任何需要高可靠的系统都适用。
延伸阅读
- 做交易所 Web3 后端两年，多链扩展的三个血泪教训 —— 本文的”具体案例版”，三个真实的技术坑
- 从 Web2 转 Web3 后端：一个工程师的生存笔记 —— 转型的动机、挫败和收获
- 头部 Meme 平台月烧 $700K，钱花在什么上 —— 高可靠系统的成本到底花在哪