我通过 FIX 协议向供应商发送订单。供应商每秒只接受 100 条 FIX 消息，并要求我限制我发送给他们的订单不超过这个速率。我确信我可以写一些东西来减慢我发送给他们的消息，类似于我在这里找到的内容：Throttling method calls to M requests in N seconds
但我有两个问题：
我想知道减慢发送给执行供应商或清算公司的消息的速度是否是行业的普遍要求，或者这是我正在与 rinky-dink 供应商打交道的危险信号？
是否有一些参数可以让 QuickFix/J 自动减慢我的消息吞吐量？
有许多系统难以处理大量灌装。它很可能与网络带宽无关，而是在应用层对消息的底层处理。
例如，一些较旧的系统依赖于具有表锁定功能的关系数据库，如果执行量很大，则整个订单管理系统可能会出现性能问题。
蛮力解决方案是强制执行提供程序汇总执行或限制它们。
这与供应商带宽有限并且可能连接数十或数百个客户端的事实有关。如果您要求对 100 种仪器定价，并且在一个安静的市场中，这些仪器都每秒更新一次，那么 - 每个 FIX 连接 - 供应商必须每秒处理 100 条消息。好的，一条 FIX 消息是关于多少字节的：说 500 个字符，每个字符 1 个字节 = 500 个字节（有人在这里纠正我）。因此，每个连接每秒 500 * 100 = 50,000 字节。
然后连接 100 个客户端 = 每秒 5,000,000 字节。嗯，还有更多的空间。
但在繁忙的市场中，报价每秒更新 10 或 20 次。这些数字乘以 10 或 20 倍。您会遇到网络风暴、长消息队列、高 CPU、消息丢失，或者整个事情都崩溃了。然后供应商将失去所有业务，因为他们无法在最关键的时刻保持联系。
好的，这个问题可能有很多解决方案，但它是对必须解决的问题的描述......
另一件事是您的供应商的主要做市商必须根据市场情况更新他们的报价。他们将要求所需的带宽或简单地拒绝交易执行。因此，您在卖方和买方之间进行了另一种权衡。