Facebook开源了他们的内部分布式日志存储项目LogDevice。它通过复制、持久日志存储和故障恢复实现写入高可用性。
Facebook 的大多数需要记录日志应用程序都需要写入高可用性、持久的日志存储以及在性能和延迟方面要求各不相同的工作负载。另一个非常重要的要求是能够承受硬件故障。Facebook 有一个叫作 Scribe 的旧项目侧重于将日志聚合到集中式存储中，但这种方案存在数据丢失的情况。Scribe 现在使用 LogDevice 作为日志存储后端。
Facebook 将 LogDevice 用在数据中心内部的流式处理管道、数据库索引更新的发布、机器学习管道、复制管道和持久任务队列（每秒摄取超过 1TB 的数据）中。尽管 Facebook 已经构建了很多用于管理 LogDevice 集群的开源工具，但还没有将它们开源出来，除了一些基本的工具集。 LDShell 工具可用于从命令行管理集群，并且可以使用 LDQuery 命令来查看集群统计信息。
LogDevice 使用“日志记录”抽象来划分单个日志事件，为每个记录分配一个称为日志序列号（LSN）的唯一 ID。LSN 由“Sequencer”组件基于时间点生成，而时间点保存在 ZooKeeper 中。LogDevice 只能以追加的模式写入记录，也就是说，一旦写入记录就无法修改。与大多数日志存储系统一样，LogDevice 会“修剪”记录，即基于时间或空间策略的日志轮换。它还可以按需进行日志修剪。除此之外，对日志的存储时间没有限制。
LogDevice 通过在不同的计算机节点上存储每个日志记录的多个副本来实现高可用性，尤其是写入高可用性。每条记录可以跨20-30 个存储节点复制。不过，如果某些具有某条日志副本的计算机速度很慢或不可用，那么该日志写入次数的增加会限制吞吐量。LogDevice 可以自动检测哪些节点已失效，并不再往这些节点写入新记录。它试图通过尽可能多的复制尽减少硬件故障的影响，并尽可能快地“重建”丢失的副本。在重建过程中，“可以以每秒5-10GB 的速率进行恢复”。LogDevice 底层存储基于RocksDB，它也是由Facebook 开源的一个键值存储系统。
LogDevice 团队还必须应对其他挑战，他们发现，LogDevice 的用户会执行回填（backfill），请求几个小时或几天内的旧数据。这些请求由使用 LogDevice 日志的下游服务发出，当这些服务从故障中恢复并重新处理日志时就会发生回填。LogDevice 通过在“节点集”之间分摊读取负载来应对这些读取高峰。
LogDevice 可以与 Apache BookKeeper 和 Apache Kafka 等其他日志存储系统进行对比。其中与 Kafka 的主要区别似乎是LogDevice 将计算和存储进行了分离，主要是为了应对Facebook 规模的日志。LogDevice 是用C++ 开发的，并托管在 GitHub 上。
查看英文原文： Facebook Open Sources LogDevice - a Distributed Data Store for Log Storage
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论 1 条评论