Architecture 中断日志记录实现

他在书中说：

日志记录者的工作是以持久的形式存储所有事件，因此 如果出现任何问题，它们可以重放。LMAX不使用 这是一个数据库，只是文件系统。他们把事件源源不断地传给媒体 磁盘

---

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

建议的日志记录者需要包含两条信息：接收到的事件本身和某种类型的标识符，以跟踪日志中的位置，以便在重播期间从该记录开始

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

• 重播可能不仅需要从系统崩溃中触发，还需要从您自己代码中的错误中触发。对输入消息字节流的操作越少越好。对字节流的任何操作都会引入bug，并使您的重放逻辑与“将字节放回输入缓冲区”非常不同。对我来说，这可能是最大的决定

• 回放应该是快速的，并且不包含业务逻辑。一种允许存储设备按顺序存储而不需要来回跳转的文件格式（如带有索引的数据库）将提高性能。环形缓冲区输入和存储层之间的层越多，速度就越慢

• 磁盘上预先分配的存储（您甚至可以使用原始分区）将允许您自始至终写入字节，而无需更新目录元数据和文件系统的自由空间跟踪区域。这将简化并提高性能。只要这种预分配足以在检查点之间保留所有数据，就可以了。随着存储设备的改进，随着时间的推移，这一点不再那么令人担忧

---

日志记录者只是主应用程序环形缓冲区的另一个使用者。消息从线路上读取，添加一个报头（接收到的时间戳等），然后送入环形缓冲区

有三个消费者：

应用程序处理程序（调用业务逻辑）

复制发送方（将邮件复制到辅助服务器）

日志处理程序

应用程序处理程序在journaller上被选通，并完成来自辅助服务器的ack，确保在处理应用程序消息之前，接收到的消息位于辅助服务器的环形缓冲区和本地系统页面缓存中

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

如果你对我们是如何得出这些结论感兴趣，我会非常详细地写下所有这些：