从 SkyWalking 迁到 DataBuff，除了直接改 Agent 地址，还可以用 databuff-proxy 双写：Agent 只改一次指向 proxy，同时写 OAP 与 DataBuff，验证通过后再切走 SkyWalking。本文是双写压测与稳定性结论；迁移步骤见 从 SkyWalking 迁移。
测试环境与写入 Demo
| 项 | 说明 |
|---|---|
| 拓扑 | Agent（145）→ proxy（120） → SkyWalking OAP（114）+ DataBuff Ingest（113） |
| Proxy | databuff-proxy · listen :11800 · workers=8 · queue_size=4096 |
| 写入 Demo | 微服务调用链：17 个业务服务，各 2 副本 |
| 中间件 | Redis、MySQL、MongoDB、Kafka 等 9 个 |
| Pod 合计 | 共 43 个 · 写入压力 QPS=35 |
| 口径 | 看 proxy 进程占用核数（非整机 %）· span/s ≠ segment/s |
业务写入 TPS
35
两侧相同压力
DataBuff 入库
1.13万
span/s
同 QPS 定稿实测
SkyWalking 入库
5.81k
segment/s
同 QPS 定稿实测
每路转发
5838
次/秒 · 双路对称 · 错误/丢弃 = 0
Proxy 占用
0.89
核（不到 1 核）· 内存 ~47 MB
Proxy 主机
CPU
16 vCPU
内存
64 GiB
| 场景 | 占用核数 | 内存 | 对比 |
|---|---|---|---|
| 满载持续转发 | ~0.86 核 | ~44 MB | 不到 1 核 |
| 过夜连续跑 10 小时+ | 0.89 核 | ~47 MB | 不到 1 核 · 内存不涨 |
数字是 proxy 进程占用几个核，不是整机 CPU 使用率。
近 6 小时监控截图
进程 CPU · 约 5% ≈ 0.8 核 / 16 核机 · 几乎拉平
进程 RSS · 约 47–60 MB · 不涨
主机接收流量 · 持续有流、曲线平稳
主机输出流量 · 持续有流、曲线平稳
CPU / 内存来自进程详情；网络来自同机 host120（进程页无网络指标）。
异常场景
| 场景 | 怎么测 | 表现 | 对比 |
|---|---|---|---|
| 一路后端挂掉 | DataBuff 端口不可用 | 坏的一路熔断；另一路继续写；proxy 不挂 | 正常 |
| 手动关一路写入 | 管理接口禁用 | 该路停写；另一路不受影响；再开可恢复 | 正常 |
| 高流量持续压 | QPS=35 连续灌入 | 两路不丢包、不报错 | 正常 |
| 长时间不停机 | 连续跑 10 小时+ | 仍在转发；内存不涨 | 正常 |
| 配置重启后恢复 | 改参后重启 proxy | 可拉起并继续双写 | 正常 |
结论
| 检查项 | 结果 |
|---|---|
| 资源持续稳定（不到 1 核 · 内存不涨） | 通过 |
| 异常场景表现正常 | 通过 |
可以正式使用：双写可靠，资源占用可控。迁移两种方案见文档；写入吞吐对比见 写入性能对比。
GitHub: https://github.com/databufflabs/databuff-proxy · 文档: proxy 双写稳定性 · 迁移: 从 SkyWalking 迁移