QuickFix引擎是否默认支持恢复？默认存储日志实现是否影响延迟？

问题1：消息恢复能力与MessageStoreFactory配置说明 #

• QuickFix 引擎默认不具备持久化级别的消息恢复能力，必须手动配置MessageStoreFactory实现。如果不做手动配置，引擎默认使用内存存储实现MemoryStoreFactory，所有会话序列号、收发消息缓存全存在进程内存中，一旦进程重启、连接异常中断，内存数据会直接清空，根本无法完成重连后的序列号对齐、漏发消息补发这类标准FIX协议要求的恢复流程，甚至会直接因为序列号不匹配被对端拒连。
• 你选择FileStoreFactory是生产环境非常成熟的选型：配置后引擎会将会话状态、历史消息持久化写入本地磁盘文件，只要存储文件无损坏，不管是进程重启还是网络闪断重连，都能基于本地持久化数据完成消息恢复流程。配置时只需要在引擎配置文件中指定两个参数即可：

  MessageStoreFactory=FileStoreFactory
  FileStorePath=/path/to/your/store/directory
  

  注意要给运行应用的系统用户分配该存储目录的读写权限，避免启动时报权限错误。

问题2：默认存储、日志组件同步逻辑对延迟的影响判断 #

• 你的推测完全符合QuickFix原生实现的实际情况。
• QuickFix 官方自带的FileStoreFactory、文件实现的FileLogFactory，全部采用同步阻塞IO逻辑：每处理一条消息，对应的存储落盘、日志写入操作都会直接阻塞当前的消息处理线程，直到操作系统完成磁盘IO返回写入成功的结果，才会继续执行后续处理逻辑。在磁盘IO性能差、消息吞吐量高的场景下，这部分阻塞开销会明显增加消息处理的端到端延迟。
• 如果你的业务对延迟比较敏感，可以根据可靠性要求做对应优化：
  • 对消息可靠性要求极高的场景，直接把存储、日志的挂载目录换成高性能SSD盘，大幅降低单次IO的阻塞耗时
  • 允许极端故障场景丢失少量非关键日志的场景，可以替换为异步实现的LogFactory，将日志写入改为内存聚合后批量刷盘，完全不阻塞核心消息处理链路
  • 注意不要为了追求低延迟直接替换为内存版MemoryStoreFactory，会直接丧失持久化消息恢复能力，生产环境极易出现序列号错配导致的会话异常断连。

内容的提问来源于stack exchange，提问作者snehal