← Financial Cloud Cloud Cloud Club · AWS Re:cap

极点宏观|Financial Cloud Cloud · AWS Re:cap

AWS Re:cap 14: AWS 上交易平台的 Tick-to-Trade 延迟

讲者: AWS re:Invent 2025

场次: 14

场次
Summit Dev Lounge2026 Re:cap
01 把架构写成 Steering,引导 AI Agent
Summit Dev Lounge2026 Re:cap
02 Agent Harness 才是真正的工程护城河
Summit Dev Lounge2026 Re:cap
03 用白话询问可观测性数据
Summit Dev Lounge2026 Re:cap
04 以 Bedrock AgentCore 打造 Serverless AR 游戏
Summit Dev Lounge2026 Re:cap
05 AgentCore 上的多 Agent 量化回测
Summit Dev Lounge2026 Re:cap
06 三分钟用 Kiro 把博客变成幻灯片
Summit Dev Lounge2026 Re:cap
AWS Community Day Hong Kong 2025 Re:cap
02 使用 Terraform 实现 AWS 合规
AWS Community Day Hong Kong 2025 Re:cap
03 从初学者到构建者:一段精彩的 AWS 云之旅
AWS Community Day Hong Kong 2025 Re:cap
04 以团队为先:使用 Laravel 与 Bref 开展无服务器工程
AWS Community Day Hong Kong 2025 Re:cap
05 活动开幕式
AWS Community Day Hong Kong 2025 Re:cap
06 智能体到智能体:在 AWS 上构建可互操作的 AI
AWS Community Day Hong Kong 2025 Re:cap
07 利用另一类遥测数据,借助 AI 智能体更快改进
AWS Community Day Hong Kong 2025 Re:cap
08 告别氛围编程:使用 Kiro 进行规格驱动开发
AWS Community Day Hong Kong 2025 Re:cap
09 使用 MCP 与 AI 智能体进行自动化测试
AWS Community Day Hong Kong 2025 Re:cap
10 使用机器学习方法实现电信安全现代化
AWS Community Day Hong Kong 2025 Re:cap
11 重新思考生成式 AI 智能体:RAG 与 MCP
AWS Community Day Hong Kong 2025 Re:cap
12 使用 TAK 和 AWS 开展灾难与应急响应
AWS Community Day Hong Kong 2025 Re:cap
13 从测试视角重新思考无服务器应用程序工作流
AWS Community Day Hong Kong 2025 Re:cap
14 Practical AWS FinOps for Cloud Success
AWS Community Day Hong Kong 2025 Re:cap
15 基于 AWS 的 AI 驱动全球纯 Alpha 宏观交易:重塑风险调整后资产收益
AWS Community Day Hong Kong 2025 Re:cap
FSI Recap
01 现代交易生命周期:从交易到结算
FSI Recap
02 Goldman Sachs:通过 Fast Track 加速应用程序上云 - AWS Re:cap Q1/2023
FSI Recap
03 Zurich Insurance Group:在 AWS 上构建高效的日志管理解决方案
FSI Recap
04 FSI Meetup 2025 年第四季度 - Brex 数据库灾难恢复
FSI Recap
05 FSI Meetup 2025 Q4 - Graviton 迁移成功案例
FSI Recap
06 FSI Meetup 2025 Q4 - Stifel 现代数据平台
FSI Recap
07 FSI Meetup 2025 Q4 - PayPal 金融交易数据对账系统
FSI Recap
08 FSI Meetup 2025 Q4 - 规模化提升韧性
FSI Recap
09 最大限度提高 AI 推理成本效益:战略性采用 AWS GPU 实例
FSI Recap
10 高级智能体 AI 设计模式
FSI Recap
11 在 AWS 上构建全新的现代化应用
FSI Recap
AWS re:Invent 2025
01 Coinbase re:Invent 回顾 (IND3312)
AWS re:Invent 2025
02 利用 AI 和 AWS 构建未来交易平台
AWS re:Invent 2025
03 交易创新:Jefferies 基于 Amazon Bedrock 构建的 AI 助手 (IND3315)
AWS re:Invent 2025
04 FSI 如何通过 Agentic AI (GBL302) 彻底改变 HFT 分析
AWS re:Invent 2025
05 使用 Amazon Time Sync 改进分布式系统(采用 Nasdaq)
AWS re:Invent 2025
06 Amazon Aurora HA 和 DR 全球弹性设计模式 (DAT442)
AWS re:Invent 2025
07 构建智能体式 AI:Amazon Nova Act 与 Strands Agents 实践 (DEV327)
AWS re:Invent 2025
08 深入探讨 Amazon Aurora 及其创新 (DAT441)
AWS re:Invent 2025
09 深入探讨 Amazon S3(STG407)
AWS re:Invent 2025
10 Nasdaq:为全球金融服务构建弹性基础设施 (HMC327)
AWS re:Invent 2025
11 AWS Lambda 新功能 (CNS376)
AWS re:Invent 2025
12 使用 Kiro 进行规范驱动开发 (DEV314)
AWS re:Invent 2025
13 Amazon 的 FinOps:全球电商巨头的云成本管理经验 (AMZ308)
AWS re:Invent 2025
14 AWS 上交易平台的 Tick-to-Trade 延迟
AWS re:Invent 2025
政务数据
01 The AI Era: The Boundary Between Development and Design Is Disappearing
政务数据
02 端侧多模态 AI 与智慧城市实践
政务数据
03 大模型能力评测与 AI 项目落地方法论
政务数据
04 基于云代理的政府开发全链路受控自动化
政务数据
05 从多智能体看 Agent 时代软件新生态
政务数据
06 AI 驱动的宏观量化研究与智慧治理
政务数据
07 公共数据授权运营与智慧政务实践
政务数据
08 数据资产化落地实践:确权合规、工程治理与数字政府案例
政务数据
09 AI技术赋能心理健康公益:可信平台的治理、架构与实践
政务数据
Amarathon 2025 回顾
01 开发者的智能体架构设计路线图
Donnie Prakoso
02 Amazon Bedrock 数据自动化
Hafiz Syed Ashir Hassan
03 AgentCore 上的多智能体
Tan Xin
04 实践中构建智能体式 AI:Nova Act 与 Strands Agents
Haowen Huang
04 使用规格驱动开发,通过 Kiro 加速迁移项目
Sanchit Dilip Jain
06 从「匹配」到「理解」:由 AgentCore Memory 驱动的个性化 AI 搜索实践
Liu Cao
07 从观察到优化:从 LLM 可观测性迈向 AIOps,将实时洞察转化为智慧自动化
Jimmy Soh
08 部署 TEAM 并打造最佳工程团队
Yuji Oshima
09 五年来所谓无服务器数据库带来的五个惨痛教训
Renato Losio
14 如果 AI 替我工作会怎样:Q Developer CLI 与 Kiro 如何改变我的日常工作
Miguel Angel Muñoz
16 兼顾速度与警觉:Amazon Bedrock Agent 开发的安全要点
Brian Tarbox
26 在单张 H100 上运行 OSS LLM:更智能、更便宜、更快速
Adit Modi Adit Modi
28 现代统一元数据架构:打破数据孤岛的新方法
Shaofeng Shi
29 无服务器 MediaOps:使用 Amazon Web Services 上的 AI 自动化视频工作流
Luis Valdivia
30 通过大规模性能测试构建兼具效率与可靠性的架构
Luis Guirigay
31 通过开源连接世界:技术、社区与全球开发者关系的实践历程
Richard Lin
33 构建流式 Iceberg 表以进行实时物流分析
Fahad Shah
34 加速大规模机器人策略训练:基于 Kiro、Trainium 和 EKS 的自动化闭环架构
Junjie Tang
35 通过规格驱动开发,从 Vibe 走向可行方案
Ricardo Sueiras
36 让云成本分析更智能:使用 Strands 和 AgentCore 构建 FinOps 智能体
Xiaofei Li
37 使用 CNCF Kagent、K8sGPT 和 Nova Sonic 转型 K8s 对话式智能体 AIOps
Shaoyi Li

