为什么我们选择Java开发高频交易系统?

2020 年 11 月 16 日

为什么我们选择Java开发高频交易系统?

在高频交易领域,自动化应用程序每天需要处理数亿个市场交易信号,并在全球各交易所之间发送成千上万的订单。


为了保持竞争力,响应时间必须始终保持在微秒级,特别是在发生类似“黑天鹅”事件的异常高峰期。


在一个典型的架构中,金融市场的交易信号被转换成内部的市场数据格式(使用各种协议,如 TCP/IP、UDP 组播和多种格式,如二进制、SBE、JSON、FIX 等)。


这些规范化的消息被发送到算法服务器、统计引擎、用户界面、日志服务器和各种类型的数据库(内存数据库、物理数据库、分布式数据库)。


这条路径上的任何一个延迟都有可能带来严重后果(比如基于旧价格做出战略决策或订单到达交易市场的时间太迟),并为此付出惨重代价。


为了加快至关重要的几微秒,大多数券商投入了昂贵的硬件:服务器组配备了超频液冷的 CPU(在 2020 年,你可以买到单台配备了 56 核 5.6 GHz CPU 和 1 TB 内存的服务器)、靠近交易所的数据中心、纳秒级高端网络交换机、海底专线(Hibernian Express 是一家主要的供应商),甚至是微波网络。


我们经常看到高度定制的可以绕过操作系统的 Linux 内核,数据可以直接从网卡“跳转”到应用程序、IPC(进程间通信),甚至是 FPGA(可编程单用途芯片)。


在编程语言方面,C++似乎是服务器端应用程序的天然竞争者:它速度快,与机器码非常接近,而且一旦针对目标平台进行编译,就可以提供恒定的处理时间。


但是,我们做了一个不一样的选择。


在过去的14年里,我们一直在用Java开发外汇算法交易系统,并使用了很棒但价格实惠的硬件。


由于团队规模小,资源有限,技术能力强的开发人员难找,所以使用 Java 意味着我们可以快速地改进软件功能,因为 Java 生态系统比 C 语言生态系统的发布速度更快。上午讨论功能改进,下午就可以实现、测试并发布到生产环境。


与那些需要几周甚至几个月才能发布更新的大公司相比,这是一个关键的优势。在高频交易领域,一个漏洞可以在几秒钟内抹掉一整年的利润,所以我们不打算在质量上做任何妥协。我们搭建了一个严格的敏捷开发环境,包括 Jenkins、Maven、单元测试、夜晚构建和 Jira,使用了很多开源库和项目。


使用 Java,开发人员可以专注于直观的面向对象业务逻辑,而不是浪费时间去调试一些晦涩的内存核心转储或管理 C++指针。而且,由于 Java 强大的内存管理能力,即使是初级程序员也可以在第一天加入项目时为系统带来价值,而且风险很小。


有了良好的设计模式和干净的编码习惯,Java 的速度可与 C++相媲美。


例如,Java 会优化和编译在应用程序运行期间观察到的最佳路径,但 C++会预先编译所有东西,因此即使未被使用的方法也会成为可执行二进制文件的一部分。


但是,Java 有一个问题,它让 Java 成为一门强大且令人喜爱的编程语言,但也成了 Java 的缺点之一(至少对于微秒级应用程序来说)——Java 虚拟机(JVM):


  1. Java在运行过程中编译代码(JIT),这意味着当它第一次运行某些代码时,会有编译延迟。

  2. Java管理内存的方式是在“堆”空间中分配内存块。每隔一段时间,它就会清理空间,移除旧对象,为新对象腾出空间。主要的问题是,为了进行准确的计数,应用程序线程需要暂时“冻结”。这个过程称为垃圾回收(GC)。


GC 是低延迟应用程序开发人员可能会放弃 Java 的主要原因。


市场上有一些可用的 Java 虚拟机。


最常见的是 Oracle Hotspot JVM,它在 Java 社区中被广泛使用,主要是一些历史原因。


对于非常苛刻的应用程序,有一个很棒的替代方案,也就是 Azul Systems 的 Zing。


Zing 是标准 Oracle Hotspot JVM 的一个强大的替代品。Zing 解决了 GC 停顿和 JIT 编译问题。


接下来,让我们来研究一下 Java 的一些固有问题和可能的解决方案。

了解 Java 的 JIT 编译器


像 C++这样的编程语言被称为编译型语言,因为发布的代码完全是二进制的,可以直接在 CPU 上执行。


PHP 或 Perl 被称为解释型语言,因为解释器(安装在目标机器上)会在运行时编译每一行代码。


