Fargate中EFS挂载卷内容因读取容器不同出现不一致的原因排查

问题场景 #

在Fargate上通过Docker Compose ECS集成部署两个独立容器：Database和Verifier，二者共享EFS卷database-state，Verifier需直接读取Database写入的磁盘文件。分容器部署时，Verifier经常读取到不一致数据导致报错；但将两个进程合并到同一容器运行时无此问题，本地测试也正常，问题仅出现在Fargate/EFS环境。

分容器部署的docker-compose.yml配置：

services:
  database:
    image: database
    volumes:
      - database-state:/database-state
  verifier:
    image: verifier
    volumes:
      - database-state:/database-state
    depends_on:
      - database
volumes:
  database-state: {}

单容器部署的docker-compose.yml配置：

services:
  database-and-verifier:
    image: database-and-verifier
    volumes:
      - database-state:/database-state
volumes:
  database-state: {}

根因分析 #

1. EFS客户端缓存延迟：EFS默认开启客户端级别的数据和元数据缓存，Database容器写入数据后，数据会先存在容器本地缓存，再异步同步到EFS服务端，Verifier容器挂载的卷无法立即获取最新数据。而单容器内共享本地文件系统，不存在跨容器的缓存同步延迟；本地测试用的是本地卷，缓存逻辑和EFS完全不同，因此无此问题。
2. 分布式文件系统的一致性语义差异：很多数据库类进程依赖本地文件系统的强一致性（写入后立即对所有进程可见），但EFS作为分布式文件系统，跨节点（容器）的文件可见性存在天然延迟，无法像本地磁盘那样保证即时一致性。
3. 文件锁同步问题：EFS的文件锁实现与本地文件系统不同，多容器同时访问同一文件时，锁状态可能无法实时同步，导致Verifier读取到Database尚未写入完成的不完整文件。

解决方法 #

1. 禁用EFS客户端缓存 #

修改Docker Compose卷配置，指定EFS驱动并禁用缓存，确保所有读写直接交互EFS服务端，避免缓存延迟。示例配置：

services:
  database:
    image: database
    volumes:
      - database-state:/database-state
  verifier:
    image: verifier
    volumes:
      - database-state:/database-state
    depends_on:
      - database
volumes:
  database-state:
    driver: aws-efs
    driver_opts:
      awsregion: <你的AWS区域>
      cache-mode: none

注意：需替换<你的AWS区域>为实际部署的区域，同时确保ECS任务角色有EFS访问权限。

2. 强制数据库刷盘 #

修改Database的配置，让每次写入后强制刷新到磁盘，确保数据真正持久化到EFS而非停留在容器缓存。比如：

• 若使用SQLite，添加PRAGMA synchronous=FULL配置；
• 若使用LevelDB，调整write_buffer_size和sync参数确保写入即时同步。

3. 优化EFS性能配置 #

• 将EFS的性能模式从「通用模式」切换为「最大IO模式」，提升高并发下的数据同步效率；
• 若使用按需吞吐量模式，改为预置吞吐量模式，避免吞吐量波动导致的同步延迟。

4. 增加跨容器同步机制 #

在Database写入完成后，生成一个标记文件（比如/database-state/write_complete.flag），Verifier进程启动或读取数据前，先检查该标记文件是否存在，确保数据已完全写入EFS后再进行读取操作。也可以通过消息队列（如SQS）让Database通知Verifier数据就绪。

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