《基于NS3的分布式消息系统Kafka的仿真实现》-工学论文，软件工程论文-论文范文参考-科学狗论文网

标题

基于NS3的分布式消息系统Kafka的仿真实现

范文

马浩然

摘要：在数据已渗透到我们生活的各个领域的时代，人们对于数据的挖掘和使用愈发频繁。作为以消息为单位进行数据共享的分布式架构，分布式消息系统成为数据处理的核心技术。传统的分布式消息系统大多用于处理数据量小的关键性数据，然而在信息剧增的今天，人们对信息的关注领域在不断扩大，挖掘的信息量在不断增多，传统的消息处理架构已不能满足我们对数据的处理需求，一个高吞吐量，可实时消费的高性能分布式消息系统成为必需。Kafka即是一种处理海量数据的分布式消息系统。本文总结了Kafka系统的特征和架构策略，对其进行抽象建模，通过网络仿真工具NS3，设计实际系统的场景部署，最后运行仿真系统，得出数据并分析，以帮助我们理解和评估Kafka分布式消息系统。

关键词：计算机软件；分布式消息系统；卡夫卡；网络仿真模拟器

中图分类号：TP311.5

文献标识码：A

1 相关背景及技术

1.1分布式消息系统的概念

分布式系统是指分散的物理机通过互联网连接建立起的一套软件系统，具有高度的内聚性和透明性。分布式环境中需要进行大量，高效，可靠的数据传输，而不同平台之间协议的多样性，不兼容性提高了分布式交互的复杂度。因此，能在客户端和服务端提供同步和异步的连接，实现应用程序之间的协同，保证不同平台之间高效通信的消息中间件机制得以采用。综上所述，基于消息中间件机制的分布式架构即称为分布式消息系统。

1.2分布式消息系统的发展

消息中间件机制的不同，决定了分布式消息系统架构迥然而异，最直接且关键的影响是消息处理模式的不同。在分布式系统发展初期，消息的传递采用的是点对点的通道模式，即发送方处理消息时需明确注明接收方的地址，尽管发送方和接收方是松耦合连接，相互通信不需要保持同步，但过于依赖地址和通道，使得系统不够灵活，难以扩展尤其是消息应用面向企业级发展后，数据集远远扩大，点对点模式的更加暴露了点对点通道模式的局限性。因此，消息中间件开始向发布/订阅模式转变，并逐渐成为目前消息处理的一种核心模式。与点对点模式不同，发布/订阅模式中的发送方并不将消息发送给特定的接收方，而是将消息分类发送给消息代理方，接收方通过与代理方通信，接收自己感兴趣的消息。即消息的“发布者”与“订阅者”并不直接关联，这种发送方与接收方的解耦增强了系统的可扩展性。目前比较典型的发布/订阅中间件包括Microsoft MSMQ，RabbitMQ，ActiveMQ，以及Kafka等等。

1.3什么是Kafka？

Kafka由社交网站Linkedin开发，为系统日志的实时处理提供数据“管道”。Kafka采用的是发布/订阅的消息处理模式，用于低延时环境下收集和提交海量日志数据，且适用于实时和离线的消息处理。

作为一个相对新颖的分布式发布/订阅消息系统，Kafka有着自己独特设计策略：1吐吞量，是Kafka最关键的特性，Kafka设计初衷就是用来处理海量的系统日志；2持久化消息存储，对于海量且安全性不高的消息，考虑开销代价，Kafka采用的是本地文件系统的存储方式，且存储设计采用高效的Partition机制。3Pull模型，Kafka采用消费者主动从代理获取消息的“拉”模型消费机制，消费状态保存在消费端，而不在服务端。4基于zookeeper的负载均衡，Kafka使用分布式协调服务zookeeper来管理和平衡客户端负载。

1.4网络仿真工具NS3

研究网络系统必然需要实际的网络环境，但实现真实的网络系统往往代价很高，尤其是分布式系统。因此，网络仿真就成为我们首选方法。所谓网络仿真就，就是使用计算机程序对网络通信进行模型抽象，模仿真实网络的特征和行为，并通过程序的运行得出可靠的数据，为研究提供分析和验证。

当前有许多优秀的网络仿真软件，本文中采用的是NS3（Network Simulator 3）。NS3是一种面向网络系统的离散事件仿真软件，由C++和Python语言编写，适用于Linux，Unix等多种操作系统。它包含了网络组件的模拟接口，如网络传输协议，通信媒介，socket服务，客户端/服务端应用程序等；事件调度器，以供执行相关事件，用来模型实际中的通信“行为”；以及基于文本的跟踪日志，非常方便仿真结果的分析。

