java - 基于分布式 JMS 的日志记录……一落千丈？

Question

在我们奇特的 ESB 中，每个请求的日志记录都是通过基于 JMS 日志记录的公共(public)基础设施完成的。简而言之，这是发生的事情:

1. 服务获取请求服务
2. 在 LogData 中准备一些数据
3. 对象服务调用数据库
4. 在 LogData 对象中捕获数据库交互所花费的时间
5. 服务已准备好发送响应
6. LogData 对象被发送到消息目的地
7. 服务发送响应

非常漂亮!是的纸建筑师。这是实际问题: JMS 服务提供者有时会变得不可用 - 由于系统级错误或软件崩溃。然后服务在必须建立 JMS 连接以发送 LogData 对象的步骤(第 6 步)处等待。导致响应延迟，从而导致糟糕的性能和用户体验。

所以这就是很多开发者网站吹捧的“分布式日志使用JMS”最大的缺点。另请注意，LogData 的存在是一种关键的非功能性需求。这意味着消息以持久模式发送，导致等待直到 JMS 提供者确认收到发送者(在本例中为服务)的消息——这该怪什么？不成熟的设计？ 是否有实现此类措施的成功案例？

Answer 1

在 db/jms/socket/etc 中同步进行任何日志记录都是在问问题，而且问题很多。

通过登录到内存和异步来实现它。转储到文件/jms(取决于 JMS 是否可用)。单个后台线程应该可以为您解决问题。有同步。日志记录可能会在应用程序的完全意外和无辜的部分造成很多麻烦。

我想不出任何可能的同步成功案例。日志记录。

编辑。最好使用 ConcurrentLinkedQueue 之类的东西来保留 LogData(我的意思是避免任何阻塞，如果可能的话，可以提高性能/吞吐量)