Disruptor 日志实现答案

【问题标题】：Disruptor Journaling ImplementationDisruptor 日志实现
【发布时间】：2018-01-24 02:06:53
【问题描述】：

日志者的工作是以持久的形式存储所有事件，所以如果出现任何问题，它们可以重播。 LMAX 不使用为此的数据库，只是文件系统。他们将事件流式传输到磁盘。

我很好奇基于文件系统的事件日志在实践中的实现是什么样的。 following answer 表示它被写入“原始文件”，但我对可能为生产系统实现的实际细节感兴趣。它真的是一个包含不断附加的结构化日志的原始文本文件吗？还是某种二进制格式？系统的这个组件是否有任何关键的设计决策？

【问题讨论】：

【解决方案1】：

日志器只是主应用程序环形缓冲区的另一个消费者。从线路读取消息，添加一个标头（接收时间戳等），然后将其送入环形缓冲区。

共有三个消费者：

应用程序处理程序在日志记录器完成和来自辅助节点的确认上进行门控，确保在处理应用程序消息之前接收到的消息在辅助节点的环形缓冲区和本地系统页面缓存中。

日志器非常愚蠢 - 消息以有线格式附加到固定长度的日志文件中。该文件是预先分配的，并且使用了各种文件系统挂载选项来最小化写入延迟。最后，我们发现 XFS 是最好的文件系统选项，但前提是没有正在写入的日志文件的并发阅读器。否则 XFS 代码中可能会出现令人讨厌的锁定效果。

如果您对我们如何得出这些结论感兴趣，我将所有这些都写得很详细：

【讨论】：

【解决方案2】：

建议的日志记录器需要包含两条信息：接收到的事件本身和某种标识符，用于跟踪您在日志中的位置，以便您可以在回放期间从该记录开始选择。

存储格式最终由您决定，但需要考虑以下因素：

重播可能不仅需要由系统崩溃触发，还需要由您自己代码中的错误触发。输入消息字节流的操作越少越好。对字节流的任何操作都会引入错误的机会，并使您的重播逻辑与“将字节放回输入缓冲区”非常不同。 对我来说，这可能是最大的决定。
重播应该快速且不包含业务逻辑。允许您的存储设备按顺序存储并且不需要来回跳跃的文件格式（例如具有索引的数据库将需要）将更好地提高性能。环形缓冲区输入和存储层之间的层数越多，速度就越慢。
磁盘上的预分配存储（您甚至可以使用 RAW 分区）将允许您从头到尾写入字节，而无需更新文件系统的目录元数据和可用空间跟踪区域。这应该简化并提高性能。只要这种预分配足以在检查点之间保留所有数据，就可以了。随着存储设备的改进，随着时间的推移，这变得不再那么令人担忧。

【讨论】：