本文使用NS3仿真工具对分布式消息系统Kafka进行抽象建模，模拟出现实网络通信场景；通过应用程序实现消息的生产者，消费者和代理者，消息数据的设计，基于主题的分类方法，基于partition的存储策略，基于队列的发送和接收方式，基于zookeeper的调度管理和负载均衡策略等等；通过不同的参数模拟不同场景的运行状况，得出数据并进行分析。

2 仿真建模

2.1架构设计

阐明一个分布式系统首先需解释它的物理拓扑和逻辑拓扑。物理拓扑描述的是系统的各个部分相互连接而成的结构。逻辑拓扑反映的系统各个部分的职能区别和交互关系。

本文实现的仿真系统采用的是星形物理拓扑结构，即使用一个“全局路由”作为中心节点，网络中的其它节点均与中心节点连接，任意两个节点间的通信均要通过中心节点，发送消息需先发送到中心节点，中心节点再负责将消息转发至目的节点，如图1所示。

NS3工具封装了节点类，以代替实际网络中的主机，它模拟了现实中的网卡设备，协议栈，驱动程序，IP地址等功能，以及作为中心节点的“全局路由”节点。本文通过使用这些模板类来搭建仿真系统的物理模型。

本文所述的逻辑拓扑反应的是研究对象Kafka的架构策略。Kafka是一个基于主题分类的发布/订阅系统，包括消息的生产者（producer），消费者（consumer），代理者（broker）和管理者（zookeeper）四个主体，生产者和消费者与代理者分别进行消息传输，其行为称作“发布”和“订阅”，代理者提供相关的存储介质和存储策略，负责消息的持久化存储和转发。管理者负责协调，分配其它三个主体之间的交互，保证系统的处于平衡状态。如图2所示。

NS3工具封装了包类，socket服务类和应用程序类。本文使用包类模拟实际网络中的数据载体，即消息；socket类模拟实际网络的发送，接收；应用程序类是本系统的关键所在，我们用它来模拟Kafka的“参与者”及其设计思想，如基于partition存储策略的代理者，基于Pull模型的消费者，基于zookeeper进行调度管理和负载均衡的管理者等。

2.2细节实现

基于前两章所述，本文在NS3仿真工具下实现以下仿真系统，本节将对系统的关键模块和实现策略进行详细描述。

2.2.1创建物理拓扑

上节已经提过仿真系统物理拓扑的实现方法，这里使用NS3节点类，设置三个节点容器，分别储存生产者，消费者和代理者节点。用户可任意添加每种节点的数目，且为每个节点添加虚拟网卡，传输协议，IP地址等，保证节点间的正常通信。其中影响系统性能的两个关键属性：节点与节点间的传输速率和延迟。

2.2.2数据载体一消息

实际网络通过包的形式封装数据进行收发，NS3使用了同样的设计思想。每一个网络包代表一条消息，仿真中一个消息包含两个组成部分，真实数据和元数据。与真实网络不同的是，在仿真中使用的“真实数据”实际上是一个虚拟的零字节缓存，并不占据内存空间，仅仅代表一条消息的负载大小；元数据是用来描述真实数据信息的数据，尽管它不是我们需要消费的信息，但对我们至关重要，在运行过程中起着解释和控制的作用，这也是本文关于消息设计的关键所在。本系统通过继承标签基类设计出一个消息标签MsgTag，它包含三部分基本信息：1）真实数据信息；如消息主题，消息编号，消息大小。2）位置信息。如生产者序号，所属partition序号，消费偏移量值。3）时间信息。每条消息的生产时间，发布时间，被请求消费时间，获得消费时间等，这里的“时间”指的是NS3仿真模拟器控制的离散时间轴的上某一时间点。在仿真系统中，应用程序负责维护以上标签信息，并根据它们控制程序的进度和方向。

2.2.3生产者Producer

通过继承应用程序基类设计生产者模型。生产者首先依据参数生产相关主题，数量和大小的消息，其中消息大小采用指定范围随机数；然后生产者向管理者“询问”可用代理，获取发布目的地址，调用底层Socket服务与之连接；最后生产者将消息加入发送队列，并设置发送时间间隔，将消息发送给代理。

2.2.4消息代理Broker

代理者模型同样通过继承应用程序基类实现，它的主要功能包括消息的接收和存储两部分。

与真实网络的socket服务一样，NS3仿真系统的socket也会将超过指定大小的消息进行拆分，分别进行发送和接收，所以在接收方需要将被拆分的“碎片包”进行重组。NS3没有提供相关的组包方法，但提供了可用的字节标签接口，字节标签标记了每个包的拆分位置。Broker模块采取队列的形式来接收包，通过字节标签来判断“碎片包”是否为同一个包，并进行重组。