Java 介于两者之间,它将代码编译成 Java 字节码,并在必要时再将其编译成二进制的。


Java 不在启动时编译代码的原因与后续的性能优化有关。通过观察应用程序运行并分析实时方法调用和类初始化情况,Java 对经常被调用的代码部分进行编译。它甚至可能会根据经验做出一些假设(某些代码永远不会被调用,或者某个对象始终是一个字符串)。


编译过的代码执行速度非常快,但有三个缺点:


  1. 一个方法需要被调用一定次数才能达到编译阈值,然后才能被编译和优化(这个阈值是可配置的,通常在10000次左右)。在此之前,未优化的代码不会“全速”运行。在更快的编译和高质量的编译之间存在折衷(如果假设是错误的,就会发生编译成本)。

  2. 当Java应用程序重新启动时,我们又回到了起点,必须等待再次达到阈值。

  3. 有些应用程序有一些不常被调用但很关键的方法,这些方法只会被调用几次,但在被调用时需要非常快。


Zing 通过让它的 JVM“保存”已编译的方法和类的状态(也就是所谓的 profile)来解决这些问题。这个独特的功能叫做 ReadyNow,也就是说 Java 应用程序可以始终以最佳速度运行,即使是在重启之后。


当你使用已有的 profile 重新启动应用程序,Azul JVM 会立即收回以前的决策并直接编译重要的方法,以解决 Java 的预热问题。


此外,你也可以在开发环境中构建一个 profile 来模拟生产行为。优化后的 profile 能部署到生产环境中,并知道所有关键路径都已经过编译和优化。


下图显示了交易应用程序(在模拟环境中)的最大延迟。



Hotspot JVM 的延时峰值是显而易见的,而 Zing 的延时保持得相当稳定。


百分比分布表明,在 1%的时间内,Hotspot JVM 发生的延迟是 Zing JVM 的 16 倍。

解决垃圾回收停顿问题


第二个问题是在垃圾回收期间,整个应用程序可能会停顿几毫秒到几秒钟(延迟会随着代码复杂性和堆大小的增加而增加),更糟糕的是,你无法控制这种情况何时发生。


虽然对很多 Java 应用程序来说,暂停应用程序几毫秒甚至几秒是可以接受的,但对于低延迟应用程序来说,这是一场灾难,无论是在汽车、航空航天、医疗还是金融领域。


GC 影响对于 Java 开发人员来说是一个很大话题,Full GC 通常也叫作“停止世界的停顿(stop-the-world)”,因为它会冻结整个应用程序。


多年来,有很多 GC 算法都试图降低吞吐量(有多少 CPU 时间用于应用程序逻辑执行而不是垃圾回收)和 GC 停顿(我可以暂停应用程序多长时间)。


从 Java 9 发布以来,G1 一直是默认的垃圾回收器,其主要思想是根据用户提供的时间目标对 GC 停顿进行划分。它通常提供较短的停顿时间,但以降低吞吐量为代价。此外,停顿时间随着堆的大小而增加。


Java 提供了大量的设置参数,从堆大小到回收算法以及分配给 GC 的线程数。因此,Java 应用程序通常会配置大量的参数:



很多开发人员通过各种技术来避免 GC。最主要的是,如果我们少创建一些对象,那么后续要清除的对象就越少。


一种古老的(仍然在使用)技术是使用对象池。例如,数据库连接池可以保存 10 个已经打开的数据库连接,以便在需要时使用。


多线程通常需要锁,这会导致同步延迟和停顿(特别是当它们共享资源时)。一种流行的方式是使用环形缓冲队列系统,多个线程可以在一个无锁的环境中(请参考disruptor)进行读写操作。


一些专家甚至处于无奈而选择完全覆盖 Java 的内存管理机制,由自己来管理内存分配,这虽然解决了问题,但也带来了更多的复杂性和风险。


因此,我们需要考虑使用其他 JVM,于是我们决定尝试 Azul Zing JVM。


很快,我们就能够在几乎无停顿的情况下实现很高的吞吐量。


这是因为 Zing 使用了一个叫作 C4(Continuously Concurrent Compacting Collector,连续并发压缩回收器)的垃圾回收器,它可以进行无停顿的垃圾回收,而不管 Java 堆有多大(可以达到 8TB)。


这是通过在应用程序运行时并发映射和压缩内存来实现的。


此外,它不需要修改代码,而且延迟和速度方面的改进都是开箱即用的,不需要进行繁杂的配置。