其中使用了 Disruptor、Aeron、FPGA、Verilog、VHDL、Linux 内核 PREEMPT_RT 补丁、YugabyteDB、Raft 共识协议、AWS 集群置放群组 (CPG)、FIX 协议、Liquidnet SmartDark 和 Barracuda 算法、5/20 EMA 交叉策略、Amazon Time Sync Service、硬件数据包时间戳、MiFID II、流式传输适配版 FIX (FAST) 以及简单二进制编码 (SBE)。

Coinbase:使用 Aeron Cluster 构建其高弹性、云原生的交易基础设施,以低延迟处理高交易量。

EDX Markets (EDXM):在其交易平台中利用 Aeron Cluster 实现容错和超低延迟。

IMMIX:采用 Aeron Cluster 构建高性能数字资产交易系统和序列器。

HSBC(汇丰银行):集成 Aeron 以增强其电子交易系统。

Man Group:在其低延迟外汇交易系统中使用 Aeron 来快速处理报价流。

SIX Interbank Clearing:已在其瑞士即时支付平台中部署 Aeron Cluster。

BLOX Markets:一家即将推出、面向零售投资者的美国股票交易平台,正在集成 Aeron。

Chicago Mercantile Exchange(芝加哥商品交易所,CME):赞助 Aeron 的开源开发,以用于内部消息传递。

Kepler Cheuvreux (Kcx):与 Adaptive 合作,基于 Aeron 构建事件驱动型股票交易平台。

DriveWealth:这家领先的经纪服务商使用 Aeron 实现交易架构现代化,并达到交易所级性能。

Talos:在其数字资产生态系统平台中使用 Aeron 传输协议,实现高性能交易和消息序列化。


买方与卖方

买方参与者:

● 机构投资者

● 数字资产基金

● 零售交易者

● 自营交易公司

● 为其投资组合购入数字资产

● 专注于策略开发、研究和交易执行以产生回报

卖方公司:

● 做市商和经纪商

● 促进交易执行和订单路由

数字资产交易所:

● 提供资产上市和交易的平台

● 与卖方公司共同构成核心交易基础设施

● 确保流动性、匹配订单并提供基本金融服务

● 主要通过费用和买卖价差创收


Tick-to-Trade 性能

● 高频、低延迟交易 (HFT) 正在中心化数字资产交易领域迅速兴起。

● 数十年来,HFT 一直是股票、大宗商品和外汇市场,以及包括期货在内的衍生品市场等金融市场基础设施的重要组成部分。

● 其核心作用是为市场参与者提供更高的流动性、更低的交易成本、价格效率和价格发现。

● HFT 平台的关键技术成功指标:延迟、抖动

● 在数字资产市场运营的 HFT 公司力求实现低两位数微秒级的 Tick-to-Trade 性能,以保持竞争力。

做市

● HFT 公司有义务在订单簿两侧向市场报价

● Bid(MM 买入,交易对手卖出)

● Ask(MM 卖出,交易对手买入)

MM 策略的核心功能:

● 获取价差(买入价与卖出价之间的差额)

● 管理风险并提供最佳(最快)执行

提供流动性的同时也承担临时库存风险:

● MM 需要执行极高数量的订单,以向市场提供流动性并从价差中获利。

● HFT 公司利用数字资产交易的多个交易所场所之间的暂时价格差异获利。

● 成功需要经过优化的执行和微秒级速度,因为延迟可能会使套利机会消失。


抖动在 HFT 中的重要性

可预测的执行:

● HFT 算法依赖一致且可预测的性能,以便在精确的时刻和价格执行交易。不可预测的延迟(高抖动)可能导致交易晚于预期执行,错过最佳价格点并可能造成损失。

套利机会:

● 抖动可能导致不同交易所之间的价格发现延迟,使仅存在数微秒的短暂套利机会消失。

风险管理:

● 一致的延迟有助于改善实时风险管理和监控。高抖动会引入变化,使系统在压力下的行为更难预测,也更难有效管理风险。

算法完整性:

● 设计为在特定时间范围内作出反应的算法可能会受到意外延迟干扰,从而可能导致非预期的交易结果。

最大限度减少抖动的技术

硬件优化:

● 对关键处理路径使用确定性硬件,例如现场可编程门阵列 (FPGA)。

● 采用专为低抖动性能设计的网络接口卡 (NIC)。

操作系统 (OS) 和内核调优:

● 使用实时操作系统 (RTOS) 或经过自定义调优的 Linux 内核(例如 PREEMPT-RT 补丁),以优先处理交易进程并最大限度减少非确定性中断。

● 实施将线程固定到专用 CPU 核心等技术,并最大限度减少上下文切换,以避免 CPU 缓存未命中和资源争用。

网络架构:

● 利用内核旁路技术将数据直接从网络硬件移至用户空间应用程序,避开通用、非确定性的 Linux 网络栈。

● 将服务器放置在交易所托管设施中,以最大限度缩短物理距离并减少网络路径变化。

软件设计:

● 使用高效的数据结构和设计模式(如 disruptor 模式)优化消息流并减少不必要的内存分配。

● 优化序列化/反序列化流程,以高效处理大量数据。


LMAX Exchange Disruptor 模式:

● 高性能、低延迟的线程间消息传递系统。

● 利用 Ring Buffer 高效传递事件/任务。

● 常用于高频交易 (HFT)。

核心概念及其工作原理:

Ring Buffer:

● 内存中固定大小的循环数组。

● 保存事件/消息。

生产者:

● 使用序列号申领缓冲区中的槽位。

● 写入数据并提交。

消费者(批处理程序):

● 处理缓冲区中的事件。

● 在依赖关系图中运行。

● 互相通知新数据。

机械同理心:

● 利用 CPU 缓存(L1、L2、L3)。

● 使数据保持连续且可预测。

● 减少代价高昂的内存读取。

无锁/无争用:

● 使用序列号和屏障代替锁。

