默认情况下何时不在Logback中使用AsyncAppender

Question

Logback支持在类中使用异步appender, ch.qos.Logback.classic.AsyncAppender并且根据文档,这将减少应用程序的日志记录开销.那么,为什么不把它作为开箱即用的默认设置.使用同步追加器可以更好地服务于哪些用例.我可以通过Async appender看到的一个问题是日志消息不是按时间顺序排列的.还有其他这样的限制吗？

Answer 1

该AsyncAppender充当调度到其他的appender.它缓冲日志事件并将它们发送到例如a FileAppender或a ConsoleAppender等.

• 为什么用AsyncAppender？

  • 该AsyncAppender缓冲区记录事件,让您的应用程序代码继续前进,而不是等待记录子系统来完成写入.这可以提高应用程序的响应能力,以防止身份不足的appender响应缓慢,例如数据库或文件系统可能容易发生争用.

• 为什么不把它作为默认行为？

  • 该AsyncAppender不能写入文件或控制台或数据库或插座等相反,它只是代表事件记录到一个appender可以做到这一点.没有底层的appender,AsyncAppender实际上是一个无操作的.
  • 日志事件的缓冲区位于应用程序的堆上; 这是潜在的资源泄漏.如果缓冲区的构建速度比可以消耗的速度快,那么缓冲区将消耗应用程序可能想要使用的资源.
  • 该AsyncAppender的需要进行配置,以平衡无损失和资源泄漏的竞争性需求和处理其缓冲区对关机排水意味着它是更复杂的管理和推理比单纯使用同步写入.因此,在优先考虑简单性而非复杂性的基础上,Logback的默认写策略是同步的.

该AsyncAppender暴露你可以用它来解决潜在的资源泄漏构杆.例如:

• 您可以增加缓冲区容量
• 一旦缓冲区达到最大容量,您可以指示Logback删除事件
• 您可以控制丢弃哪些类型的事件; 在ERROR事件之前删除TRACE事件等

该AsyncAppender还自曝,你可以用它来限制(但不能消除)事件的损失在应用程序关闭配置杠杆.

但是,确保成功写入日志事件的最简单最安全的方法仍然是同步写入它们.在AsyncAppender当你有一个行之有效的问题,即写入一个appender重大影响您的应用程序响应能力/吞吐量才应考虑.