2

对于高性能交易引擎，它一次匹配/处理一个订单，是否应该在继续下一个订单之前将订单和其他关键信息保存到数据库？

或者我可以使用单独的线程异步保存到数据库吗？

如果是异步的，我可以使用 zeromq 将包含关键信息的 msg 发送到 DB 服务器，但是，如果崩溃，订单信息会丢失。

相反，如果我使用将消息持久保存到磁盘的rabbitmq，它是否足够安全？

4

2 回答 2

3

你的问题打开了一个完整的潘多拉盒子，里面装满了非常重要的问题。

ZeroMQ被用于这个行业是因为它非常聪明，速度极快，并且具有极简的占地面积和低开销，但是您询问的解决方案不是基于单层技术或微不足道的 Yes/No 答案.

无论 IT 行业做出何种承诺——无论是 SSD、高级 SSD、3D-SSD 还是类似的创新，核心责任在于您的端到端系统架构的可行性，而不是技术元素。假设任何元素都可能并且将会失败。市场上没有“嗯，休斯顿，我们有问题”的呼吁，高频交易中更少。

下一步

  1. 准确——陈述量化和可衡量的要求
  2. 根据需求进行设计（不是意见，无论这些营销可见性如何）
  3. 针对峰值和持续性能阈值进行测试
  4. 不要在业务灾难恢复措施测试中妥协（链式最坏情况+意外抽奖）
  5. 有条不紊和坚持不懈，妥协是相当昂贵的（如果不是致命的）

如果您仅回顾过去 4 年在金融市场中使用高性能计算的情况，那么已经满足了实现高性能和故障恢复的主要基石。沿着这条道路，还看到了错误的概念和糟糕的设计和缺乏错误隔离实践的破坏性影响——只要看看 Knights HFT 崩溃（好吧，而不是几个小时的 HFT 仍然注入错误的 XTO 指令）有一个如果 cra$h 发生在 materiali$e 中，则 $ize$ 可能会在 thi$indu$try 中出现一个“撞击坑”。

高性能交易引擎

假设您为您的系统说明了范围和性能包络：

[SCOPE]------------------------------------------------------------
Forex Majors instruments   { EURUSD, GBPUSD, <list-all-that-applicable> }
Forex Exotic instruments   { <list-all-that-applicable> }
Precious Metals            { XAUUSD, XAGUSD, <list-all-that-applicable> }
Commodities                { <list-all-that-applicable> }
US-stocks                  { AAPL, GOOG, XOM, <list-all-that-applicable> }
Euro-stocks                { <list-all-that-applicable> }
*-stocks                   { <list-all-that-applicable> }
US-indices                 { <list-all-that-applicable> }
Euro-indices               { FTSE, CAC, DAX, AMS, <list-all-that-applicable> }
*-indices                  { <list-all-that-applicable> }
Futures                    { <list-all-that-applicable> }
Options                    { <list-all-that-applicable> }
Binary Options             { <list-all-that-applicable> }
Options on Futures         { <list-all-that-applicable> }
Options on Indices         { <list-all-that-applicable> }
BT*-based instruments      { <list-all-that-applicable> }

在类似的结构中，用于设计评估的状态是实时操作性能约束，其持续值和峰值均以 [msec] 为单位

[PERFORMANCE]------------------------------------------------------
System requirement for a number of Market Events per msec per segment
System requirement for a number of PriceFeed Quotes per msec per segment
System requirement for a number of OrderProcessing Events per msec per segment

这为您提供了约束系统实时操作设计的第一个基本指标。即，您必须针对哪些开销/延迟限制进行设计，因此您有时间在 [usec]-s 中将哪些工具和哪些措施纳入管道的任何阶段，以便仍然保证系统实时稳定性和鲁棒性阈值.

一次匹配/处理一个订单？

这不是一个问题。这是给定的外部性。

[订单]匹配通常由市场监管机构提供（如果不是为暗池和其他非公开准市场设计），以满足公平市场原则。订单处理从属于您的监管和审计监督职责。这两者都不是系统设计的自由意志领域。

它应该保存吗？

[ Order ] 和 DB 的其他关键信息在转移到下一个之前，或者我可以使用单独的线程异步保存到 DB 吗？.. 更多的是来自审计/监督机构的系统要求，而不是技术委员会的意见。

如果这崩溃了？

如果您的系统架构设计允许，它可能会崩溃。然后您需要采取措施进行崩溃后恢复

如果你的系统架构设计需要开发不会崩溃的系统，这将成为一个空洞的问题。可实现应用在线镜像+热备阴影，采用 N+1、(N+1)+1 或 (N+M)+1 冗余模型，从而适当隔离个别崩溃。

它足够安全吗？

取决于您的业务灾难恢复计划和业务连续性措施。测试是不可避免的。

记住著名的诺贝尔奖得主迪克·费曼指着核电站蓝图中间的手指……

于 2014-09-26T16:02:19.463 回答
1

这个问题有很多方面，但这里有一些事情需要考虑......

发生崩溃的可能性有多大，以及在发生崩溃时丢失“关键”数据的后果是什么？这确实是一个商业问题（与技术相反）。在许多情况下，成本效益支持这样的想法，即丢失数据是可以的，并且每次发生数据时都要付出处理它的代价。在早期，经纪人通常会保证“订单在 X 中执行或您的交易成本返还”，但甚至没有衡量它。如果您投诉，他们只会退款。

一旦您知道哪些数据必须绝对持久化，高性能系统将需要找到最快的方法来做到这一点。这里也有很多细微差别？你需要什么程度的“安全”？

  • 进程内内存？（如果进程崩溃，数据会消失）
  • 进程外内存（如果“持久”进程也崩溃，数据会消失）？
  • 操作系统磁盘缓冲区，但仍然不是磁盘（如果操作系统崩溃，数据也会消失）？
  • 物理磁盘（如果磁盘本身或整个服务器“消失”，数据就会消失）？

没有人能告诉你每家高频交易公司在这方面做了什么（他们太保密了）。在银行、经纪商等中，通常在处理下一条消息（在许多情况下，无论数据是物理写入磁盘还是仍在操作系统缓冲区中）。这让您在应用程序崩溃的情况下放心。然后将异步完成进一步的处理（例如写入数据库以便可以轻松查询数据，或检查风险限制等）。

于 2014-09-26T05:11:38.127 回答