● 防止线程相互阻塞。

避免伪共享:

● 填充数据以确保变量不共享缓存行。

● 避免不必要的缓存失效。

优化:

CPU 缓存使用:

● 利用 CPU 缓存(L1、L2、L3)。

● 使数据保持连续且可预测。

避免使用锁:

● 使用序列号和屏障代替锁。

● 防止线程相互阻塞。

避免伪共享:

● 填充数据以确保变量不共享缓存行。

在交易中的应用:

速度:

● 对微秒级延迟至关重要的 HFT 而言不可或缺。

吞吐量:

● 处理海量市场数据和订单流。

可扩展性:

● 允许复杂的处理流水线跨多个 CPU 核心扩展。

面向任务的流水线:

● 非常适合将订单处理分解为顺序执行、可并行化的任务。

优势:

低延迟:

● 实现阶段之间纳秒级的处理。

高吞吐量:

● 处理的事件数量显著多于传统的基于队列的系统。

可预测的性能:

● 避免锁和垃圾回收暂停带来的不可预测性。


现场可编程门阵列 (FPGA)

● 是一种灵活的集成电路 (IC)。

● 制造后仍可编程。

● 允许创建自定义数字电路。

● 提供硬件级定制。

● 适用于高性能计算、信号处理和快速原型设计。

● 不同于固定功能芯片。

● 使用可重构逻辑块、互连和内存。

● 并行实现各种功能。

● 支持硬件加速和低延迟性能。

● 非常适合电信、汽车 (ADAS)、航空航天和数据中心。

硬件描述语言 (HDL):

● 工程师使用 Verilog 或 VHDL。

● 描述所需的数字电路。

逻辑综合、布局与布线:

● 软件转换 HDL 代码。

● 创建配置文件(比特流)。

● 将设计映射到 FPGA 的内部资源。

可编程资源:

● 芯片包含查找表 (LUT)、触发器和多路复用器。

● 可编程互连。

● 允许构成任意数字电路。

并行处理:

● 操作在硬件上同时进行。

● 提供高吞吐量和低延迟。

● 非常适合复杂任务。


数字资产市场中的公平和平等访问:

● 确保所有参与者拥有相同的交易和信息访问机会。

● 在成熟市场(股票和衍生品)中,监管监督会执行严格的信息披露和平等访问要求。

技术实施:

● 通过最大限度减少延迟差异来实现。

● 确保所有参与者在规定容差(微秒到毫秒)内体验相似的响应时间。

● 支持可靠地参与价格发现、流动性提供和交易执行。

AWS 的贡献:

● 许多交易场所基于云平台构建,着眼于可扩展性,而不是精确的性能调优。

● 持续改进平台,以支持交易所和交易公司。

● 增强实现更高公平性和平等性的能力。

架构:

● 中心化数字资产交易所在 AWS 上优化基础设施,以实现低延迟性能。

● 使做市商 (MM) 每秒能够执行数千笔交易。

● AWS 提供计算放置和网络拓扑优化,以减少延迟和抖动。

● 参考架构描绘了典型 CEX 交易处理热路径,用于与 MM 进行延迟优化的访问。


交易接收和处理流程:

订单提交:

● 将订单提交至交易所网关 (Exchange Gateway)。

订单转发:

● 将订单转发至公平订单排序器 (Fair Order Sequencer)。

批处理和加时间戳:

● 排序器执行批处理,并将带时间戳的订单发送至撮合引擎。

执行确认:

● 撮合引擎发送执行确认。

市场数据更新:

● 市场数据更新被发送至分发服务器。

● 更新被发送至市场数据网关。

HFT 行情处理器:

● 市场数据被传送至 HFT 行情处理器。

● 行情处理器将市场数据发送至交易策略引擎。

交易策略引擎:

● 生成提供或获取流动性的信号。

● 信号被发送至订单管理系统 (OMS)。

订单管理系统 (OMS):

● OMS 发送订单并接收执行确认。

● 执行通知被传送至 OMS。

数据复制:

● 数据被复制到辅助可用区或 AWS 区域。

● 确保主可用区受损时仍可持续运行。

高可用性和灾难恢复:

● 不同交易场所采用的方法各不相同。

● 范围从同步故障转移到仅对订单层进行部分故障转移,以用于头寸管理和对账。


延迟优化方法:

● 跨这些层进行优化,以确保交易和实时工作负载实现尽可能低的端到端延迟。

关键延迟:

● Order-to-Ack 延迟:表示订单交易的整个流程。

● Tick-to-Order 延迟:衡量消费价格变化、将其转换为交易信号以及修改头寸的速度。

成功指标:

● 价格发现、策略和订单执行的延迟及抖动。

● 目标:低两位数微秒级的 Tick-to-Trade 性能。

优化类别:

网络:

● 来自底层网络的延迟。

● 包括 AWS 路由、实例放置和连接选择。

计算:

● 来自 Amazon EC2 实例类型的延迟。

● 包括实例选择、内核和 OS 调优,以及优化 Elastic Network Adapter (ENA) 性能。

应用程序:

● 来自业务逻辑和用户空间处理的延迟。

● 专注于高效流量处理、CPU/内存使用以及最大限度减少资源争用。

系统:

● 来自系统范围进程的延迟。

● 包括数据分发、计时服务和整体架构效率。


CEX 和 MM 热路径:

CEX 热路径:

● 专注于订单录入、在订单簿上执行和市场数据分发。

● 包括订单录入、余额检查、撮合、确认以及市场事件发布。

● 目标:提供最佳执行和定价体验,以吸引流动性。

MM 热路径:

● 专注于 Tick-to-Trade 延迟。

● 涉及接收市场数据、评估交易机会和下单。

● 目标:保持最新的市场视图并避免风险和机会成本。


做市商“热路径”:

● 技术系统中对延迟敏感的数据和执行路径。

● 针对速度和效率进行优化,以保持竞争优势并管理风险。

关键组件:

市场数据摄取:

● 快速接收和处理外部市场数据。

● 确定资产当前的公允价格。

定价和机会评估:

● 计算最优买入价和卖出价并确定交易量。

● 管理库存风险并最大限度减少方向性敞口。

订单录入和执行:

● 用于快速下达限价单的低延迟系统。

内部通信和余额检查:

● 内部系统之间的快速通信。

● 确保订单有效,并使公司的风险敞口处于可接受范围内。

对冲:

● 快速执行抵消交易以对冲头寸。

● 管理从客户交易中获得的库存。

市场事件分发:

● 及时发布内部市场事件和确认。

● 分发给相关内部系统和外部客户。


优化技术:

集群置放群组 (CPG):

● 用于缩短组件之间的物理网络距离。

● 将 CEX 和 MM 工作负载放置在 CPG 中,使实例集中放置在一个可用区的同一网络主干上。

优势:

● 与 CPG 外部的实例相比,P50 UDP 往返时间延迟平均降低 37%,P90 平均降低 39%。

延迟来源:

