D8 零基础速成笔记

你在交易所页面点一下"买入"，这张订单会依次经过七八个服务。每个服务只干一件事。今天后面每一节，都是在放大这张图里的某一个框。

先按顺序认识一遍，每个只记一句话：

• 网关：所有请求的大门。检查你是谁（签名、登录态），限制你每秒能发多少请求（D3 讲过的限频就在这里）。
• 下单服务：把请求整理成一张标准订单，检查价格和数量的格式（D2 讲的 tickSize、lotSize）。
• 下单前风控：钱够不够、价格离谱不离谱、有没有超过持仓上限。不过关就直接拒绝，订单不会进订单簿。钱够的话，这一步会把下单要用的钱先"冻结"起来（第 2 节）。
• 定序：同一个交易对（比如 BTCUSDT）的所有订单，在这里排成一队，每张编上一个连续的号。后面按号码顺序处理（第 4 节）。
• 撮合引擎：按顺序拿订单，和订单簿里已有的单子配对成交（第 3 节）。它只负责"谁和谁成交、成交多少、什么价格"，不直接改任何人的余额。
• 清算：拿到撮合的成交结果，算清楚每个人该加多少、该减多少、手续费多少，写成一条条账。
• 账户服务：真正改余额的地方。你看到的"可用""冻结"两个数字都存在这里。
• 行情推送：把成交和订单簿的变化推给所有人。D3 里你订阅的成交流和盘口增量，就是从这里出来的。

 user / bot
    |  REST / WebSocket
    v
 +---------+    +-----------+    +-----------+    +-----------+
 | gateway |--->| order svc |--->| pre-trade |--->| sequencer |
 +---------+    +-----------+    | risk      |    +-----+-----+
                                 +-----------+          |
                                                        v
 +-------------+    +----------+    +------------------------+
 | account svc |<---| clearing |<---| matching engine        |
 | avail/frozen|    | (ledger) |    | (in-memory order book) |
 +-------------+    +----------+    +-----------+------------+
                                                | trades / book changes
                                                v
                                    +------------------------+
                                    | market data push       |---> D3 里你订阅的行情
                                    +------------------------+

图里的英文：user / bot = 用户或机器人；gateway = 网关；order svc = 下单服务；pre-trade risk = 下单前风控；sequencer = 定序；matching engine = 撮合引擎；in-memory order book = 放在内存里的订单簿；clearing (ledger) = 清算（记账）；account svc = 账户服务；avail / frozen = 可用 / 冻结；trades / book changes = 成交和订单簿变化；market data push = 行情推送。
这张图说明：撮合只管配对，改余额的是清算和账户服务，两件事分开做。

你账户里的每一种币，都分成两个数：可用和冻结。下单时先把要花的钱冻结起来，成交时从冻结里扣，撤单时把没用上的解冻还给可用。

成交那一刻，清算会同时记几条账：你 −300 U（从冻结扣）、+0.005 BTC；卖方 −0.005 BTC、+300 U；如果有手续费，再记一条"手续费账户 +多少"。同一种币，所有人加起来的变化一定是 0。这种"每笔钱都有来处和去处"的记法，会计上叫复式记账。对账时查的就是它：哪种币加起来不是 0，就说明哪里记错了。

import java.math.BigDecimal;

/** 一个用户的一种币。真实系统里这是数据库的一行，更新要加版本号或放进单线程处理 */
public class AssetBalance {
    private BigDecimal available = new BigDecimal("0");
    private BigDecimal frozen    = new BigDecimal("0");

    /** 下单：可用 → 冻结。钱不够就拒绝 */
    public void freeze(BigDecimal amt) {
        if (available.compareTo(amt) < 0) throw new IllegalStateException("insufficient");
        available = available.subtract(amt);
        frozen    = frozen.add(amt);
    }
    /** 成交：从冻结里扣掉真正花掉的钱 */
    public void deductFrozen(BigDecimal amt) { frozen = frozen.subtract(amt); }
    /** 撤单，或实际成交比限价便宜时退差价：冻结 → 可用 */
    public void unfreeze(BigDecimal amt) {
        frozen    = frozen.subtract(amt);
        available = available.add(amt);
    }
}

三个方法对应演示里的三种变化。金额一律用字符串构造 BigDecimal（D2 讲过为什么不能用 double）。英文：insufficient = 余额不足。

一张买单进来，撮合引擎只按两条规则找对手：先找价格最好的卖单；价格一样，找最早挂上去的那张。成交价用挂在簿上的那张单的价格。

总页 D8 的编程题 match 就是让你把这套规则写出来：输入订单簿和一张新订单，返回成交列表和"剩下挂上簿的那一截"。它返回的每一笔成交带三个字段：挂单编号、成交价、成交数量，和下面 Java 代码里的 MatchFill 一一对应。

import java.math.BigDecimal;
import java.util.*;

