发生异常时自定义ILogger实现的最佳实践

针对直接写入SQL Server的自定义ILogger实现，结合你提到的无内存队列、无异常处理的问题，以下是落地性强的最佳实践：

1. 强制引入异步内存队列 #

直接同步写入SQL Server会严重阻塞业务主线程——一旦SQL服务响应缓慢或不可用，业务请求会被拖垮。必须用内存队列做异步解耦：

• 业务代码仅负责将日志消息快速丢入内存队列，随即返回，不等待SQL写入完成；
• 启动独立的后台线程（或利用IHostedService）异步消费队列，执行SQL写入操作；
• 给队列设置容量上限（比如用BlockingCollection<LogEntry>(boundedCapacity: 10000)），队列满时可选择丢弃最旧日志或触发告警，避免内存溢出。

2. 异常处理：绝对隔离日志故障与业务逻辑 #

• 禁止将SQL写入异常向上传递到业务代码：日志组件的故障不能影响核心业务流程，这是日志系统的底线；
• 绝对避免用同一记录器记录写入失败事件：这会触发无限递归（写入失败→记录失败日志→再次写入失败→循环），直接引发连锁故障。

3. 配置降级/备用日志目标 #

当SQL写入失败时，静默捕获异常后切换到备用日志方案：

• 优先选择依赖少、可靠性高的目标，比如Windows事件日志（系统级服务，可用性远高于自定义SQL存储）、本地文本文件；
• 降级时仅记录关键的故障信息（比如“SQL日志写入失败，已切换到Windows事件日志”），且控制记录频率（比如5分钟内只记录一次），避免备用目标被大量故障日志刷屏。

4. 额外可靠性优化 #

• 给SQL写入操作设置超时时间（比如30秒），避免后台线程被长时间阻塞；
• 实现指数退避重试：SQL写入失败后，按1s、2s、4s的间隔重试2-3次，避免短时间内重复请求加重SQL服务器负载；
• 增加监控指标：统计日志写入成功率、队列积压量，当失败率超过阈值时触发运维告警，及时排查SQL端问题。

内容的提问来源于stack exchange，提问作者m.t.bennett