# 影子采集器部署

在第二台机器上跑一套完全相同的采集，用来看不同地理位置的数据差异。

## 为什么要跨地采集

滑点里最大的一项是**延迟漂移**：从 K 线收盘到实际下单之间，价格已经走掉的
那部分。而延迟 = 交易所出包 + 网络传输 + 本地处理。本机（新加坡）实测到达
延迟中位 350~650ms，其中网络传输占多少、换个机房能压掉多少，只有实测。

延迟压下来直接等于滑点下降，所以机房选址是个可优化参数，不是固定成本。

## 三个必须一致，一个必须不同

必须一致，否则差异分不清是地理位置还是环境造成的：

- **代码版本**（`git_commit`）——同一个 commit
- **镜像摘要**（`image_digest`）——同一个 hummingbot 镜像
- **时钟**——两台都同步到 NTP，偏移都在 10ms 内

必须不同：

- **`SHADOW_SITE`**——写进每一行数据，是合并后区分来源的唯一依据

`start.sh` 会把这四项连同内核、核数、内存一起写进
`research/out/run_meta_<site>.json`。两地数据对不上时先看这个文件。

## 时钟为什么是硬门槛

所有延迟数字都是「本地时钟 − 交易所 K 线收盘时间戳」。时钟偏 50ms，全部
延迟就同向偏 50ms，而且**不会有任何报错**——只会让跨地对比得出一个干净、
自信、且完全错误的结论。所以 `start.sh` 在时钟未同步或偏移超阈值时直接
拒绝启动，而不是打个警告了事。

## 步骤

在新机器上：

```bash
git clone ssh://jack@git.jackyu66.com:2222/jack/chan.git
cd chan && git checkout chan

bash research/live/deploy/setup.sh          # 装 docker + chrony，拉镜像
SHADOW_SITE=aws-tokyo bash research/live/deploy/start.sh
```

确认健康：

```bash
bash research/live/deploy/status.sh
```

启动日志里应当看到：

```
[补丁] 覆盖生效：基类取首元素 … 本地取末元素 …
成交流已挂 ['BTC', 'ETH', 'SOL']
就绪 3.0s · 1m [2001, 2001, 2001] 根 · 5m [801, 801, 801] 根
```

第一行尤其重要。上游 Bitget 连接器的换根解析有 bug（只取多根消息的首元素），
补丁把它修掉拿回约 1.06 秒。补丁若失效是静默的——不崩不报错，只是延迟悄悄
退回 1.4 秒，所以启动时做了断言。

## 对比

把两站的 `research/out/` 收到一处（同名文件会覆盖，所以分目录放）：

```bash
mkdir -p collected/sg collected/aws
rsync -av sg-box:chan/research/out/   collected/sg/
rsync -av aws-box:chan/research/out/  collected/aws/

python research/live/compare_sites.py \
  --glob 'collected/*/shadow_latency.csv' \
  --drift-glob 'collected/*/shadow_drift.csv' \
  --meta-dir collected/sg --meta-dir collected/aws
```

对比脚本做两件事值得说明：

- **只取各站都有的 K 线**做配对比较。不取交集就可能在比不同时段，而延迟对
  市场活跃度敏感。
- 报**配对差的符号占比**而不只是两个中位数相减。同根配对消掉了市场状态，
  「A 比 B 慢的根占多少」比「两个中位数差多少」更能说明有无系统性差异。

判读上有一条自检：**同一个固定延迟点上，两站的漂移应当几乎相同**——漂移是
市场性质，与机器位置无关。若漂移也差很多，先怀疑时钟或时段没对齐，而不是
急着下结论。

## 资源占用

本机实测：内存约 1.5GB（两个计算进程 + 盘口缓冲），CPU 单核不满。
盘口与成交流落盘约 15MB/天（gzip）。一周 168 小时的量级在百 MB 内。

`--workers 2` 是因为信号计算走独立进程池、不能阻塞事件循环。核数少的机型
可以给 1，但要看心跳里的 `compute_ms`：若接近 60 秒就会开始堆积。