我使用 QuickFIX/J 庫構(gòu)建了一個(gè) FIX Initiator 應(yīng)用程序來向我的經(jīng)紀(jì)人發(fā)送訂單。如果您不知道什么是 FIX 應(yīng)用程序，請(qǐng)考慮我的程序是一個(gè)通過 TCP 連接向服務(wù)器發(fā)送消息的應(yīng)用程序。為了獲取和發(fā)送由多種算法創(chuàng)建的訂單，我有一個(gè)目錄觀察器 (WatchService)，它使用 AWS Cli 監(jiān)視與 S3 存儲(chǔ)桶同步的本地目錄上的修改。這種方法效果很好，除了我必須等待大約 6-8 秒才能將文件放入我的本地目錄，這樣我可以解析它以修復(fù)訂單并發(fā)送到經(jīng)紀(jì)人的 FIX 應(yīng)用程序。我真的很想減少訂單創(chuàng)建和訂單發(fā)送給經(jīng)紀(jì)人之間的延遲。我認(rèn)為有哪些可能的解決方案：1) 不使用 AWS CLI 直接從 S3 存儲(chǔ)桶讀取2） 針對(duì)每個(gè)不同的算法開啟不同的FIX會(huì)話3) 不是從桶中讀取數(shù)據(jù)，而是為新訂單訪問數(shù)據(jù)庫 (MySQL)。算法將生成表格行而不是文件4) 在我的 FIX 應(yīng)用程序和算法之間有一個(gè) API，所以算法可以直接連接到我的應(yīng)用程序。解決方案 (1) 沒有改進(jìn)訂單接收時(shí)間，因?yàn)榱谐?S3 對(duì)象、獲取摘要和過濾所需文件所花費(fèi)的時(shí)間大致相同。解決方案（2）我沒有嘗試過，但我認(rèn)為這不是最好的。例如，如果我有 100 種不同的策略，我將不得不打開 100 個(gè)不同的連接，而且我不確定我的代理應(yīng)用程序是否可以處理。但我可能錯(cuò)了。解決方案（3）我也沒試過。解決方案（4）是我認(rèn)為理想的，但我不知道如何實(shí)施。我試圖創(chuàng)建一個(gè) REST API，但我不知道它在概念上是否正確。假設(shè)我的 FIX 應(yīng)用程序當(dāng)前連接到經(jīng)紀(jì)人的服務(wù)器，我的想法是 (i) 創(chuàng)建一個(gè)新的 webapp 來創(chuàng)建一個(gè) REST API (ii) 通過 API 接收訂單信息，(iii) 找到當(dāng)前活動(dòng)會(huì)話和 (iv ) 使用當(dāng)前會(huì)話向代理服務(wù)器發(fā)送訂單。不幸的是，我無法通過 ID 在運(yùn)行 FIX 應(yīng)用程序的不同類上使用以下內(nèi)容找到當(dāng)前會(huì)話：SessionID sessionID = new SessionID("FIX.4.4", "CLIENT1", "FixServer");     Session session = Session.lookupSession(sessionID);我想聽聽您的意見：您認(rèn)為發(fā)送由多個(gè)來源創(chuàng)建的 FIX 訂單的最佳解決方案是什么？如果我想創(chuàng)建一個(gè) API 來連接 2 個(gè)不同的應(yīng)用程序，我可以遵循哪些步驟？如果我有點(diǎn)困惑，我很抱歉。如果您需要進(jìn)一步說明，請(qǐng)告訴我。