● 从网络延伸到实例内部,并经过网卡、内核、操作系统和应用程序层。


延迟优化的权衡:

● 使用集群置放群组 (CPG):

● 最大限度减少网络延迟。

● 与具备完整弹性的多可用区 (Multi-AZ) 架构不兼容。

将撮合引擎作为状态机:

● 通常建模为确定性状态机。

● 相同的输入事件序列会产生相同的可预测状态。

● 对保持 CEX 订单簿和金融系统的一致性至关重要。

● 核心执行为单线程,以避免非确定性并确保线性处理。

用于高可用性和可扩展性的分布式状态机:

● 跨多个实例实施,以实现高可用性和可扩展性。

● 跨多个节点复制逻辑,从而即使某些节点发生故障也能维持运行。

● 通过在多个副本之间分配工作负载来实现水平扩展。

● 通过健壮的共识协议(例如 Raft)保持一致性。

消息传递、一致性和低延迟:

● 将共识协议与消息传递协议结合,以实现最小延迟和一致性。

● 客户可以设计自定义消息传递层,也可以使用 Aeron 或 Chronicle 等成熟产品。

● [https://github.com/aeron-io/aeron](https://github.com/aeron-io/aeron)

● 针对低延迟、高吞吐量通信优化消息传递层。

● 以最小的延迟开销实现状态机输入的确定性复制。


Aeron:超低延迟消息传递中间件

超低延迟

● 微秒级延迟:旨在提供微秒范围的延迟,这对高频交易至关重要。

● 可预测的性能:确保在不同负载下保持一致的性能。

高吞吐量

● 每秒数百万条消息:能够可靠处理大量消息。

● 可扩展架构:支持扩展以满足大型交易系统的需求。

可靠性和弹性

● 24/7 可用性:专为持续运行而构建,并具备确保高可用性的功能。

● 容错:包括自动故障转移和恢复机制。

成本效益

● 开源:免费使用,降低许可成本。

● 高效利用资源:最大限度降低硬件和运营成本。

主要功能和组件

Aeron Transport:

● 核心功能:高性能、低延迟的消息传输。

● 协议:使用 UDP(单播和多播)以及进程间通信 (IPC)。

● 支持的 API:Java、C/C++ 和 .NET。

Aeron Archive:

● 用途:用于消息录制和重放的扩展。

● 功能:以完整消息速率将流持久化到磁盘,确保数据恢复,并使服务可以无消息丢失地无缝重新连接。

Aeron Cluster:

● 框架:用于构建容错的分布式服务。

● 共识算法:使用 Raft 算法。

● 功能:自动故障转移和强数据一致性,非常适合交易所和事务性工作流。

Agrona 与简单二进制编码 (SBE):

● Agrona:提供高性能数据结构。

● SBE:提供紧凑、低开销的二进制消息格式,以最大限度减小消息大小和 CPU 周期。

对交易公司的优势

超低延迟:

● 性能:在云环境中提供低于 100 微秒的延迟,在物理硬件上则低于 20 微秒。

● 对以下领域至关重要:高频交易。

高吞吐量:

● 容量:能够每秒可靠处理数百万条消息。

可靠性和弹性:

● 可用性:确保 24/7 可用。

● 功能:自动故障转移、即时恢复和健壮的数据丢失处理机制。

成本效益:

● 降低成本:降低硬件和运营成本,避免供应商锁定。

经验证的采用:

● 用户:全球主要金融机构和平台,包括 Coinbase、Man Group 和 SIX Interbank Clearing。

● 应用:为实时交易和支付系统提供支持。

Aeron 系统的主要组件:

Media Driver:

● 功能:管理缓冲区处理、网络 I/O 和数据传输的核心引擎。

● 部署:可以作为应用程序内的嵌入式线程运行,也可以作为单独进程运行。

● 优势:最大限度减少垃圾回收暂停等事件对延迟的影响。

Aeron Client:

● 接口:面向开发者的应用程序 API。

● 操作:客户端创建 Publication(用于发送消息)和 Subscription(用于接收消息)。

Channel 和 Stream:

● Channel:定义通信路径。

● Stream ID:用于在同一 channel 上复用不同逻辑消息流的整数标识符。

Log Buffer:

● 存储:消息写入一系列称为 log buffer 的内存映射文件。

● 设计:支持直接内存访问(堆外),绕过 JVM 垃圾回收,以实现可预测的低延迟访问。

真实应用案例

● Coinbase:使用 Aeron Cluster 构建其高弹性、云原生的交易基础设施,以低延迟处理高交易量。

● EDX Markets (EDXM):在其交易平台中利用 Aeron Cluster 实现容错和超低延迟。

● IMMIX:采用 Aeron Cluster 构建高性能数字资产交易系统和序列器。

● HSBC:集成 Aeron 以增强其电子交易系统。

● Man Group:在其低延迟外汇交易系统中使用 Aeron 快速处理报价流。

● SIX Interbank Clearing Ltd:为其瑞士即时支付平台部署了 Aeron 集群。

● BLOX Markets:一家即将推出、专注于零售投资者的美国股票交易平台,正在集成 Aeron 系统。

● Chicago Mercantile Exchange (CME):赞助了用于内部消息传递的 Aeron 开源开发项目。

● Kepler Cheverton (Kcx) 与 Adaptive 合作,构建了基于 Aeron 的事件驱动型股票交易平台。

● 经纪服务领导者 DriveWealth 采用 Aeron 重构其交易基础设施,实现交易所级性能。

● Talos 在其数字资产生态系统平台中利用 Aeron 传输协议,实现高性能交易和消息序列化处理。


消息流和机制

Publication:

● 方法:发布者客户端使用 offer() 方法将消息写入共享内存中的 log buffer。

● 操作:非阻塞;返回状态码,指示成功或是否施加了背压。

Media Driver 操作:

● 功能:持续读取发布者的 log buffer,并通过配置的 channel(UDP 或 IPC)将数据传输到适当的目标。

Subscription 和轮询:

● 方法:订阅者客户端调用 poll() 方法,从其关联的 log buffer 中读取消息。

● 模型:轮询模型让应用程序控制何时处理数据,通过避免中断驱动的回调来保持可预测的延迟。

可靠性:

● 层:Aeron 在 UDP 之上实现自己的可靠性层。

● 机制:检测消息丢失并使用否定确认 (NAK) 请求重传缺失的分片,以最小开销确保可靠、有序的传送。

无锁设计:

● 技术:所有内部操作均为无锁操作,使用 log buffer 中的原子尾部更新等技术。

● 优势:避免线程争用并最大限度提高吞吐量。


原子尾部更新

网络协议:

● 原子尾部更新对于高性能网络和数据库系统至关重要。

● 它们可以高效管理 ring buffer 或日志等数据结构。

● 以原子方式更新尾指针可确保并发交互不会导致数据损坏。

系统升级:

● 在某些 Linux 发行版(原子发行版)中,原子更新涉及在一个事务中升级整个 OS 映像。

● 仅当更新成功时,系统才会启动到新映像,从而确保完整性。

● 这是利用原子性原则的系统范围更新。


Raft 共识算法:

● 一种确保服务器就数据状态达成一致的分布式系统算法,通过领导者选举、日志复制和节点角色(Follower、Candidate、Leader)来强调易理解性。

● 领导者选举:如果未检测到 Leader,节点会从 Follower 转变为 Candidate,发起选举以选出新的 Leader。

● 日志复制:Leader 记录客户端请求并将其发送给 Follower。一旦多数节点确认,该条目即被提交,确保所有节点就操作顺序达成一致。

节点状态:

● Follower:接受来自 Leader 的命令和心跳。

● Candidate:在选举期间争取成为领导者。

● Leader:协调复制和客户端请求。

简化工作流:

● 启动:所有节点都以 Follower 身份启动,并设置随机选举超时。

● 选举:Follower 超时后成为 Candidate,递增任期并请求投票。

● 投票:如果 Follower 在当前任期内尚未投票,且 Candidate 的日志为最新,则投票给该 Candidate。

● Leader:获得多数票的 Candidate 成为 Leader 并发送心跳。

● 复制:客户端向 Leader 发送请求,Leader 记录请求并将其复制给 Follower。

● 提交:一旦多数 Follower 记录了该条目,Leader 就会提交该条目并将其应用于自己的状态机,同时指示 Follower 执行相同操作。

主要优势:

● 易理解性:与 Paxos 等较旧协议相比,更易于实现和理解。

● 强一致性:确保所有节点以相同顺序看到操作(线性一致性)。

● 容错:选出新的领导者以应对服务器故障。

应用:

● 数据库:CockroachDB、YugabyteDB。

● 集群管理器:HashiCorp Consul。

● 消息队列:使用 KRaft 的 Apache Kafka。


用于高可用性和灾难恢复的 Multi-AZ 部署:

● 共识和消息传递解决方案在单个可用区内提供高可用性,并跨多个可用区或区域提供灾难恢复。

● 通过将日志复制到辅助目标或持久存储层来实现。

● 使用 Amazon S3、Amazon FSx 等存储服务,以及 Amazon Aurora 和 Amazon Aurora DSQL 等分布式数据库。

● Raft 日志复制模式各不相同:完全同步、近同步或异步。

● 复制的数据包含完整的系统交互历史记录,因此可用于审计和合规。

CPG 和 Amazon EC2 容量供给注意事项:

● 使用 CPG 优化放置并将 EC2 实例置于同一位置。

● 管理与容量供给之间的权衡。

● CPG 会在单个可用区网络主干下创建一个有效的部署边界,从而减少可用的 Amazon EC2 容量池。

● 影响因可用区大小而异:在大型区域和可用区中有所缓解,在较小的区域和可用区中则更明显。

● 使用 On-Demand Capacity Reservations 预留 Amazon EC2 容量来管理风险。

● 优势包括通过共享 CPG 降低延迟并提高容量保障。


CEX 和 MM 网络边界延迟:

● 对于寻求与数字资产交易所低延迟共置部署的 HFT 至关重要。

● 客户无法控制这些边界;延迟和抖动取决于放置和网络设计。

用于延迟优化的 CPG:

● 集群置放群组 (CPG) 是延迟优化放置的基础。

● 共享 CPG 将共置部署扩展到不同 AWS 账户。

● 符合区域内云端共置部署的原则。

连接模式:

● 数字资产交易所提供各种连接模式,其延迟特征范围从 50–200 微秒到超过一毫秒。

最优连接:

● HFT 客户力求获得通往交易所的最低延迟路径,避开 CDN 和负载均衡器。

● 理想情况下,通过 VPC 对等连接,使用公有或私有 IP 直接与 EC2 订单网关上的交易所端点交互。

● 优化协议选择,优先使用 FIX 而不是 REST 或 WebSockets,以最大限度减少协议导致的延迟。

延迟监控:

● HFT 使用分层测试监控到 CEX 端点的延迟:

● 基本 HTTP/TCP ping。

● 端到端延迟。

● 对市场事件和订单执行进行应用程序级监控。

● 持续优化放置,在延迟、可用性和实例选择之间取得平衡,因为 CEX 端点和 HFT 实例可能会在一个可用区内移动。


金融信息交换 (Financial Information eXchange, FIX) 协议

核心概念和机制

● 结构化消息:FIX 协议使用标签-值对格式来构造结构化消息。

● 标签-值对:每个数据字段由一个唯一整数标签和与之配对的值标识。

关键操作层:

● 会话层:管理双方之间的连接,使用心跳和间隙填充等机制,确保可靠的消息传送、排序以及从中断中恢复。

● 应用层:定义业务相关消息的内容,例如新订单、执行报告、订单取消和交易分配。

广泛采用和用例

● 起源:最初于 1992 年开发,用于 Salomon Brothers 与 Fidelity Investments 之间的美国股票交易。

● 支持的资产类别:已扩展为支持几乎所有资产类别,包括固定收益、外汇 (FX)、衍生品、大宗商品以及数字资产/加密货币。

主要用例:

● 订单路由和执行:在市场参与者之间无缝传输订单和执行报告。

● 市场数据分发:分发实时报价、交易量和市场深度信息。

● 交易后处理:处理交易分配、确认和结算详情,简化后台运营和监管报告。

● 算法交易和高频交易 (HFT):结构化、低延迟的特性使其非常适合自动交易策略,而简单二进制编码 (SBE) 和流式传输适配版 FIX (FAST) 等优化的二进制编码可满足极致性能需求。

FIX 协议的工作原理

● 基于消息的标准:围绕一系列标签-值对构建,以实现互操作性和高效率。

消息结构:标签-值对:

● 整数标签:FIX 消息中的每一项数据都由整数标签表示。

● 等号:后跟一个等号。

● 数据值:然后是数据值(例如,35=D 表示单笔新订单,即 New Order Single)。

FIX 消息的组成部分:

● Header:包含 BeginString、MsgType、SenderCompID 和 TargetCompID 等会话级字段。

● Body:包含 Symbol、OrderQty、Price 和 Side 等核心应用级业务数据。

● Trailer:包含用于验证消息完整性的 CheckSum。

操作层

会话层:

● 管理两个交易对手之间可靠且持续的连接。

关键机制:

● 心跳:定期发送消息以确认连接仍然有效。

● 序列号:每条消息都有唯一、递增的编号,用于检测缺失消息。

● 重发请求:如果检测到序列间隙,接收方可以请求对缺失消息进行“间隙填充”。

应用层:

● 定义消息的实际业务内容。

● 规定有效的订单类型、执行报告、交易确认和市场数据请求。

示例:单笔新订单 (New Order - Single, 35=D)

● 以 $150.00 买入 100 股 Apple (AAPL)。

● 8=FIX.4.2|9=100|35=D|34=10|49=BUYER|56=SELLER|52=20251211-10:00:00.000|11=ORD1001|21=1|38=100|40=2|54=1|55=AAPL|44=150.00|10=000|

● 8=FIX.4.2:FIX 版本(例如 4.2)。

● 9=100:Body Length(消息正文中的字符数)。

● 35=D:Message Type(D = New Order - Single)。

● 34=10:Sequence Number(会话中的第 10 条消息)。

● 49=BUYER:Sender ID(您的公司)。

● 56=SELLER:Target ID(经纪商/交易所)。

● 52=20251211-10:00:00.000:时间戳。

● 11=ORD1001:ClOrdID(客户端订单 ID)。

● 21=1:HandlInst(1 = 自动执行、私有、无经纪商干预)。

● 38=100:OrderQty(数量:100 股)。

● 40=2:OrdType(2 = 限价单)。

● 54=1:Side(1 = 买入)。

● 55=AAPL:Symbol(Apple Inc.)。

● 44=150.00:Price(限价:$150.00)。

● 10=000:Checksum(用于消息完整性)。


简单二进制编码 (Simple Binary Encoding, SBE)

● 一种专门的开放标准二进制协议,广泛用于电子交易和高频交易 (HFT) 环境。

● 为关键任务交易消息实现极高的处理速度和可预测(确定性)的延迟。

交易为何使用 SBE

● 在交易中,每一微秒都至关重要。

● XML 或 JSON 等传统数据格式速度太慢且过于臃肿。

● SBE 由 FIX Trading Community 开发,旨在满足对编码和解码过程中最大限度提高 CPU 效率并最大限度降低延迟的协议需求。

● SBE 优化了从订单创建到抵达交易所这一过程中的交易消息路径。

关键原则

固定偏移二进制布局

● SBE 的核心概念。

● 为交易消息中的每个字段分配精确的内存位置(偏移)。

● 对交易的影响:直接内存访问避免复杂的解析逻辑,缩短处理时间并使延迟高度可预测。

CPU 优化(缓存友好)

● 设计为对现代计算机处理器“缓存友好”。

● 对交易的影响:固定偏移设计最大限度减少条件分支,使 CPU 的内部预测机制可以有效工作。

简洁性和代码生成

● 使用结构化、机器可读的 XML schema 定义消息布局。

● 工具自动生成必要的代码(Java、C++、C# 等),以读取和写入这些特定交易消息。

● 对交易的影响:代码生成消除了人为错误,并确保发送方和接收方以完全相同、高效的方式解释二进制数据。

交易中的 SBE 与 FAST 对比

SBE(订单录入)

● 通常是向交易所发送实际订单的首选。

● 无状态特性和确定性延迟使其非常适合关键的点对点订单提交通信。

FAST(市场数据)

● 主要用于接收市场数据(价格、报价)。

● 其优势是大幅压缩重复数据流(增量编码),非常适合高效广播数百万次价格更新。


流式传输适配版 FIX (FIX Adapted for Streaming, FAST)

● 在交易环境中主要用于市场数据分发,通常不用于发送交易订单(订单录入)。

目的和用例

● FAST 由 FIX Trading Community 专门设计,旨在优化从交易所传输到交易公司的大容量实时市场数据馈送。

● 大容量数据:交易所每秒生成数百万次价格更新、报价和市场深度消息。以传统的文本 FIX 格式发送这些内容会消耗过多带宽并导致延迟。

● 压缩效率:FAST 作为强大的压缩算法,通过消除重复数据并使用基于模板的系统,显著缩小这些消息。

● 分发(扇出):它针对一对多通信(一个交易所向许多订阅者发送数据)进行了高度优化,因此非常适合交易运营的“市场数据”端。

FAST 如何处理交易数据

● FAST 使用一种“有状态”方法,接收方会记住一个会话中先前消息的值。

● 类比:如果订单簿更新时仅特定股票的价格发生变化,而货币、交易所和时间保持不变,则 FAST 只发送新的价格值。

● 优势:这会大幅减少带宽使用和整体网络延迟,确保交易者尽快收到价格更新,以便作出明智决策。

FAST 与订单录入(SBE 为何不同)

● 虽然 FAST 优化了数据接收,但它通常不是发送交易订单(订单录入)的主要协议。

● 订单录入要求可预测性:发送交易订单是一种点对点、高度关键的交互,其中确定性延迟至关重要。接收交易所需要每个订单完整且可立即解析,而不能依赖前一条消息的状态。

● 订单首选 SBE:简单二进制编码 (SBE) 通常是订单录入的首选,因为它使用固定偏移二进制布局,可以立即进行无条件解析,与 FAST 的有状态压缩相比可提供更加可预测的超低延迟。


市场数据和多播:

CEX 撮合引擎:

● 持续更新订单簿,生成动态的市场活动视图。

市场数据转换:

● 通过聚合和标准化,将原始订单簿状态转换为市场数据。

● 交易所提取不同级别(Level 1、Level 2、Level 3)的最佳买入价和卖出价等关键指标。

● Level 1 数据:提供最佳买入价(买方愿意支付的最高价格)和最佳卖出/要价(卖方愿意接受的最低价格)的实时信息。通常还包括最后成交价和成交量。

● Level 2 数据:通过显示不同价格级别的多个买入价和卖出价(订单簿)提供更深入的市场视图。这种市场深度 (DOM) 信息有助于交易者判断整体供需。

● Level 3 数据:通常仅供做市商和交易所成员使用。它包含 Level 1 和 Level 2 的所有信息,以及与订单簿交互并直接执行交易的能力。

市价单:

● 为市价单生成市场数据,市价单会立即与最佳可用买入价或卖出价撮合。

AWS Transit Gateway 上的多播:

● 在 VPC 内部或 VPC 之间复制和模拟多播传送时需要使用。

● 较小型 CEX 可能使用共享 transit gateway 向 MM 分发市场数据。

● Transit Gateway 使用方便,但并非为高频、低延迟交易而设计,并且对大型 CEX 存在扩展限制。


市场数据分发:

传统市场:

● 通过经过优化、物理边界明确的托管网络,使用 UDP 多播向 HFT MM 分发市场数据。

云托管 CEX:

● 主要使用 TCP 单播 WebSocket API 分发实时市场数据。

REST API:

● 用于按需或定期检索数据(例如历史交易、K 线数据)。

● 适用于投资组合跟踪器等非实时应用程序。

● 轮询 REST 端点会引入更高的延迟和更严格的速率限制。

FIX Gateway:

● 一些 CEX 通过 FIX gateway 为机构 MM 提供实时市场数据。

● 提供消息标准化和更低延迟的访问。

● FIX 端点通常托管在专用于特定机构 MM、对冲基金和自营交易公司的云基础设施上。


精确时间与公平、平等的订单处理:

公平和平等访问的重要性:

● 对数字资产交易所至关重要,并从网络基础设施延伸到应用程序组件。

● MiFID II 等监管框架在传统市场中强制执行公平原则,数字资产交易所也遵循类似原则。

公平的订单和市场事件排序:

● 在交易撮合之前和之后都至关重要。

● 准确计时是公平订单排序的核心,使 CEX 能够为跨分布式组件的消息添加时间戳。

HFT MM 的精确时间:

● 支持更准确地处理事件和生成信号。

● 为策略执行和风险控制提供信息。

过去的云计时服务:

● 精度可达数百微秒或毫秒,无法满足要求个位数微秒精度的 HFT 策略。


第二版金融工具市场指令 (Markets in Financial Instruments Directive II, MiFID II)

● 是一项于 2018 年生效的欧盟法规。

● 旨在创建更公平、更透明、更高效的金融市场。

● 加强整个欧洲的投资者保护和竞争。

● 涵盖更多工具,并收紧有关行为、透明度和报告的规则。

关键方面:

● 向客户详细披露成本/费用

● 更严格的适当性评估,包括可持续性偏好

● 客户交易的最佳执行义务

● 加强向监管机构提交交易报告,以进行市场监控

● 针对 OTF(Organised Trading Facilities)等新交易场所的规则,以及针对现有交易场所的更严格规则

关键目标

● 投资者保护:确保客户获得最佳结果(最佳执行)和适合他们的产品,并获得清晰的成本/风险信息。

● 透明度:要求向监管机构 (ESMA) 和客户详细报告交易活动(价格、交易量)。

● 市场效率:促进竞争、减少不透明交易(如暗池),并创建欧盟范围内的统一规则。

核心要求和变化

● 成本和费用:公司必须预先向客户披露所有成本(费用、佣金)。

● 最佳执行:公司必须采取一切措施,为客户交易获得尽可能好的结果(价格、速度、成本)。

● 产品治理:要求制造商和分销商确定每种产品的“目标市场”。

● 交易场所:创建新场所 (OTF),并对现有场所实施更严格的规则。

● 数据报告:增加向监管机构 (ESMA) 提交的交易报告,以监控市场滥用行为。

适用对象

● 投资公司

● 银行

● 资产管理公司

● 交易场所(包括新的 OTF)

● 金融产品的制造商和分销商


有组织交易设施 (OTF)

● 是用于债券、结构化产品、排放配额和衍生品的欧洲金融场所。

● 作为一个多边系统,使买卖权益相遇并形成合约。

● OTF 运营商对执行拥有裁量权,允许进行配对自营交易。

● 根据 MiFID II 规则为非流动性工具创造透明度。

关键特征:

● 产品重点:主要面向债券、结构化金融产品、排放配额和衍生品等非权益工具(MiFID II 工具)。

● 多边系统:汇集多个第三方买卖权益,与其他交易场所类似。

● 全权执行:OTF 运营商可以自行决定如何执行交易,这与 Multilateral Trading Facilities (MTF) 的非全权规则不同。

● 配对自营交易:运营商可以作为自营方匹配买卖订单,但仅限严格条件下,尤其是流动性较差的主权债务。

● 监管框架:根据 MiFID II/MiFIR 创建,需要授权,并受严格的市场滥用规则和透明度要求约束。

与 MTF (Multilateral Trading Facilities) 的区别:

● 裁量权:OTF 允许运营商行使裁量权;MTF 不允许。

● 产品:OTF 专注于固定收益和衍生品;MTF 可以交易股票和其他工具。

● 自营交易:OTF 允许有限的配对自营交易,而 MTF 通常禁止此类交易。


多边交易设施 (MTF)

● 是受监管的电子平台,提供传统证券交易所的替代方案。

● 根据欧洲 MiFID II 等规则连接买方和卖方。

● 促进各种资产(股票、债券、衍生品)的交易,通常用于流动性较低或场外交易 (OTC) 产品。

● 为市场运营商和银行提供高效、非全权的交易。

● 与传统交易所相比,其对工具的审查不那么严格。

MTF 的关键特征:

● 电子化和多边性:汇集多个第三方对金融工具的买卖权益。

● 替代场所:作为非交易所场所,通常用于奇异或 OTC 产品,增加市场流动性。

● 由运营商运营:由市场运营商或投资公司运营,不一定由证券交易所本身运营。

● MiFID 框架:受 MiFID II 等欧洲指令监管,确保透明度和公平性。

● 资产类别:可以交易股票、债券和衍生品,但有特定规则(例如不得进行自营交易)。

与受监管市场的区别:

● 上市流程:MTF 上的工具不一定经过传统交易所(受监管市场)所要求的广泛审查和持续义务。

● 裁量权:MTF 根据非全权规则进行交易撮合,这与允许对非股票工具行使裁量权的 Organised Trading Facilities (OTF) 不同。

示例:

● Liquidnet Europe

● Currenex MTF

● UBS MTF


Currenex MTF

● Currenex MTF (Multilateral Trading Facility) 是 State Street 面向机构外汇交易的电子平台。

● 由 60 多家银行提供紧密价差和深度流动性。

● 提供匿名的全对全 ECN 访问。

● 允许专业人士使用多种订单类型、算法和低延迟 API 连接执行交易。

● 作为纯 ECN(No Dealing Desk)系统运行。

● 专注于为大型参与者提供高效、经济的外汇和金属交易。


Liquidnet

● 是一家技术驱动的代理执行专家,也是 TP ICAP Group 的子公司。

● 将机构投资者连接到庞大的全球流动性池,主要服务于股票、固定收益和衍生品的大宗交易。

核心服务和功能:

● 大宗交易:促进机构投资者之间的大规模匿名交易,最大限度降低市场冲击成本并保护交易信息。

● 全球网络:连接六大洲 57 个市场的 1,000 多家资产管理公司,这些公司合计管理着数万亿美元的资产。

技术和平台:

● 暗池:作为 Alternative Trading System (ATS) 或 Multilateral Trading Facility (MTF) 运营,使用私有论坛进行交易。

● 算法交易:提供“Barracuda”和“SmartDark”等高级算法,在最大限度减少市场足迹的同时,在内部和外部场所寻找流动性。

● OMS/EMS 集成:旨在与成员现有的 Order Management Systems (OMS) 和 Execution Management Systems (EMS) 无缝集成。

资产类别:

● 固定收益:为二级市场交易提供解决方案,并为一级债券市场提供创新的电子工作流,包括与银团银行的连接。

● 上市衍生品:扩展到美国股票期权,以增强多资产能力。


非全权规则

● 是不留个人判断或选择余地,要求采取特定行动或取得特定结果的准则或要求。

● 常见于金融(要求客户批准交易)、法律(强制支出/行动)和交易系统(固定买入/卖出触发条件,如 5/20 交叉)。

● 在投资中,这意味着经纪商必须为每笔交易获得客户同意;这与由顾问作出决定的全权委托账户形成对比。

● 非全权意味着遵循严格的协议,而不是行使个人裁量权。

关键方面:

● 强制遵守:必须严格遵守规则,例如食品或住房等必需品的非全权支出。

● 明确触发条件:通常涉及客观标准,例如交易系统的算法(例如 5 日平均线穿越 20 日平均线)。

● 客户控制(投资):在金融领域,客户保留“最终决定权”,批准每笔交易,经纪商则充当订单接收者。

与全权规则的对比:

● 非全权:严格遵守预先确定的规则或客户指示(例如,“当 XYZ 达到 $50 时买入 100 股”)。

● 全权:允许顾问运用自己的判断作出决定(例如,“管理我的投资组合以实现增长”)。


外汇交易中的无交易员平台 (No Dealing Desk, NDD) 系统

● 客户订单直接传递给外部流动性提供商,不经过任何内部干预,也没有“dealing desk”作为交易对手。

● 确保透明度,并消除经纪商与交易者之间潜在的利益冲突。

NDD 系统的工作原理:

● NDD 经纪商充当纽带,使用自动化系统从流动性提供商网络中寻找最佳可用价格。

主要通过两种机制运行:

● 直通式处理 (Straight-Through Processing, STP):客户订单直接路由到流动性提供商,经纪商在价差上增加少量固定加价作为佣金。

● 电子通信网络 (Electronic Communication Network, ECN):交易者的订单在去中心化市场中直接与其他参与者(包括银行、其他经纪商和个人交易者)匹配。ECN 经纪商通常按每笔交易收取固定佣金,同时提供来自市场的原始浮动价差。

优点和缺点:

● 基础:No Dealing Desk (NDD)

● 经纪商的角色:促成交易而不持有对手立场。

● 利益冲突:不存在潜在利益冲突,因为经纪商从交易量/佣金而不是客户亏损中获利。

● 订单执行:以实际市场价格自动、即时执行,不重新报价。

● 定价:根据实际市场状况浮动的价差。

● 透明度:由于直接访问市场和实时报价,透明度很高。

● 潜在缺点:在高波动期间价差可能扩大;可能涉及佣金或整体成本略高;存在滑点风险。

产品和经纪商:

● 交易者通常使用特定平台进行 NDD 交易,有多家信誉良好的经纪商提供此系统。

NDD 经纪商:

● FP Markets:因持续较低的 RAW 价差(通常为零点)和快速执行速度而备受赞誉。

● Pepperstone:以出色的 MT4 交易工具和 Razor 账户上有竞争力的价差著称。

● IC Markets:因提供市场上一些最低的平均 RAW 价差而脱颖而出(EUR/USD 最低可达 0.02 点)。

● FxPro:提供具有 RAW 价差的 cTrader 平台,以简洁界面和高级图表工具著称。


Liquidnet Barracuda 算法

● 寻找流动性的交易算法

● 将暗池聚合与明盘交易相结合

● 旨在实现高参与率和最小市场冲击

Barracuda 算法的工作原理

● 利用机会主义逻辑获取流动性

暗池聚合

● 核心组件:暗池聚合器

● 在暗池中寻找大型匿名流动性区块

● 在不暴露订单规模或意图的情况下执行交易

● 减少价格冲击

明盘交易

● 补充暗池聚合

● 在有利时于公开证券交易所交易

● 采用机会主义逻辑寻找最佳执行机会

结果和优势

高参与率

● 在市场交易量中取得显著参与率(例如明盘市场交易量的 65.5%)

节省市场冲击成本

● 节省市场冲击成本

● 据报告,大宗订单执行节省了 10.0 个基点 (bps)

性能指标

● 比 10% 成交量百分比 (POV) 交易成本模型优 17.4 个基点 (bps)

● 比区间成交量加权平均价 (Interval VWAP) 优 4.8 个基点 (bps)

结论

● 高效执行大额订单

● 最大限度减少对市场价格的干扰


Liquidnet SmartDark 算法

● 专为机构交易者设计

● 在暗池中高效执行大额股票订单

● 最大限度降低市场冲击并增强价格稳定性

SmartDark 算法的工作原理

● 在 Liquidnet Dark 交易环境中运行

● 寻找大型、不公开显示的流动性区块

优先路由

● 使用优先路由系统

● 评估“收益和质量指标”

● 智能决定将订单的各个部分发送到何处

● 优先选择具有更佳执行规模和稳定价格的场所

寻找流动性的策略

● 主动寻找和访问广泛的暗池场所

● 利用内部大宗交叉交易机会

● 避免被动等待匹配

最大限度扩大流动性覆盖

● 将目标明确的策略与最大流动性覆盖面相结合

● 允许交易者访问高质量场所

最大限度降低市场冲击

● 在暗池中匿名执行大额交易

● 防止更广泛的公开市场看到大额订单规模

● 避免明盘交易所中发生的显著价格波动


5/20 EMA 交叉策略

● 使用 5 周期 EMA 与 20 周期 EMA 的交叉来发现短期趋势变化

● 当 5 EMA 上穿 20 EMA 时产生看涨信号(买入)

● 当 5 EMA 下穿 20 EMA 时产生看跌信号(卖出)

● 非常适合有趋势、快速波动的市场

● 需要确认(例如 RSI、交易量)以避免虚假信号

工作原理

● 5 EMA(快线):快速响应近期价格变化

● 20 EMA(慢线):提供更广泛、更平滑的短期趋势视图

入场信号

● 看涨(买入):5 EMA 上穿 20 EMA

● 看跌(卖出):5 EMA 下穿 20 EMA

实施步骤

● 识别趋势:使用更高时间周期(日线/周线)查看整体市场方向

● 绘制 EMA:在图表中添加 5 周期和 20 周期 EMA

● 等待交叉:在所选时间周期中等待 5 EMA 穿越 20 EMA

● 确认:使用 RSI、交易量或 K 线形态等其他工具验证信号

● 设置止损和目标:对多头将止损设置在摆动低点以下,对空头设置在摆动高点以上;使用风险/回报比(例如 1:2、1:3)止盈

最适合

● 动量交易:捕捉快速、剧烈的走势

● 趋势市场:在方向明确的市场中效果最佳

● 活跃交易者:适合较短时间周期(15 分钟、1 小时、5 分钟)的日内或波段交易

关键注意事项

● 虚假信号:5 EMA 的快速特性会产生许多信号,其中很多是虚假的(震荡洗盘)

● 确认至关重要:切勿仅依赖交叉;始终寻求其他指标的确认


Amazon Time Sync Service:

● 于 2023 年末改进,使用 PTP 和 PTP 硬件时钟实现低于 100 微秒(通常低于 50 微秒)的时间精度。

● 由每个可用区中的专用计时网络和 GPS 校准时钟提供支持。

硬件数据包时间戳:

● 于 2025 年 6 月推出,在硬件级别为每个入站网络数据包附加一个 64 位、纳秒精度的时间戳。

● 利用 AWS Nitro System 的参考时钟并绕过软件引起的延迟。

● 提供数据包抵达 Nitro NIC 时的纳秒级可见性。

增强执行和监控能力:

● 改善 AWS 上数字资产交易所和 HFT MM 的执行及监控能力。

更高的公平性和准确测量:

● 允许 CEX 实现更高的公平性。

● 使 HFT 能够准确测量往返延迟和单向延迟。