使用EF Core的Windows服务数据库不可用时暂存数据方案咨询

1. EF Core 原生支持情况 #

EF Core 本身没有内置数据暂存、离线后自动重试入库的功能。它的核心定位是ORM框架，仅负责抽象数据库交互逻辑，不包含业务层面的持久化队列、离线容错能力。

2. 最优落地架构 #

核心思路是持久化本地队列 + 自动重试机制，完全可以满足数据库不可用时期服务正常运行的要求，实现逻辑如下：

• 先封装待写入数据：将需要入库的实体序列化（推荐用Protobuf或System.Text.Json），附带唯一ID、操作类型、创建时间等元数据，用于后续幂等校验和顺序控制
• 主写入流程：
  • 每次触发写入操作时，先尝试用EF Core正常提交变更
  • 捕获到数据库连接异常、超时异常等明确为数据库不可用的错误时，将封装好的待写入数据持久化到本地队列
  • 注意区分数据本身不合法的异常（如字段长度超限、外键不存在），这类异常即使数据库恢复也无法入库，需直接记录错误日志并告警，不要进入暂存队列
• 后台重试任务：
  • 基于Windows服务自带的IHostedService实现独立后台线程，按固定间隔（如30秒，可根据业务调整）轮询本地暂存队列
  • 轮询到待处理数据时，按创建时间先后批量提交到数据库，写入成功后删除对应队列数据，写入失败则等待下一轮重试，可配合Polly库实现熔断策略，避免数据库恢复初期被大量重试请求打满

3. 成熟现成方案选型 #

根据数据规模和复杂度可以直接选以下落地方案，无需从头实现：

• 轻量场景（数据量<10万/天）：本地文件队列
  无需引入第三方依赖，直接在本地指定目录下，将每个待写入项存为独立的序列化文件，文件名用「时间戳+GUID」命名，既保证顺序，又避免重名。写入文件时先写.tmp后缀的临时文件，写完再改名，避免程序中途退出产生半截无效文件。
• 中等规模场景：嵌入式数据库
  用SQLite或LiteDB作为本地暂存存储：
  • SQLite可以直接复用EF Core的操作能力，你可以共用实体模型，甚至可以直接把DbContext的Provider切换为SQLite写入暂存数据，学习成本极低
  • LiteDB是轻量NoSQL嵌入式数据库，无需预定义表结构，存序列化实体更灵活，API简单易上手
• 低代码场景：Hangfire
  直接将数据库写入操作封装为Hangfire后台任务，配置Hangfire用SQLite作为持久化存储，无需部署额外服务。Hangfire原生支持失败自动重试、任务持久化、重试间隔配置，你完全不需要自己写队列管理、重试逻辑，只需要配置重试策略即可，适合快速落地。

4. 注意事项 #

• 必须保证幂等性：给每个待写入项分配唯一业务ID，入库前先校验是否已存在，或在数据库中加唯一约束，避免重试时重复插入数据
• 如果业务对写入顺序有严格要求，暂存队列必须保证FIFO（先进先出），重试时严格按创建时间顺序处理
• 可配置多级重试策略：数据库不可用时先做3-5次即时短间隔重试，还失败再存入本地队列，减少不必要的暂存操作

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