"我该部署在哪个地区"是搭 Solana 机器人的团队最常问的问题之一,而它通常在那些会改变答案的问题之前就被问出来了。
老实的版本是:★地区确实有影响,但远小于人们在它之后才去优化的那些东西。★
地区实际改变了什么
你的机器人的总耗时可以拆成几段,而部署位置只碰得到其中一部分:
你的机器人 → RPC 端点 ★地区影响这一段★
RPC → 验证节点网络 ★地区影响这一段★
被收录进区块 ★地区影响不到★
确认 ★地区影响不到★
在物理上靠近你的 RPC 端点,能缩短第一跳。靠近验证节点密集的地方,对第二跳有帮助。两者都改变不了出块方在交易到达之后如何给它排优先级。
★一个位于连接优良地区、却写死手续费且没有重试循环的机器人,会输给一个在地球另一端、但提交调好了的机器人。★ 地区是一个已经正确的配置之上的适度乘数,不是它的替代品。
去测,不要假设
关于地区的建议老化得很快,因为验证节点分布会变、服务商的容量也会变。这个测量只要一个下午,而且给出的答案是针对你的端点、你的策略、以及当前网络的。
// ★测你实际在做的事,不要测 ping 告诉你的事。★
async function measureRegion(endpoint: string, samples = 200) {
const conn = new Connection(endpoint);
const results = [];
for (let i = 0; i < samples; i++) {
const submitSlot = await conn.getSlot();
const sig = await sendRepresentativeTransaction(conn);
const landed = await waitForLanding(sig);
results.push(landed.slot - submitSlot);
await sleep(1000);
}
results.sort((a, b) => a - b);
return {
p50: results[Math.floor(results.length * 0.5)],
p90: results[Math.floor(results.length * 0.9)],
p99: results[Math.floor(results.length * 0.99)],
};
}
★有两个细节决定这次测量诚不诚实。★
测 slot 距离,不要测往返时间。 ping 告诉你的是网络路径。它不告诉你你的交易有没有赶上下一个区块 —— 而那是唯一决定竞速胜负的东西。
在拥堵时跑,不要在清闲时段跑。 ★那些在凌晨三点看起来一模一样的地区,在高负载下可能差得很明显★,而高负载正是你的结果被决定的时候。
如果你测完发现差距在提交而不在位置,免费领个 BoltTx key 改一行就能拿来对比。
多地区不是免费的
在多个地区运行听起来只是"覆盖更多"。它会引入单地区部署没有的问题。
★重复发送是其中最要命的那个。★
// ★两个地区,同一个机会,两笔交易。★
// 不同的 blockhash → 不同的签名 → 两笔都可能落块。
Solana 的防重放覆盖的是相同的签名。两个地区各自独立地构建同一笔交易,产出的是两笔不同的交易,而两笔都可能执行。对一笔 swap 来说,那意味着买了两次。
按稳健程度递增的几种修法:
一个地区决策,多个地区提交。 单一的决策路径,扇出到多个提交点,用同一份已签名字节。★相同的字节从任何地方发都是安全的 —— 一个签名最多被收录一次。★
同一时间只跑一个。 由一个地区运行策略,其余待命,并有明确的故障切换路径。推理简单,代价是待命的那份容量被闲置。
按市场分区。 每个地区拥有一组互不相交的市场,这样它们永远不会争同一个东西。
行不通的做法,是在两个地区独立跑同一个策略、然后指望它们不会撞上。 它们会撞,而且撞车会集中在波动期。
故障切换比地区更值得关注
对大多数团队来说,★可用性问题比延迟问题值钱。★
一个位于理论最优地区、却在波动的那天宕了两个小时的机器人,损失比一个位置不理想的机器人大得多。
// ★按健康状况选,不要轮询。★
const endpoints = [primary, secondary, tertiary];
async function submit(tx) {
for (const ep of endpoints) {
if (!health.isHealthy(ep)) continue;
try {
return await ep.sendRawTransaction(tx.serialize(), {
skipPreflight: true, maxRetries: 0,
});
} catch (e) {
health.recordFailure(ep);
}
}
throw new Error("所有端点都不健康");
}
★把同一笔已签名交易通过第二个端点重发是安全的★,因为签名完全相同。这让端点级故障切换比地区级简单得多:你没有重建任何东西,所以不存在重复执行的可能。
多区域到底要花多少钱
跨区数据传输。 跨区流量是要计费的,一个在地区之间流式传输更新的机器人,能累积出可观的费用。
状态同步。 仓位、冷却时间、已执行意图的记录都必须一致,而跨区一致性要么慢,要么复杂。
运维面。 部署、密钥、监控、事故响应全都按地区数量翻倍。★双地区部署不是两倍的工作量 —— 贵的是协调那部分。★
时钟偏差。 如果地区之间靠时间戳协调,微小的差异会产生排序 bug。要按 slot 协调,它是全网统一且无歧义的,不要按墙上时钟。
一个合理的顺序
对大多数团队来说,真正出结果的顺序是:
1. 调提交。 推导出来的手续费、重发到过期为止、skipPreflight、上链失败不做客户端退避。★免费,而且通常是单项最大的改善。★
2. 测你当前的地区。 拿到一个高负载下的 slot 距离分布。
3. 测一个备选。 同样的测量、同样的条件。比较分布,不要比较平均值。
4. 加故障切换。 多个端点、按健康状况选择、发送相同字节。
5. 再考虑多地区。 只有当测量显示出值得那份运维成本的差异时。
★大多数团队在第 1 步就找到了答案。★ 真正需要走到第 5 步的机器人,是那些已经把第 1 到 4 步榨干了的。
上链应该是什么水平
我们投递节点上的真实交易:中位确认 336 毫秒 —— 不到一个 slot。
★这是你做地区对比时该拿来参照的数字。★ 如果你当前的配置明显比它更宽,那差距更可能在提交上,而不在地理位置上。
BoltTx 在这里的位置
我们在四个地区运行投递节点,所以路由这个问题是在我们这一侧处理的,不是你那一侧。
提交带 SWQoS 路由、不暴露公共 mempool —— 交易在落块之前、传输途中观察不到。你的机器人指向一个端点,多地区行为发生在它背后 —— 没有重复发送的问题,也没有跨区状态要同步。
你在本地签名。我们不托管资金、不代签、不修改交易内容。tip 带在交易里、从你自己的钱包链上支付,交易失败时跟着一起 revert —— 这是 Solana 原子交易的机制决定的。只有到达链上的交易才计费。
免费领 API key,没有月费:
const connection = new Connection("https://la.bolttx.io/?api-key=YOUR_KEY");
常见问题
Solana 交易机器人该放在哪里? 去测,不要假设。关于地区的建议老化得很快,答案取决于你的端点和策略。一个在平庸地区调好了提交的机器人,胜过一个在理想地区没调的。
服务器位置会影响 Solana 交易速度吗? 它影响到你端点的那几跳、以及往验证节点去的那一段,但不影响出块方在交易到达之后怎么给它排优先级。这限制了单靠地理位置能做到的上限。
怎么正确地测量地区延迟? 用有代表性的交易,在拥堵期记录"提交到落块"的 slot 距离分布。ping 测的是网络路径,不是你有没有赶上下一个区块。
我该在多个地区跑机器人吗? 只有在调完提交、并且测出了值得这份成本的差异之后。多地区会带来重复发送风险、跨区状态,以及翻倍的运维面。
怎么避免两个地区重复执行? 让一个地区决策,把同一份已签名字节扇出到多个提交点。相同字节到哪里发都安全,而各自独立构建的交易签名不同,两笔都可能落块。
从多个端点发同一笔交易安全吗? 安全,前提是字节完全相同。一个签名最多被收录一次,这正是端点故障切换比重建简单得多的原因。
地区和故障切换哪个更重要? 对大多数团队是故障切换。一个在波动期宕了几小时的机器人,损失大于一个位置不理想的,而宕机是比小幅延迟差异更大也更常见的失败。
怎么实现端点故障切换? 在一个有序列表上按健康状况选择,失败时重发相同字节,并按端点记录失败。轮询会把流量发给已知正在故障的端点。
拥堵时地区差异会更大吗? 一般会,这正是清闲时段的测量有误导性的原因。在低负载下看起来一样的地区,在决定你结果的那些条件下可能分化。
多地区部署有哪些隐藏成本? 跨区数据传输、状态同步的复杂度,以及按地区数量翻倍的运维面。协调那部分通常比基础设施本身更贵。
地区之间该用时间戳协调吗? 不该,要用 slot 协调。slot 是全网统一且无歧义的,而地区间的时钟偏差会产生难以复现的排序 bug。
和验证节点同机房有用吗? 只对它缩短的那一跳有用,而且改变不了收录优先级。它同时是一项不小的运维承诺,而实测常常显示收益并不大。
延迟差多少才值得搬迁? 要大到能改变你的 slot 分布,而不是改变你的毫秒平均值。 如果 p90 slot 距离没变,那网络路径的改善并没有传导到你真正在乎的结果上。
不部署过去能测试一个地区吗? 能测一部分,在那个地区开一台虚机跑你的测量脚本。完全复制不了的是你的生产负载模式 —— 而那正是尾部行为产生差异的原因。
考虑地区之前该先修什么?
把写死的手续费改成推导的、重发到 blockhash 过期为止、skipPreflight,以及上链失败时不做客户端退避。这些都免费,而且通常比地区的影响更大。
一个机器人该配几个端点? 至少两个,最好三个,按健康状况选择。目标是扛住单个服务商的劣化,而这比地区级的网络问题常见得多。
延伸阅读
- Solana 交易延迟该测什么
- Solana 交易机器人的 RPC 配置
- Solana 交易机器人的监控
- Solana 私有 RPC 详解
- Solana 交易上链完全指南