D7 零基础速成笔记

故障演练就是在出事之前，主动把系统弄坏一次，看它扛不扛得住。

把 D3 到 D6 做的东西连起来看，一共有六个地方最容易出事。下面的图里用数字标出来了，后面每一节讲一个。

 Exchange WS ──(4)──► [ GridBot ] ──► [ OrderGateway ] ──(3)──► Exchange
                                               │
 leader fill ──► leader.fills ──(1)(2)──► [ Fanout ] ──(5)──► copy.orders ──► [ OrderWorkers ]

 (6) any process may die between "order sent" and "event logged"

图里的名字都是前几天做过的东西：Exchange WS 是交易所推行情的 WebSocket 连接（D3）；GridBot 是你的网格机器人（D4）；OrderGateway 是负责把订单发给交易所的那一层（D4 项目骨架里的 order 目录）。下面一行是跟单（D6）：leader fill 是带单员的一笔成交，先进 leader.fills 这个 topic，Fanout 是扇出服务（D6 的 FanoutService），把它拆成每个跟单者一张订单放进 copy.orders，OrderWorkers 是真正去下单的消费者。括号里的数字对应下表。

把第 3–7 节的六种故障放在一起。选一种，勾上或去掉对应的防线，点"注入故障"看后果。

做法很简单：加一个开关类 Chaos（英文"混乱"），平时全部关掉；演练时打开某一个开关，看系统的反应。下面的类名和方法名沿用 D3–D6 笔记里的代码。

// 故障开关：演练时打开，平时全部为 0 / false
import java.util.Random;

public final class Chaos {
    public static volatile double DUPLICATE_RATE = 0.0;       // 重复发送消息的概率
    public static volatile double DROP_RATE = 0.0;            // 丢掉一条行情的概率
    public static volatile double LOST_ACK_RATE = 0.0;        // 下单成功但回复丢了的概率
    public static volatile boolean CRASH_AFTER_PLACE = false; // 下单之后、写日志之前直接死掉

    private static final Random R = new Random();
    public static boolean hit(double rate) { return R.nextDouble() < rate; }
}

// rec 是要发的那条 Kafka 消息，producer 是 D6 里的 KafkaProducer
void publish(ProducerRecord<String, String> rec) {
    producer.send(rec);
    if (Chaos.hit(Chaos.DUPLICATE_RATE)) producer.send(rec);   // 同一条再发一次
}

// D5 第 9 节的 PaperExchange（存文件的模拟交易所）：订单收下了，但故意抛超时
public Order place(Order o) throws TimeoutException {
    if (open.containsKey(o.clientOid()))                 // 编号已存在：像真交易所一样拒绝
        throw new IllegalStateException("DUPLICATE_CLIENT_OID");
    open.put(o.clientOid(), o);                          // 订单已经进了"交易所"
    save();                                              // 写 exchange.db
    if (Chaos.hit(Chaos.LOST_ACK_RATE))
        throw new TimeoutException("模拟：成功了，但回复丢了");
    return o;
}

// 调用方：就是 D5 第 4 节的 placeSafely，超时后用同一个编号先查
public Order placeSafely(Order o) throws Exception {
    try {
        return exchange.place(o);
    } catch (TimeoutException e) {
        Optional<Order> found = exchange.query(o.clientOid());
        if (found.isPresent()) return found.get();       // 已经有了：接管真实状态
        return exchange.place(o);                        // 确认没有：用同一个编号重下
    }
}

// D3 第 10 节处理增量的方法，在最前面加一行
void onDelta(Delta d) {
    if (Chaos.hit(Chaos.DROP_RATE)) return;             // 假装这条在网络上丢了
    // ……下面是 D3 原来的逻辑：先检查序列号，跳号就丢掉订单簿、重新拉快照
}

Order placed = exchange.place(o);
if (Chaos.CRASH_AFTER_PLACE) Runtime.getRuntime().halt(1);  // 不跑任何收尾代码，接近 kill -9
local.record("PLACED " + placed.clientOid());              // D5 的 LocalBook：先写日志，再改内存

演练是你主动去找问题，监控是让问题自己冒出来。系统持续记录几个关键数字，超过事先定好的阈值就发告警（发消息、打电话给值班的人）。

七天的成果最后落到一页纸上：这个系统会在哪 5 个地方出事，每个都写清现象、后果、防线和你亲手验证的证据。进组第一周，它就是你跟同事聊天的底稿。

故障名称：
  现象：    一句话，别人能听懂发生了什么
  后果：    带数字，比如"多下了 9 张单""多付了 0.6 U 手续费"
  防线：    用了什么机制，写在代码的哪里
  我的验证：开了哪个开关，看到了什么，对照实验是什么
  还没想明白：进组后要问的问题

写的时候直接写在 七日冲刺 D7 的总结框里，会自动保存在本机浏览器。

今天用到的词都在这里，包括前几天学过、今天又用到的。

自测 7 题