Kafka依赖于本地的文件系统进行持久化存储。且存储策略基于partition机制，即每个话题（Topic）分为若干个partition，每个partition分为若干个segment，每个segment存储若干条消息。代理接收到消息后会依次顺序添加至segment文件，且每条消息使用位偏移量进行记录。基于这些设计思想，Broker模型设计持久化存储采用了Map和Vector嵌套的数据结构，其中Topic是以主题和Partition为键值对的Map结构，partition和segment分别为vector结构。此外，为Broker添加一个负载等级属性，它会根据Broker存储的消息数量进行更改，反应了每个消息代理的空间负载程度。

2.2.5消费者Consumer

消费者模型同样继承应用程序基类，它的主要功能包括发送请求，接收并存储消息，消息数据的分析。

上文提到Kafka的消息分类基于主题，存储基于partition和segment，记录基于位偏移量offset，因此消费者模型的消费思路为：将需要消费信息的主题和位偏移量发送给管理者，管理者根据主题寻找可消费的Broker，根据位偏移量寻找消息的partition和segment位置，并将结果返回给消费者，消费者根据收到的结果与对应Broker通信，取回消息。这个过程体现了Kafka的其中一个设计思想：Pull模型。

消费者接收和存储消息采用了Broker模型的组包算法和存储结构。但在本系统的消费者模型中，我们更加关心消费结果，即一条消息从生产者产生，经Broker存储，最后由消费者消费的过程中消息发生的变化，它体现在上文提到的消息元数据中。NS3提供了时间戳接口，消息在关键的生产，存储，消费等关键动作时，使用此接口方法为其添加对应时间轴点的时间戳，并存储在消息元数据中。当消费者消费一条消息后，可以从其元数据的时间戳属性中得到此消息的生产，存储时和消费时间等等，通过对比这些信息，我们可以对系统的功能和性能进行评估和进一步研究。

2.2.6管理者Zookeeper

Zookeeper是一个针对大型分布式系统的协调服务，Kafka使用它来协调控制分布式网络中各个节点的通信，维护系统的负载均衡，本系统通过继承应用程序基类模拟Zookeeper。它的功能包括两大部分：1）维护系统信息。这里使用了Map嵌套结构生成一个节点信息表和一个代理消息存储表。每个生产者，代理者和消费者节点被创建时都会在节点信息表中注册基本信息，如节点名称，编号，IP地址，运行状态等等；Broker在存储消息时会在代理消息存储表中注册每条消息的位置信息，如Broker序号与主题的对应关系，每个主题下的partiton和segment与消息的对应关系。2）协调控制节点间的通信。这里包含两个重要算法，一是生产者发布消息时对代理的选择，zookeeper模块通过对比代理的负载等级选取负载最轻的代理节点返回给发布者，这样可以保证代理系统的空间负载趋于平衡状态。二是消费者请求消费时对代理的选择，zookeeper通过代理的运行状态选取最“闲”的代理节点返回给消费者，这样保证最大程度减轻代理系统的通信压力，提高总体系统的性能。

3 设计场景并运行

为验证仿真系统与Kafka系统的一致性，我们通过设置参数设计如下场景：

1.为系统添加3个生产者，4个代理者，和2个消费者；

2.设置消息大小为100字节，3个生产者分别发布8000，5000，11000条消息；

3.每个代理者存储结构负责管理10个主题，每个主题分为10个partition，每个partition分为100个segmentfile，每个segmentfile可存储100条消息；

4.两个消费者采用随机消费的方式进行消费，分别消费300和1100条消息。

运行上述场景，得出数据，这里我们选取了其中一个代理节点和一个消费节点的信息数据进行分析。如图3.1-3.3。

图3.1为仿真系统代理节点得到的部分实际数据，图3.2，图3.3描述了生产者从发布消息和代理者接收消息的时间趋势，以及他们的时间差。由图中曲线可以看出，接收时间滞后于发布时间，接收时间差在开始会有一个比较高的峰值，之后趋于平稳，初步估计由于系统的调度和下层网络连接导致的。

图4.1为仿真系统中消费者节点得到的部分实际数据，从中根据包标签属性可以看出符合我们随机消费的要求。图4.2，图4.3描述了消息消费的时间趋势和时间差，由图中看出它们并没有明显的规律可循。这是因为Kafka采取了与传统系统不同的消费模式：PULL模型。“拉”模型以消费者为主动方发起消费行为，这使得消息的大小，类型，存储位置等都会影响到其被消费的时间延迟。

4 结论

作为新一代分布式消息系统，在大数据背景下的今天，Kafka为我们处理海量数据提供了研究方向。本文对分布式消息系统Kafka进行了抽象建模，并基于网络仿真工具NS3模拟实现了其基本功能，最后设计场景并运行程序，得到相关数据并进行了分析。以上工作旨在深入了解分布式消息系统Katka的设计架构，理解其基本原理，工作流程和异于传统架构的特征，为之后的相关研究提供基本思路和工作环境。

随便看

科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。