| 标题 | 基于海量数据消息队列的性能比较及其优化 |
| 范文 | 邰宇 摘 要 互联网的快速发展促进了海量数据的产生，而实时处理海量数据离不开具有良好性能的分布式消息队列，可明显提高数据处理的效率，海量数据采用何种消息队列进行传输是关键问题之一。分析研究应用最频繁的Apache Kafka、Rocket-MQ及Rabbit-MQ三种消息队列特点及实现原理，在实时大数据计算场景下基于此对消息队列分别搭建集群测试环境，比较有关结果后实现对消息队列的性能设计优化。 關键词 海量数据；消息队列；大数据时代 中图分类号 G2 文献标识码 A 文章编号 1674-6708（2018）204-0106-02 1 概述 随着互联网技术的迅速发展，网络日志在主流网站及应用中每日产生的都是海量级的，其数据价值与其产生时间之间存在负相关关系。基于此研发的实时流计算系统，使这些数据体现出最大的价值。将数据向计算系统传输已成为对计算效率产生影响的一个主要瓶颈，结合特定业务场景科学合理地选择分布式消息队列更为适宜，可在一定程度上使实时计算效率明显提高。对不同分布式消息队列在实时计算场景下实时性、并发性、可靠性及扩展能力等方面表现出的差异比较，以确定最优性能的消息队列。 2 消息队列 2.1 Kafka及其基本架构 Kafka是可实现、发布及订阅功能的分布式消息队列系统，生产者生产消息并将指定话题的消息向消息集群中发布，消费者会对消息集群中的指定话题消息主动订阅，中间对持久化消息的存储称为Broker。消息偏移量在消费者中存储，因Kafka消息队列无状态，用于对Kafka中当前消费者的消费状况进行记录。 若某个节点在集群中宕机，系统还能提供正常服务，但容易丢失存储在宕机节点上的信息。无状态的Kafka需消费者定期维护消息队列集群中消费的偏移量，详细记录之前的消费状态。消息偏移量是不连续增量，在对下一个消息位置计算时，应将当前消息长度以原来偏移量为基础进行相加计算。 2.2 Rocket-MQ及其基本架构 Rocket-MQ主要是由服务器端的NameServer、Broker和客户端的Producer、Consumer四种节点组成，其Broker、Producer、Consumer与Kafka具有基本相同的功能。NameServer主要用于提供给Producer和Consumer生产消费的Broker地址，Rocket-MQ集群随着启动的Broker集群，发起连接指定NameServer的请求，Broker将以30s为周期会自动发送具有目的topic消息的一次心跳，同时NameServer每隔两分钟对是否存在心跳进行主动检测，若未检测到心跳，将自动断开连接。若Broker挂掉，也将断开连接，NameServer迅速感知到并将topic和broker的关系更新。但不会向客户端主动通知，在客户端启动时，对部分NameServer指定具体的网址，客户端自动与指定NameServer进行连接，若不能成功连接，客户端就会尝试连接其他NameServer地址，连接成功将每隔30s对路由信息进行查询。 2.3 Rabbit-MQ及其基本架构 由Exchanges与Queues组成的Broker是Rabbit-MQ与其他2种消息队列的主要区别，向Exchanges中push生产者生产的消息，系统利用RoutingKey将找到消息与Queue的对应存储位置。Queue利用routing keys进行绑定，在消息传输中，若消费者对客户端的发送消息正确接收并消费，系统将这条消息从Queue中删除。多个消费者可接收发送来的同一消息，及时将数据向消费者发送后同时在队列中将这条数据删除。 3 实验设计 采用本地虚拟机PC搭建测试环境，对测试主机进行网络配置。对实验系统进行设计，其主要过程为生产者向Broker集群中Push数据，然后对消费者Pull到Broker集群中的数据进行计算。由程序自动生成实验数据，再向Broker集群中存储。预先搭建好Storm实时计算系统，3种消息队列分别与生产者和消费者建立连接，再对消息分别统计分析其生产和消费效率。 4 性能优化设计及实验结果 4.1 创新性 为使数据计算提高准确性，采用全新Kafka消息结构，放弃消费者利用对offset的维护消费Kafka集群中的数据。消费者对数据接口的读取和消费者对数据偏移量接口的修改分别进行重新设计，同时由消费者调用读取数据接口和修改偏移量接口，以确保其消费端具有较高的可靠性。 4.2 消费者可靠性设计 丢失传送消息和重新传送消费过的消息是读取Kafka原生的消费者端数据中比较常见的2个问题，因此，基于此采取可靠性设计方案。将主键Id分别添加到生产者中的每条消息中，在消费者中若检测出重复Id则进行自动过滤，以确保不会重新消费已被消费的消息。确保不丢失传送数据的方法主要是采取消费者同步处理数据和对数据偏移量修改，即消费者将一条数据处理完后再依次将另一条数据依次进行处理。 4.3 测试主要用例 测试主要是实现对以上3种消息队列的磁盘 IO、吞吐量及CPU资源消耗率之间存在差距的比较。正常启动Zookeeper和3个消息队列，测试是将消息队列集群与Storm计算集群启动，push消息队列中100万条准备好的测试数据，对topic分别创建，计算Storm计算集群pull出消息队列中的数据。 4.4 实验结果 通过比较分析以实时流处理场景为基础的吞吐量，Kafka最高，Rabbit-MQ的broker磁盘IO处于瓶颈。Rocket-MQ比较稳定，磁盘IO使用率已接近全部。Rabbit-MQ在消耗CPU资源方面较大。再对服务端处理同步发送的有关消息队列的性能进行比较，Kafka消息队列最高，Rabbit-MQ消息队列最低。 5 结论 综上所述，基于实时流处理业务场景对存储和读取需处理数据的消息队列进行选择十分必要。通过对Kafka消息结构的优化，再比较基于Storm集群实时计算场景中性能较好的3种消息队列，研究结果显示以极大的实时计算数据量和较低延迟的要求为基础，综合评价这3种消息队列的吞吐量、磁盘IO及消耗CPU标准等有关指标，Kafka消息队列的优势比较明显。 参考文献 [1]王岩，王纯.一种基于Kafka的可靠的Consumer的设计方案[J].软件，2016（17）：61-66. [2]马浩然.基于NS3的分布式消息系统Kafka的仿真实现[J].软件，2015（1）：94-99. [3]张鹏，李鹏霄，任彦，等.面向大数据的分布式流处理技术综述[J].计算机研究与发展，2014（s2）：1-9. [4]周京晖.集成消息服务和定时通知的分布式内存数据库[J].软件，2013，34（1）：82-92. [5]谭玉靖.基于ZooKeeper的分布式处理框架的研究与实现[D].北京：北京邮电大学，2014. |
| 随便看 |
|
科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。