干货 | 携程基于BookKeeper的延迟消息架构落地实践

作者简介

 

本文作者magiccao、littleorca，来自携程消息队列团队。目前主要从事消息中间件的开发与弹性架构演进工作，同时对网络/性能优化、应用监控与云原生等领域保持关注。

一、背景

QMQ延迟消息是以服务形式独立存在的一套不局限于消息厂商实现的解决方案，其架构如下图所示。

QMQ延迟消息服务架构

延迟消息从生产者投递至延迟服务后，堆积在服务器本地磁盘中。当延迟消息调度时间过期后，延迟服务转发至实时Broker供消费方消费。延迟服务采用主从架构，其中，Zone表示一个可用区（一般可以理解成一个IDC），为了保证单可用区故障后，历史投递的待调度消息正常调度，master和slave会跨可用区部署。

1.1 痛点

此架构主要存在如下几点问题：

a）服务具有状态，无法弹性扩缩容；

b）主节点故障后，需要主从切换（自动或手动）；

c）缺少一致性协调器保障数据的一致性。

如果将消息的业务层和存储层分离出来，各自演进协同发展，各自专注在擅长的领域。这样，消息业务层可以做到无状态化，轻松完成容器化改造，具备弹性扩缩容能力；存储层引入分布式文件存储服务，由存储服务来保证高可用与数据一致性。

1.2 分布式文件存储选型

对于存储服务的选型，除了基本的高可用于数据一致性特点外，还有至关重要的一点：高容错与低运维成本特性。分布式系统最大的特点自然是对部分节点故障的容忍能力，毕竟任何硬件或软件故障是不可百分百避免的。因此，高容错与低运维成本将成为我们选型中最为看重的。

2016年由雅虎开源贡献给Apache的Pulsar，因其云原生、低延迟分布式消息队列与流式处理平台的标签，在开源社区引发轰动与追捧。在对其进行相关调研后，发现恰好Pulsar也是消息业务与存储分离的架构，而存储层则是另一个Apache开源基金会的BookKeeper。

二、BookKeeper

BookKeeper作为一款可伸缩、高容错、低延迟的分布式强一致存储服务已被部分公司应用于生产环境部署使用，最佳实践案例包括替代HDFS的namenode、Pulsar的消息存储与消费进度持久化以及对象存储。

2.1 基本架构

BookKeeper基本架构

Zookeeper集群用于存储节点发现与元信息存储，提供强一致性保证；

Bookie存储节点，提供数据的存储服务。写入和读取过程中，Bookie节点间彼此无须通信。Bookie启动时将自身注册到Zookeeper集群，暴露服务；

Client属于胖客户端类型，负责与Zookeeper集群和BookKeeper集群直接通信，且根据元信息完成多副本的写入，保证数据可重复读。

2.2 基本特性

a）基本概念

Entry：数据载体的基本单元

Ledge