DistributedLog介绍及与Kafka比较

一、背景介绍

Distributed是Twitter 2016年5月份开源的一个分布式日志系统。在Twitter内部已经使用2年多。

主页：http://distributedlog.io/

代码：https://github.com/twitter/distributedlog

介绍：

1、Building DistributedLog: Twitter’s high-performance replicated log service

  https://blog.twitter.com/2015/building-distributedlog-twitter-s-high-performance-replicated-log-service

2、【年度案例】Twitter高性能分布式日志系统架构解析

 

二、架构介绍

2.1 数据存储

 

数据模型

Log Segment：应用程序看到的Log 流是连续的，但物理存储是一个个的Log Segment。

1、  同一个Log Segment上的Replica Configuration是一样的

2、  Log Segment可以设置按时间或者按大小，创建新的。

3、  Log Segment 分布式的存储在 Log Segment Store中。

4、  系统中的Log Segments最终会分散在各个节点上，数据读取就不会产生热点节点。

5、  Log Segment也是数据保留单元。即可以按照超时时间配置TTL，也可手动truncate。

 

Log Sequence Number

 日志记录（Log Record）被顺序的写入Log Stream中，并且被分配一个DLSN（DistributeLog Sequence Number）。Writer自动分配的。

DLSN = LSSN + EID + SID

LSSN：Log Segment Sequence Number    -- 属于哪个Log Segment 。

EID：Entry ID                         -- 在这个Log Segment中的ID。

SID：Slot ID                          -- 在 Entry 中的ID。

 

日志记录可以根据DLSN排序。

 

除了DLSN，应用程序还可以分配一个 Transaction ID（递增的64位正整数）。比如一个常见的场景是，应用把记录生成时的timestamp作为记录的Transaction ID。在继续数据分析时，应用可以根据这个Transaction Id倒回到指定的时刻的日志。

 

命名空间(Name Space)

   属于相同的应用下的日志流（Log Streams）被归类到同一个命名空间（namespace）下。

应用根据命名空间定位日志流。应用能够在命名空间下创建和删除日志流，或者指定日志流ID，切除（truncate）日志流。

 

2.2读写过程

持久化存储

   DL的存储层（Storage Layer），提供持久化、可用性和一致性等核心功能。存储层的主要组件有日志段存储（Log Segment Store）、冷数据存储（Cold Storage）、元数据存储（Metadata Store）。

 

日志段存储（Log Segment Store）

  使用BookKeeper做日志段的存储。BookKeeper提供从写入到读取的E2E的低时延、多副本的存储能力，并且通过fencing机制，在多份写时，能够提供强一致性。