上周Facebook决定共享其分布式日志管理系统，这可能是由于管理大量日志的系统管理员想要一个新的“朋友”了。其中最让人印象深刻的是这样的操作:Facebook声称，在失败后，LogDevice可以重建日志，以“每秒5 Gbps到10 Gbps之间的速度完全恢复受影响的所有记录的复制因子”。

正如《华盛顿邮报》解释的那样，日志记录显示了在无限制规模下两个难以兑现的问题:记录存储高度可用且持久，同时保持“这些记录上的可重复的全部顺序”。

实现这一目标所需的规范如下:

·LogDevice是记录导向的，而不是字节，写在日志上的最小的不可分割的单元是一个完整的记录，该公司说它提供了“在出现问题时更好的写入可用性”;

·日志是附加的，日志记录不能被修改;

·为了管理日志大小，文件可以根据基于时间的或基于空间的保留策略来调整进行修改，然后丢掉最旧的记录。

要获得Facebook所需的规模，关键是将日志序列与记录本身分离开来：测序器作为一个单独的进程运行，无论是在存储节点上还是在其自身的节点上。

这些序号本身并不是整数，而是整数对。“纪元存储区”是一个持久计数器的存储库，每个日志一个，很少递增，而且保证不会倒退。而在今天，我们使用Apache Zookeeper作为LogDevice的纪元存储区。

Facebook的LogDevice

▲LogDevice将排序与对象存储分开

对于日志对象存储，LogDevice将一个记录随机地分配给一个存储节点。那么，假如您没有将某个特定服务器上的所有日志登陆到同一磁盘上，而且万一失败，您也不会丢失全部日志。

这就是快速重建很重要的地方:如果一个记录正在等待被恢复，当第二次失败发生时怎么办?没错，重建的目的就在于此了。

所有的集中化日志自然都来自于本地日志，因此，LogDevice引入了一个名为LogDB的写优化存储，它是一种针对写入优化的数据存储区。它的“设计目的是保持磁盘的数量小且可控，而且存储设备上的写和读取IO模式大多是连续的”。

Facebook表示，希望今年能实现其最终目标：开源的LogDevice。