Facebook了他们的内部分布式日志存储项目LogDevice。它通过复制、持久日志存储和故障恢复实现写入高可用性。

Facebook的大多数需要记录日志应用程序都需要写入高可用性、持久的日志存储以及在性能和延迟方面要求各不相同的工作负载。另一个非常重要的要求是能够承受硬件故障。Facebook有一个叫作的旧项目侧重于将日志聚合到集中式存储中，但这种方案存在数据丢失的情况。Scribe现在使用LogDevice作为日志存储后端。

Facebook将LogDevice用在数据中心内部的流式处理管道、数据库索引更新的发布、机器学习管道、复制管道和持久任务队列（每秒摄取超过1TB的数据）中。尽管Facebook已经构建了很多用于管理LogDevice集群的开源工具，但还没有将它们开源出来，除了一些基本的工具集。工具可用于从命令行管理集群，并且可以使用命令来查看集群统计信息。

LogDevice使用“日志记录”抽象来划分单个日志事件，为每个记录分配一个称为日志序列号（LSN）的唯一ID。LSN由“Sequencer”组件基于时间点生成，而时间点保存在ZooKeeper中。LogDevice只能以追加的模式写入记录，也就是说，一旦写入记录就无法修改。与大多数日志存储系统一样，LogDevice会“修剪”记录，即基于时间或空间策略的日志轮换。它还可以按需进行日志修剪。除此之外，对日志的存储时间没有限制。

LogDevice通过在不同的计算机节点上存储每个日志记录的多个副本来实现高可用性，尤其是。每条记录可以跨20-30个存储节点复制。不过，如果某些具有某条日志副本的计算机速度很慢或不可用，那么该日志写入次数的增加会限制吞吐量。LogDevice可以自动检测哪些节点已失效，并不再往这些节点写入新记录。它试图通过尽可能多的复制尽减少硬件故障的影响，并尽可能快地“”丢失的副本。在重建过程中，“可以以每秒5-10GB的速率进行恢复”。LogDevice底层存储基于RocksDB，它也是的一个键值存储系统。

LogDevice团队还必须应对其他挑战，他们发现，LogDevice的用户会执行回填（backfill），请求几个小时或几天内的旧数据。这些请求由使用LogDevice日志的下游服务发出，当这些服务从故障中恢复并重新处理日志时就会发生回填。LogDevice通过在“节点集”之间分摊读取负载来应对这些读取高峰。

LogDevice可以与和等其他日志存储系统进行对比。其中与Kafka的似乎是LogDevice将计算和存储进行了分离，主要是为了应对Facebook规模的日志。LogDevice是用C++开发的，并托管在上。

查看英文原文：