我对关于日志记录步骤的最常见（或推荐）disruptor 实现感到好奇。我最常见的问题是：
- 它是如何实际实现的（通过示例）？
- 使用 JPA 明智吗？
- 常用的数据库是什么（已经使用disruptor实施项目的社区）？
- 在中间处理程序（EventProcessors）中使用是否明智，因此应保存每个消息的状态，而不是在业务逻辑过程之前和之后？
顺便说一句（很抱歉，我知道这与日志步骤无关），在 eventHandler 过程中从 RingBuffer 中删除消息的正确方法是什么（假设消息已死亡/过期，应通过以下方式删除）整个过程）。我想知道类似的东西死信频道 http://www.eaipatterns.com/DeadLetterChannel.html图案。
Cheers!
Disruptor 通常用于低延迟、高吞吐量处理。例如。数百万条消息，典型延迟为数百微秒。由于很少有数据库能够以合理的有限延迟处理这种更新率，因此日志记录通常对原始文件进行，并复制到第二个（或第三个）系统。
出于报告目的，系统会尽快读取此文件或侦听消息并更新数据库，但这会脱离关键路径。
当每个事件处理器都处理完某个条目后，该条目在环形缓冲区中就已死亡。
消息使用的槽在每个事件处理器处理完该消息及其之前的所有消息之前不可用。删除消息的成本太高，无论是在性能还是对设计的影响方面
每个事件处理器都会看到每条消息。由于这种情况同时发生，因此执行此操作的成本很小，但事件处理器因此忽略消息是很正常的。 （可能是大多数消息）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