/** 挂在簿上的单。remaining 会随成交减少，所以用普通类，不用 record */
final class Resting {
    final String id; final BigDecimal price; final long ts;
    BigDecimal remaining;
    Resting(String id, BigDecimal price, BigDecimal qty, long ts) {
        this.id = id; this.price = price; this.remaining = qty; this.ts = ts;
    }
}

/** 撮合引擎内部产生的一笔成交：和哪张挂单、什么价、多少 */
record MatchFill(String makerId, BigDecimal price, BigDecimal qty) {}

public class SimpleBook {
    // 卖单：价格从低到高，每个价位一个先进先出队列
    private final TreeMap<BigDecimal, ArrayDeque<Resting>> asks = new TreeMap<>();
    // 买单：价格从高到低
    private final TreeMap<BigDecimal, ArrayDeque<Resting>> bids = new TreeMap<>(Comparator.reverseOrder());

    /** 限价买单进来（卖单方向对称，这里省略） */
    public List<MatchFill> buyLimit(String id, BigDecimal limit, BigDecimal qty, long ts) {
        List<MatchFill> fills = new ArrayList<>();
        BigDecimal left = qty;
        while (left.signum() > 0 && !asks.isEmpty()) {
            Map.Entry<BigDecimal, ArrayDeque<Resting>> best = asks.firstEntry(); // 价格优先：最便宜的一档
            if (best.getKey().compareTo(limit) > 0) break;                    // 比我的限价贵，不吃
            ArrayDeque<Resting> queue = best.getValue();
            Resting maker = queue.peekFirst();                                 // 时间优先：最早挂的
            BigDecimal q = left.min(maker.remaining);
            fills.add(new MatchFill(maker.id, maker.price, q));                // 成交价 = 挂单的价格
            left = left.subtract(q);
            maker.remaining = maker.remaining.subtract(q);
            if (maker.remaining.signum() == 0) queue.pollFirst();              // 这张挂单吃完了
            if (queue.isEmpty()) asks.pollFirstEntry();                        // 这一档空了
        }
        if (left.signum() > 0) {                                               // 没吃完：剩下的挂到买方
            bids.computeIfAbsent(limit, k -> new ArrayDeque<>()).addLast(new Resting(id, limit, left, ts));
        }
        return fills;
    }
}

Resting = 挂在簿上的单；remaining = 剩余数量；ts = 到达顺序（timestamp 的缩写，这里用序号代替时间）；MatchFill 的 makerId = 挂单编号。注意它和 D4 的 Fill 不是一回事：D4 的 Fill 是机器人收到的成交回报，MatchFill 是撮合引擎自己内部产生的。Side 沿用 D4 的 enum Side { BUY, SELL }。每个类型放一个单独的文件，和 D4 一样。

同一个交易对的撮合，常见做法是只用一个线程、订单簿整个放在内存里。这听起来很"不高并发"，但正是它又快又不出错的原因。

 orders ---> [ sequencer ] ---> seq 1,2,3,4 ... ---> append to event log   ← 先落日志
                                     |
                                     v
                          +-------------------------+
                          | matching engine BTCUSDT |   one thread, in memory
                          +-------------------------+
                          | matching engine ETHUSDT |   another thread
                          +-------------------------+
                                     |
                                     v  trades (with seq)
                          clearing / market data     ← 下游按序号消费

图里的英文：orders = 订单；sequencer = 定序；seq = 序号；append to event log = 追加写进事件日志；one thread, in memory = 一个线程、在内存里；another thread = 另一个线程；trades (with seq) = 带序号的成交结果；clearing / market data = 清算和行情。
这张图说明：一个交易对内部是单线程，不同交易对之间各跑各的，这样整体仍然能并行。

撮合引擎本身只会机械地配对。为了防止手滑、程序 bug 或者故意操纵，交易所会在撮合前后加几道闸。策略机器人最常被这几道闸拒单，所以你必须认识它们。

现货成交，是真的把币换到你账户里。合约成交，你账户里的币没变，多出来的是一条"仓位"记录和一笔被占住的保证金。后台因此多了一整套服务。

合约比现货多出来的几个服务，今天后面每节讲一个：

• 仓位服务：记每个人每个合约的仓位，成交后更新数量和开仓均价（第 8 节讲它有两种记法）。
• 资金费结算：每隔一个周期，按仓位给多空双方记一笔资金费（第 9 节）。
• 风险引擎：标记价格一变，就重算每个仓位还安不安全（第 10 节）。
• 强平引擎：风险引擎判定某个仓位不安全以后，由它接管这个仓位，去市场上平掉，亏穿了找保险基金，保险基金不够再触发自动减仓（ADL）。

 open long --> freeze margin --> match --> position svc: qty +, entry price
                                                |
   every funding period (e.g. 8h) --------------+--> funding settle: margin +/-
                                                |
   mark price svc --> risk engine: still safe? -+
                                                | no
                                                v
                        liquidation engine takes over --> insurance fund --> ADL

