推ter开源分布式高性能日志复制服务-DistributedLog

   <p>日前，推ter在 <a href="/misc/goto?guid=4959673444881753441" rel="nofollow,noindex" style="line-height: 1.6;">Github</a> 上基于Apache 2许可证协议 <a href="/misc/goto?guid=4959673444972581209" rel="nofollow,noindex" style="line-height: 1.6;">开源了其日志服务DistributedLog（DL）</a> 。DL是一个高性能的日志复制服务，提供了持久化、复制以及强一致性的功能，这对于构建可靠的分布式系统都是至关重要的，如复制状态机（replicated-state-machines）、通用的发布/订阅系统、分布式数据库以及分布式队列。</p>    <p>DistributedLog会分类维护记录的序列（sequences of records），并将其称为Log（又叫做Log Stream），将记录写入到DL Log的进程称之为Writer，从Log中读取并处理记录的进程称之为Reader。因此，它整体的软件栈如下所示：</p>    <p><img src="https://simg.open-open.com/show/ada1cfab98c4da7a6dcb243d998422f5.png"></p>    <p>具体来讲，它包含如下几个组成部分：</p>    <p><strong>Log</strong></p>    <p>Log是有序的、不可变的日志记录（log record），它的数据结构如下所示：</p>    <p><img src="https://simg.open-open.com/show/bdfa5faca04009f15042750efde4c073.png"></p>    <p><strong>日志记录</strong></p>    <p>每条日志记录都是一个字节序列。日志记录会按照序列写入到日志流中，并且会分配一个名为DLSN（分布式序列号，DistributedLog Sequence Number）的唯一序列号。除了DLSN以外，应用程序还可以在构建日志记录的时候设置自己的序列号，应用程序所定义的序列号称为TransactionID（txid）。不管是DLSN还是TransactionID都能用来定位Reader，使其从特定的日志记录开始读取。</p>    <p><strong>Log分段（Log Segments）</strong></p>    <p>Log会被分解为Log分段，每个分段中包含了其记录的子集。Log分段是分布式的，应该放到Log分段存储中（如BookKeeper）。DistributedLog会基于配置好的策略来轮询每个Log分段，要么是可配置的时间段（如每两个小时），要么是可配置的最大规模（如每128MB）。所以Log的数据将会分为同等大小的Log分段，并且均匀分布到Log分段存储节点上。这样，Log的存储就不会局限于单台服务器的限制，同时，能够在集群中分散读取的流量。</p>    <p>Log的数据可以永远保存，直到应用程序显式地将其截断，也可以在一个可配置的时间段内保存。对于构建复制状态机来说，显式截断会非常有用，如分布式数据库。在数据何时能够截断这一点上，它们往往有着严格的控制。基于时间保留Log对于实时分析的场景更为有用，它们只关心一定时间内的数据。</p>    <p><strong>命名空间</strong></p>    <p>属于同一组织的Log流通常会归类在同一个命名空间（namespace）下，并据此进行管理。DL的命名空间基本上就是用来定位Log流在何处的。应用程序可以在某个命名空间下创建和删除流，也能将某个流截断到给定的序列号上（DLSN或TransactionID均可以）。</p>    <p><strong>Writer</strong></p>    <p>Writer会将数据写入到它们所选择的Log中。所有的记录都会按照顺序添加到Log之中。序列号是由Writer所负责的，这就意味着对于某个Log，在给定的时间点上，只能有一个激活的Writer。当出现网络分区（network partition），导致两个Writer试图往同一个Log进行写入的时候，DL会保证其正确性，这是通过Log分段存储的屏障（fencing）来实现的。</p>    <p>Writer由名为Write Proxy的服务层来提供和管理，Write Proxy用来接受大量客户端的fan-in写入。</p>    <p><strong>Reader</strong></p>    <p>Reader会从它们所选择的Log中读取记录，这会在一个给定的位置开始。这个给定的位置可以是DLSN，也可以是TransactionID。Reader将会严格按照Log的顺序读取记录。在同一个Log中，不同的Reader可以在不同的起始位置读取记录。</p>    <p>与其他的订阅/发布系统不同，DistributedLog并不会记录/管理Reader的位置，它将跟踪的任务留给了应用程序本身，因为不同的应用在跟踪和协调位置上可能会有不同的需求，很难用一种方式就将这些需求全部解决。在应用程序层面，借助各种存储（如ZooKeeper、FileSystem或Key/Value存储）能够很容易地跟踪Reader的位置。</p>    <p>Log记录可以缓存在名为Read Proxy的服务层中，从而应对大量Reader的读取。</p>    <p><strong>Fan-in与Fan-out</strong></p>    <p>DistributedLog的核心支持单Writer、多Reader的语义。服务层构建在DistributedLog Core之上，支持大量的Writer和Reader。服务层包含Write Proxy和Read Proxy，Write Proxy管理Log的Writer，并且在机器宕机时，能够对它们进行故障恢复。它能够从众多来源聚集Writer，允许不必关心Log的所有权（又称为Fan-in）。Read Proxy通过将记录放到缓存中，优化了Reader的读取路径，以应对成百上千的Reader读取同一个Log流的状况。</p>    <p>作为一个日志服务，DistributedLog的优势可以总结为:</p>    <ul>     <li>高性能：面对大量的并发日志时，在可持久化的Writer上DL能够提供毫秒级的延迟，同时还能应对上千客户端每秒大量的读取和写入操作。</li>    </ul>    <ul>     <li>持久化和一致性：消息会持久化到磁盘上，并且以副本的形式存储多份，从而避免丢失。通过严格的顺序，保证Writer和Reader之间的一致性。</li>    </ul>    <ul>     <li>各种工作负载：DL支持各种负载，包括延迟敏感的在线事务处理（OLTP）应用（如分布式数据库的WAL和基于内存的复制状态机）、实时的流提取和计算以及分析处理。</li>    </ul>    <ul>     <li>多租户：针对实际的工作负载，DL的设计是I/O隔离的，从而支持多租户的大规模日志。</li>    </ul>    <ul>     <li>分层架构：DL有一个现代化的分层设计，它将有状态的存储层与无状态的服务提供层进行了分离，能够使存储的扩展独立于CPU和内存，因此支持大规模的写入fan-in和读取fan-out。</li>    </ul>    <p> </p>    <p>来自： http://www.infoq.com/cn/news/2016/05/推ter-Github-DistributedLog</p>    <p><br>  </p>