一、做市商系统概述

1.1 什么是做市商

做市商，说白了就是「双边报价商」。

我经常跟团队新人这么解释：你去菜市场买菜，有个摊主同时喊出「我2块钱收你的菜，3块钱卖给你」。这个摊主就是做市商。他赚的不是菜价涨跌的钱，而是买卖之间的差价。

在金融市场里，做市商扮演的就是这个角色。他们为某个交易品种（比如股票、期货、加密货币）同时挂出买入价和卖出价，保证市场随时有人接盘。你想想看，如果没有做市商，你想卖的时候没人买，想买的时候没人卖，这市场就转不动了。

1.2 做市商的核心盈利模式

很多人以为做市商靠预测行情赚钱，其实不是。他们的盈利逻辑很朴素——吃差价。

举个例子：

• 买一价（Bid）：100.00 元
• 卖一价（Ask）：100.02 元
• 价差（Spread）：0.02 元

每成交一个来回（先买后卖，或先卖后买），做市商就赚这0.02元。别小看这点差价，高频交易下，一天几万笔订单，利润相当可观。

我在项目中遇到过一种情况：有些新手做市商总想「赌方向」，结果一次大行情就把之前几个月的利润全亏回去了。记住，做市商的核心不是预测，而是赚取流动性溢价。

盈利模式可以归纳为三类：

盈利来源	说明	风险等级
买卖价差	低买高卖，赚取固定点差	低
返佣/手续费	交易所按成交量返还费用	极低
库存增值	持仓期间价格有利变动	中高

1.3 做市商系统的核心功能模块

一个完整的做市商系统，至少包含四个模块。我按重要性排个序：

1. 报价模块

这是做市商的脸面。报价模块负责实时计算并发送买卖价格。核心指标就两个：价差宽度和报价深度。

我个人习惯把报价策略拆成三层：

• 基准层：根据市场中间价确定报价锚点
• 调整层：根据库存、波动率、对手方行为动态调整
• 执行层：负责发送订单、管理订单生命周期

2. 风控模块

做市商死得快，往往不是策略不行，而是风控没做好。风控模块需要实时监控：

• 净头寸暴露（不能单边押注太多）
• 最大订单金额（防止被大单吃掉）
• 报价偏离度（防止报价异常）
• 资金利用率（保证金是否充足）

3. 订单管理模块

订单管理负责处理订单的整个生命周期：创建、提交、确认、撤销、成交。这里有个坑——订单状态一致性。

我曾经遇到过：订单在交易所显示已成交，但本地系统还显示「待成交」。结果又发了一笔对冲单，造成了双倍仓位。嗯，后来我们引入了订单状态机+重试机制，才彻底解决这个问题。

4. 清算模块

清算模块负责盘后对账、计算盈亏、生成报表。虽然不像交易模块那么实时，但一旦出错，后果很严重。

我见过最离谱的事：清算模块把手续费算反了，导致团队以为赚了钱，实际上亏了两个月。所以，清算模块一定要有独立对账机制。

1.4 系统架构演进史

做市商系统的架构演进，其实就是一部「性能与复杂度」的博弈史。我把它分成三个阶段：

第一阶段：单机架构（2010年前）

早期做市商系统很简单。一台服务器，跑一个进程，连上交易所API，搞定。

// 伪代码示例：单机做市商
while (true) {
    price = getMarketPrice()
    bid = price - spread / 2
    ask = price + spread / 2
    sendOrder(bid, ask)
    sleep(100ms)
}

优点：开发快，部署简单。
缺点：单点故障，性能瓶颈。一旦服务器宕机，全线停摆。

第二阶段：分层架构（2015年左右）

随着交易量增长，单机扛不住了。大家开始把系统拆成多层：

• 接入层：负责与交易所通信，处理网络协议
• 策略层：运行报价算法和风控逻辑
• 数据层：存储订单、成交、行情数据

这个阶段，我印象最深的是消息队列的引入。以前各模块直接调用，耦合严重。用了消息队列后，模块之间解耦，扩展性大大提升。

第三阶段：分布式架构（2020年至今）

现在的做市商系统，基本都是分布式、微服务化了。核心特点：

特性	说明
水平扩展	交易量大了，加机器就行
高可用	多机房部署，单机房挂了自动切换
低延迟	使用FPGA、RDMA等硬件加速
实时风控	风控规则下放到每个节点

本章知识体系总览

下面这张图，概括了做市商系统的核心知识结构。我建议你保存下来，后面每学一章，都可以回来对照看看。

这张图把本章的核心内容串起来了。从上往下看：做市商系统由四个模块支撑，架构在不断演进，盈利模式是最终目标。后面每一章，都会围绕这张图展开。

---