在Twitter,他们使用复制日志来解决分布式系统中存在的一系列问题。比如,他们有一个Manhattan分布式键值数据库。该系统采用了一种灵活的最终一致性数据模型,允许开发者以一致性换取低延迟。写入操作会单独应用到数据集的所有副本,Manhattan会保证各个副本的数据最终一致。但是,应用程序在查询一个刚刚更新过的数据集时可能会因为读取的副本不同而获取到不同的数据。为了防止这种不一致的情况,他们必须针对每个副本以同样的顺序应用所有更新。日志(一个严格有序的操作记录)是实现序列化更新的一种简单方式。在Twitter,还有其它有类似情况的应用程序需要某种日志服务基础设施。于是,他们构建了DistributedLog,一个高性能的“复制日志(replicated log)”服务。近日,Twitter消息团队高级软件工程师Leigh Stewart撰文分享了他们构建该服务的经验。
他们根据自己构建分布式系统的经验,对复制日志服务提出了如下要求:
可靠性:稳定,而且在出现各种常见问题(网络划分、集群拓扑变化、流量峰值等)时都能提供可以预见的性能;
高吞吐量:在高峰时段可以支持每秒数以百万计的消息传递;
低延迟:始终如一的低延迟;
工作负载隔离:在一个以日志为中心的分布式系统中,工作负载可以分为如下三类:写日志尾、读日志尾和“追赶读(catch-up read)”。各类负载互不影响;
可扩展性:在地理、节点数量、每秒请求数、数据规模、租户数量等各个维度可扩展;
可操作性:在扩展时易于操作,比如可以很容易地增加或移除节点;
简单:接口简单,便于开发人员使用。
为了满足上述需求,他们评估了几种可选方案,其中包括:(一)使用类似Kafka的发布/订阅系统;(二)使用类似Paxos或Raft的一致性算法构建新的服务或库;(三)使用一种像Apache BookKeeper那样的底层日志服务。对于Kafka,他们对其I/O模型心存疑虑,并认为它缺乏强有力的稳定性保证;Paxos和Raft颇具吸引力,但从头构建一个新系统需要一个很长的开发周期。于是,选项仅剩了Apache BookKeeper。这个最初为HDFS设计的事务日志后台唯一关注的是存储效率和日志段(称为Ledger)检索。另外,不同于Kafka,它并不关注发布/订阅系统中的一些高级特性,如“分区归属(partition ownership)”、面向流的抽象等。以下是Apache BookKeeper的核心优势:
灵活的复制功能:BookKeeper采用了一种基于投票的复制机制。该机制直接由客户端驱动,可以避免引入主次复制方案中存在的延迟,使他们可以屏蔽数据库故障或速度慢的问题,实现可预见的延迟。此外,BookKeeper复制设置高度可配置,并支持可插拔的“副本放置(replica placement)”策略。
卓越的I/O性能:BookKeeper节点使用不同的I/O组件处理上述三种核心日志存储负载,提供了卓越的I/O性能。
因此,他们认定,BookKeeper是一个日志存储的上佳选择。不过,它虽然满足了上面列出的大部分关键需求,但是还缺少一些关键的特性,比如高级抽象、日志归属等。为此,他们在BookKeeper之上构建了一个服务层DistributedLog,提供一种可以满足上述需求的、端
构建高性能分布式日志 来自淘豆网m.daumloan.com转载请标明出处.
