Twitter是如何构建高性能分布式日志的

Twitter构建了DistributedLog服务,以解决分布式系统中的问题。该服务基于Apache BookKeeper,提供可靠的、高吞吐量的日志存储解决方案。通过实现序列化更新,确保了数据的一致性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Twitter是如何构建高性能分布式日志的

在Twitter,他们使用复制日志来解决分布式系统中存在的一系列问题。比如,他们有一个Manhattan分布式键值数据库。该系统采用了一种灵活的最终一致性数据模型,允许开发者以一致性换取低延迟。写入操作会单独应用到数据集的所有副本,Manhattan会保证各个副本的数据最终一致。但是,应用程序在查询一个刚刚更新过的数据集时可能会因为读取的副本不同而获取到不同的数据。

为了防止这种不一致的情况,他们必须针对每个副本以同样的顺序应用所有更新。日志(一个严格有序的操作记录)是实现序列化更新的一种简单方式。在Twitter,还有其它有类似情况的应用程序需要某种日志服务基础设施。于是,他们构建了DistributedLog,一个高性能的“复制日志(replicated log)”服务。近日,Twitter消息团队高级软件工程师Leigh Stewart撰文分享了他们构建该服务的经验。

他们根据自己构建分布式系统的经验,对复制日志服务提出了如下要求:

  • 可靠性:稳定,而且在出现各种常见问题(网络划分、集群拓扑变化、流量峰值等)时都能提供可以预见的性能;

  • 高吞吐量:在高峰时段可以支持每秒数以百万计的消息传递;

  • 低延迟:始终如一的低延迟;

  • 工作负载隔离:在一个以日志为中心的分布式系统中,工作负载可以分为如下三类:写日志尾、读日志尾和“追赶读(catch-up read)”。各类负载互不影响;

  • 可扩展性:在地理、节点数量、每秒请求数、数据规模、租户数量等各个维度可扩展;

  • 可操作性:在扩展时易于操作,比如可以很容易地增加或移除节点;

  • 简单:接口简单,便于开发人员使用。

为了满足上述需求,他们评估了几种可选方案,其中包括:(一)使用类似Kafka的发布/订阅系统;(二)使用类似PaxosRaft的一致性算法构建新的服务或库;(三)使用一种像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,提供一种可以满足上述需求的、端到端的服务,如下图所示:



BookKeeper提供稳定性和高可用的日志段存储;DistributedLog提供简单的抽象,如命名、数据分割、保留策略等;应用程序层负责分区、路由、偏移量管理等高级特性。其中,DistributedLog具有如下特性:

  • 面向流的抽象:DistributedLog只暴露了一些简单的实体,在大多数情况下,用户都只需考虑将数据附加到一个已命名的流对象上;

  • 命名和元数据:DistributedLog提供了一种永久命名和元数据方案,用户可以将已命名的日志或主题视为Ledgers集合的替代;

  • 日志归属方案:BookKeeper没有规定一种专门的日志所有者方案,因此,DistributedLog实现了一种基于ZooKeeper的方案;

  • 数据管理策略:DistributedLog允许用户针对不同的场景调整数据保留策略,并提供了一种将日志分段以便在存储节点间平衡数据分布的控制机制;

  • 可调节的读写通道:在写入路径上,DistributedLog提供了一种高度可调节的批处理机制;在读取路径上,它提供了一种可调节的预读机制;

  • 高效“扇入(fan-in)”和“扇出(fan-out)”的服务层DistributedLog是一个专门针对多租户数据中心环境优化过的服务层,可以通过聚合来自多个数据源的写入来支持不关注日志归属的应用程序。在有成千上万的读者消费同一数据流的情况下,该服务可以通过缓存日志数据优化读取路径;

  • 跨地理位置复制日志:可以保证日志跨多个数据中心可用;

在过去的两年里,DistributedLog解决了许多分布式系统中颇具挑战性的问题,其本身也在发展。事实证明,基于DistributedLog的一致性写入路径非常可靠,而且性能令人称赞。将DistributedLog引入Manhattan的写入路径平均仅仅增加了10毫秒的写入延迟。


相关参考资料:

1. http://chuansong.me/n/2078071

2. http://distributedlog.io/html/


资源下载链接为: https://pan.quark.cn/s/1bfadf00ae14 “STC单片机电压测量”是一个以STC系列单片机为基础的电压检测应用案例,它涵盖了硬件电路设计、软件编程以及数据处理等核心知识点。STC单片机凭借其低功耗、高性价比和丰富的I/O接口,在电子工程领域得到了广泛应用。 STC是Specialized Technology Corporation的缩写,该公司的单片机基于8051内核,具备内部振荡器、高速运算能力、ISP(在系统编程)和IAP(在应用编程)功能,非常适合用于各种嵌入式控制系统。 在源代码方面,“浅雪”风格的代码通常简洁易懂,非常适合初学者学习。其中,“main.c”文件是程序的入口,包含了电压测量的核心逻辑;“STARTUP.A51”是启动代码,负责初始化单片机的硬件环境;“电压测量_uvopt.bak”和“电压测量_uvproj.bak”可能是Keil编译器的配置文件备份,用于设置编译选项和项目配置。 对于3S锂电池电压测量,3S锂电池由三节锂离子电池串联而成,标称电压为11.1V。测量时需要考虑电池的串联特性,通过分压电路将高电压转换为单片机可接受的范围,并实时监控,防止过充或过放,以确保电池的安全和寿命。 在电压测量电路设计中,“电压测量.lnp”文件可能包含电路布局信息,而“.hex”文件是编译后的机器码,用于烧录到单片机中。电路中通常会使用ADC(模拟数字转换器)将模拟电压信号转换为数字信号供单片机处理。 在软件编程方面,“StringData.h”文件可能包含程序中使用的字符串常量和数据结构定义。处理电压数据时,可能涉及浮点数运算,需要了解STC单片机对浮点数的支持情况,以及如何高效地存储和显示电压值。 用户界面方面,“电压测量.uvgui.kidd”可能是用户界面的配置文件,用于显示测量结果。在嵌入式系统中,用
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值