Java 程序员可以享受到两方面的好处:Java 的简单性(不需要担心创建太多的新对象)和 Zing 的底层性能,允许系统中出现高度可预测的延迟。


GCeasy提供了通用 GC 日志分析器,我们可以在真实的自动交易应用程序(在模拟环境中)中快速地对 JVM 进行比较。



在我们的应用程序中,使用 Zing 的 GC 大约比使用标准 Oracle Hotspot JVM 的 GC 快 180 倍。


更令人印象深刻的是,GC 停顿通常对应于实际的应用程序停顿时间,而 Zing 的 GC 通常是并行发生的,实际的停顿很少,甚至没有停顿。


总之,在享受 Java 的简单和特性的同时,仍然有可能实现高性能和低延迟。C++一般用于开发特定的底层组件,如驱动程序、数据库、编译器和操作系统,但大多数现实生活中的应用程序可以使用 Java 开发,甚至是要求很高的应用程序。


这就是为什么 Java 是排名第一的编程语言(根据 Oracle 的说法),并拥有数百万开发者,在全世界有超过 510 亿个 Java 虚拟机。


原文链接:


https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94

2020 年 11 月 16 日 14:246338
用户头像

发布了 70 篇内容, 共 96409 次阅读, 收获喜欢 102 次。

关注

评论 6 条评论

发布
用户头像
想看一下Zing对CPU的消耗图
2020 年 11 月 24 日 14:49
回复
用户头像
主要还是因为java成熟的事务管理吧
2020 年 11 月 20 日 17:00
回复
用户头像
所以最终原因还是你们团队掌控不了c啊
2020 年 11 月 19 日 19:25
回复
照你的说法,直接写汇编好了
2020 年 11 月 23 日 17:32
回复
你没看到文中都说上FPGA了吗,汇编都嫌慢
2020 年 11 月 26 日 21:08
回复
用户头像
什么是物理数据库?
2020 年 11 月 17 日 10:03
回复
没有更多评论了
发现更多内容

dnsmasq-域名访问及解析缓存

一周思进

架构师如何做架构总结

Karl

食堂就餐卡系统设计

飞雪

SpringBoot基本特性以及自动化配置-SPI机制

攀岩飞鱼

Java 微服务 Spring Boot SpringCloud

程序员的晚餐 | 6 月 7 日 豆腐年糕

清远

美食

Flink源码分析之Flink startupMode是如何起作用的

shengjk1

flink flink 消费 kafak 实时计算 flink源码 flink源码分析

Flink源码分析之Flink是如何kafka读取数据的

shengjk1

flink flink 消费 kafka flink源码分析 flink消费kafka源码解析

人人都是产品经理

二鱼先生

产品经理 个人品牌 职场成长 产品思维

Flink源码分析之-如何保存 offset

shengjk1

Flink源码分析之FlinkConsumer是如何保证一个partition对应一个thread的

shengjk1

flink flink 消费 kafka 实时计算 flink源码分析

ARTS(2020-06-01/2020-06-07)

天行者

ARTS 打卡计划

每周学习总结-架构师培训一期

Damon

架构师训练营第一周学习总结

刘志刚

食堂就餐卡系统设计

刘志刚

图解Java垃圾回收算法及详细过程!

攀岩飞鱼

Java JVM 虚拟机 垃圾回收机制

食堂就餐卡系统设计

饶军

ARTS打卡 week 2

猫吃小怪兽

ARTS 打卡计划

ARTS-WEEK2

一周思进

ARTS 打卡计划

SpringBoot整合Quartz实现任务定时

北漂码农有话说

SpringBoot 2

极客时间-架构师培训-1期作业

Damon

食堂就餐卡系统架构设计

Karl

SpringBatch系列之并发并行能力

稻草鸟人

Spring Boot SpringBatch 批量

食堂就餐卡管理系统

孙志平

程序员陪娃系列——数学启蒙趣事

孙苏勇

程序员人生 陪伴

Flink源码分析之Flink 自定义source、sink 是如何起作用的

shengjk1

flink flink源码 flink源码分析 flink自定义source flink自定义sink

Element-UI实战系列:Tree组件的几种使用场景

brave heart

vue.js 前端 Elemen

架构师训练营第一周作业

芒夏

极客大学架构师训练营

LeetCode 769. Max Chunks To Make Sorted

liu_liu

LeetCode

架构师训练营第一周作业

小树林

愚蠢写作术(3):如何把读者带入迷宫深处

史方远

学习 读书笔记 个人成长 写作

架构方法学习总结

飞雪

为什么我们选择Java开发高频交易系统?-InfoQ