如何在AWS的多个微服务之间共享Chronicle Queue？

核心问题 #

你们的EFS共享存储方案本身不符合Chronicle Queue的设计依赖，核心原因有两点：

• Chronicle Queue底层高度依赖本地POSIX文件系统的mmap（内存映射）机制，以及跨进程的实时文件一致性保证。而EFS是基于NFS协议的分布式文件系统，天生不支持跨节点的mmap页缓存一致性——MS1写入的内容即使已经刷到EFS服务端，MS2本地的mmap映射页也不会主动失效，所以消费逻辑感知不到新消息。
• EFS默认开启了元数据和内容缓存，默认的属性缓存TTL可达数秒，即使你在控制台看到文件已修改，MS2侧的缓存还没过期，就读不到最新的文件内容。只有重启MS2时会重新加载整个队列文件，才会偶尔读到历史未消费的消息。

可行的落地方案 #

方案1：保留Chronicle Queue的性能优势（推荐） #

Chronicle Queue原生设计面向同节点多进程通信场景，不要用跨节点共享存储的方式使用：

• 将有上下游依赖的MS1、MS2调度到同一台EC2实例上，共享本地SSD卷的目录作为Chronicle Queue的存储路径，完全避开分布式文件系统的一致性问题，可以100%保留本地测试时的10~30倍性能收益。
• 如果必须跨节点部署上下游服务，放弃共享存储方案：每个服务写本地的Chronicle Queue，自研轻量同步进程将队列数据增量同步到消费节点的本地存储，消费进程直接读本地队列即可。

方案2：必须用EFS共享存储的临时调优方案 #

该方案会大幅损耗性能，大概率会抵消Chronicle Queue相对于Kafka的延迟优势，仅做临时验证使用：

• 修改EFS的挂载参数，关闭所有缓存：挂载时添加参数 lookupcache=none,actimeo=0,nocto，强制每次文件访问都请求EFS服务端拉取最新内容和元数据。
• 调整MS2的消费逻辑，禁用Chronicle Queue默认的文件变更监听逻辑，每间隔100ms主动触发一次队列的显式刷新操作，强制使本地mmap缓存失效。

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