第1章做市业务全景与监控挑战

一、做市业务全景与监控挑战

做市商不是靠预测涨跌赚钱的。这个很多人搞混了。

说白了，做市商赚的是「买卖价差」和「交易所返佣」。你想想看，一个做市商同时在买一价挂单、卖一价挂单，只要市场来回波动，两边都能成交。每次赚一点点，但一天几百万笔交易下来，利润就相当可观了。

我刚开始接触做市业务时，觉得这生意稳赚不赔。后来才发现，没那么简单。做市商最大的风险是什么？是「库存风险」。比如你手里囤了一堆ETH，突然市场暴跌，你还没来得及调整报价，就已经亏惨了。

  核心盈利模式拆解：
  价差收入：买一价与卖一价之间的差额，通常只有0.01%~0.05%
交易所返佣：交易所为了流动性，会给做市商返还交易手续费，甚至倒贴
资金费率套利：在永续合约市场，通过资金费率赚取额外收益

嗯，这里要注意一点。做市策略的收益曲线，看起来应该是一条平稳向上的斜线。如果你看到某个做市商的收益曲线像过山车一样，那说明他其实是在赌方向，不是真正的做市。

很多人以为监控就是看看服务器CPU、内存、网络延迟。这远远不够。

全链路监控，我个人的定义是：从行情数据进入系统，到策略计算，再到订单发送、交易所确认，最后到仓位和盈亏更新，整个链条上的每一个环节都要可观测、可追溯、可告警。

我在项目中遇到过这样一个案例：某次行情剧烈波动，策略端明明发出了卖出指令，但交易所那边就是没收到。排查了半天，发现是网络中间某个交换机丢包了。如果没有全链路监控，这种问题根本定位不了。

具体来说，全链路监控应该覆盖以下层面：

你想想看，如果只监控了服务器CPU，策略卡死了你都不知道。因为CPU可能还是正常的，但策略线程已经死锁了。这就是为什么全链路监控必须深入到业务逻辑层面。

做市业务对延迟极其敏感。我见过最极端的场景，延迟每增加1毫秒，收益就下降5%。所以监控本身不能成为性能瓶颈。

这里有几个典型的难点：

难点一：监控本身引入延迟

我曾经在某个项目中，为了记录详细的订单日志，在核心路径上加了大量的日志打印。结果呢？策略延迟从50微秒飙升到了200微秒。后来我们改用异步日志 + 内存环形缓冲区，才把延迟降回来。

我的建议：

核心路径上的监控，一定要用无锁数据结构 + 零拷贝技术。比如用LMAX Disruptor做事件队列，用内存映射文件做日志存储。非核心指标，可以走旁路采集，不要阻塞主流程。

难点二：海量数据的实时处理

做市系统每秒可能产生几十万条订单事件。把这些数据全部实时聚合、计算、存储，对系统压力非常大。我见过有些团队直接把所有数据丢到Elasticsearch里，结果ES集群直接被打挂了。

怎么解决？其实可以分层处理：

难点三：分布式环境下的时序对齐

做市系统通常部署在多台机器上，甚至跨机房。不同机器的时钟可能差了几毫秒。这就导致一个问题：你看到行情在10:00:00.000到达，策略在10:00:00.003发出订单，但这两条日志可能来自不同的机器，时间戳根本对不上。

我个人习惯的做法是：所有机器统一使用PTP（精确时间协议）同步时钟，精度可以到微秒级。同时在每条日志里带上一个全局递增的序列号，方便跨机器关联。

说了这么多，其实可以用一张图来概括本章的核心内容。我画了一个做市业务全链路监控的知识体系图，你看看就明白了。

这张图其实已经说得很清楚了。从上到下，业务层决定了你要监控什么，监控范围决定了你要覆盖哪些环节，难点决定了你的技术选型，最终目标就是实现一个低损耗、高可用的监控系统。

一个小建议：

刚开始搭建监控系统时，不要追求大而全。先抓住最核心的3~5个指标，比如订单延迟、成交率、敞口暴露。把这些指标监控好了，再逐步扩展。我见过太多团队一开始就想把所有指标都监控起来，结果系统复杂度爆炸，最后什么都没做好。

好了，第一章的内容就到这里。做市业务的全貌和监控挑战，你应该已经有了一个清晰的认识。下一章我们会深入具体的监控指标设计，聊聊哪些指标真正有用，哪些只是看起来好看。