QuickFIX/J - 故障转移策略

如何解决QuickFIX/J - 故障转移策略

我想问一下 QuickFIX/J 和 Spring Boot QuickFix starter 的几个故障转移策略

例如，如果我有一个 FIX 引擎服务器，并且一整天都在接收大量 FIX 消息，但突然该服务变得不可用。

1. 当服务再次启动时会发生什么？它将从哪里开始再次读取新的 FIX 消息？
2. 当服务开始负载很重并且 kubernetes 开始放置第二个实例时会发生什么？有什么办法可以保持两个微服务之间的数据一致性，使它们不会两次处理同一条消息？
3. 如何同时处理多个微服务上的多个会话并进行扩展

感谢您的回复，我刚刚开始使用这个库

解决方法

1. FIX 引擎将根据收到的最后一条消息的序列号同步消息。您可以在此处阅读基础知识：FIX message recovery
   由于您是 FIX 协议的新手，因此整个页面可能是让您熟悉该协议的良好起点。当然，FIX 引擎会自行完成与会话级别相关的工作，但了解基础知识总是好的。

2. 我对 Kubernetes 没有任何深入的了解，但这里重要的是 FIX 会话是点对点连接。这意味着对于完全相同的会话（由 SessionID 标识，它通常由 BeginString（例如 FIX.4.4）、SenderCompID、TargetCompID 组成）您只会有一个发起者（即客户端）和一个接受者（即服务器）。
   因此，应避免启动将连接到同一 FIX 会话的服务的第二个实例。如果您将多个会话分布在多个实例上，这可能会奏效。

3. 我真的不明白你的意思，抱歉。