Disruptor：日记示例
我对有关日记步骤的最常见（或推荐）的disruptor实现感到好奇。 我最常见的问题是：
- 它是如何实际实现的（例如）？
- 使用JPA是明智的吗？
- 什么数据库是常用的（由已经实施破坏者项目的社区）？
- 在中间处理程序（EventProcessors）中使用是否明智，因此应该保存每条消息的状态，而不是在业务逻辑进程之前和之后？
顺便说一句（对不起，我知道这与日志记录步骤无关），在eventHandler进程中从RingBuffer中删除消息的正确方法是什么（假设消息已经死/过期，应该通过整个程序）。 我想知道类似死信频道模式的东西。
干杯!
Disruptor通常用于低延迟，高吞吐量处理。 例如，数百万条消息具有数百微秒的典型延迟。 由于极少数数据库可以通过合理限制的延迟来处理这种更新速率，因此通常会对复制到第二（或第三）系统的原始文件执行日记。
出于报告目的，系统会读取此文件或侦听消息并尽快更新数据库，但这会从关键路径中取出。
当每个事件处理器处理完条目时，条目缓冲区中的条目已经死亡。
消息使用的插槽在每个事件处理器处理完之前以及之前的所有消息之前都不可用。 在性能和对设计的影响方面，删除消息的成本太高
每个事件处理器都能看到每条消 由于这种情况同时发生，这样做的成本很低，但事件处理器忽略消息是很正常的。 （可能是大多数消息）