图里的英文：open long = 开多；freeze margin = 冻结保证金；match = 撮合；position svc = 仓位服务；qty + = 数量增加；entry price = 开仓均价；every funding period (e.g. 8h) = 每个资金费周期（比如 8 小时）；funding settle = 资金费结算；margin +/- = 保证金加或减；mark price svc = 标记价格服务；risk engine: still safe? = 风险引擎判断还安全吗；no = 不安全；liquidation engine takes over = 强平引擎接管；insurance fund = 保险基金；ADL = 自动减仓。
这就是"做完的标志"里要你画的第二条链路。

合约按"押金和盈亏用什么币算"分两种。押 U、赚亏也是 U，叫 U 本位；押 BTC、赚亏也是 BTC，叫币本位。D1–D7 讲的都是 U 本位。

同一个合约，你能不能同时拿着一个多仓和一个空仓？交易所给两种模式让你选：单向持仓只能有一个净仓位，双向持仓多仓和空仓分开记。

最容易写错的是"平多"：方向是卖，但 positionSide 仍然是 LONG，因为你操作的是多仓。写成 SHORT 就变成了开一个新空仓。

为什么策略的人要在乎：合约网格在双向模式下，可以把"低买"挂在多仓、"高卖"挂在空仓，两边独立；在单向模式下，所有买卖都在一个净仓位上加减。同一套策略，两种模式的下单参数完全不同。进组后第一件事，是问清楚你们的账户用哪种模式。

import java.math.BigDecimal;

public enum PositionSide { LONG, SHORT }

/** 双向持仓下的一个仓位。单向持仓只需要一个带正负号的 qty */
public record Position(String accountId, String symbol, PositionSide positionSide,
                       BigDecimal qty, BigDecimal entryPrice) {}

accountId = 账户编号；symbol = 交易对，比如 BTCUSDT；qty = 数量；entryPrice = 开仓均价。第 9 节的资金费结算会用到它。

D2 讲过资金费是多空之间定期转账。在交易所后台，它是一个定时批量任务：到点了，拿当时所有人的仓位，一个一个算钱、记账。难点不在公式，而在"几百万个仓位，跑到一半挂了怎么办"。

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.List;

/** 结算时刻那一瞬间的仓位，结算只用它 */
public record PositionSnapshot(String accountId, String symbol, PositionSide positionSide, BigDecimal qty) {}

public class FundingSettler {
    private final FundingLedger ledger;    // 资金费流水表，(periodId, accountId, symbol, positionSide) 唯一
    private final Accounts accounts;

    public FundingSettler(FundingLedger ledger, Accounts accounts) { this.ledger = ledger; this.accounts = accounts; }

    public void settle(String periodId, List<PositionSnapshot> snapshot, BigDecimal mark, BigDecimal rate) {
        for (PositionSnapshot p : snapshot) {
            BigDecimal fee = p.qty().multiply(mark).multiply(rate).setScale(8, RoundingMode.HALF_UP);
            // 费率为正：多付空。rate 为负时 fee 是负数，符号自动反过来
            BigDecimal amount = p.positionSide() == PositionSide.LONG ? fee.negate() : fee;
            // 同一个数据库事务：先插流水，插成功才改余额；唯一键冲突说明上次已经记过，跳过
            if (ledger.insertIfAbsent(periodId, p.accountId(), p.symbol(), p.positionSide(), amount)) {
                accounts.addMargin(p.accountId(), amount);
            }
        }
    }
}
interface FundingLedger { boolean insertIfAbsent(String periodId, String accountId, String symbol, PositionSide side, BigDecimal amount); }
interface Accounts { void addMargin(String accountId, BigDecimal amount); }

periodId = 结算周期编号，比如 "BTCUSDT-2026-10-06T08:00Z"；mark = 标记价格；rate = 资金费率；insertIfAbsent = 不存在才插入；addMargin = 给保证金加（或减）钱。仓位价值用标记价格算是常见做法，各家不同。

D2 教你算强平价，今天看交易所是怎么"执行"强平的：风险引擎盯着每个仓位，发现不安全就交给强平引擎，强平引擎接管仓位、去市场上平掉，亏穿了再找保险基金和自动减仓。

手续费不是一个固定数。交易越多费率越低，挂单比吃单便宜，顶级的挂单大户甚至是交易所倒贴钱给他。这一节是 D9 讲做市策略的铺垫。

现在把第 1 节的全景图再看一遍：网关限频、下单服务检查精度、下单前风控冻结钱、定序排队、撮合配对、清算按费率记账、账户服务改可用和冻结、行情推送广播出去。合约再多出仓位服务、资金费结算、风险引擎和强平引擎。这两条链路能在白纸上画出来，今天就过关了。

今天和前几天用到的词，这里都能查到。

自测 8 题