消息中間件選型分析——從Kafka與RabbitMQ的對(duì)比來看全局?

本文收錄于InfoQ，未經(jīng)允許不得轉(zhuǎn)載。

歡迎支持筆者新作：《深入理解Kafka:核心設(shè)計(jì)與實(shí)踐原理》和《RabbitMQ實(shí)戰(zhàn)指南》，同時(shí)歡迎關(guān)注筆者的微信公眾號(hào)：朱小廝的博客。

一、前言

消息隊(duì)列中間件（簡(jiǎn)稱消息中間件）是指利用高效可靠的消息傳遞機(jī)制進(jìn)行與平臺(tái)無關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進(jìn)行分布式系統(tǒng)的集成。通過提供消息傳遞和消息排隊(duì)模型，它可以在分布式環(huán)境下提供應(yīng)用解耦、彈性伸縮、冗余存儲(chǔ)、流量削峰、異步通信、數(shù)據(jù)同步等等功能，其作為分布式系統(tǒng)架構(gòu)中的一個(gè)重要組件，有著舉足輕重的地位。

目前開源的消息中間件可謂是琳瑯滿目，能讓大家耳熟能詳?shù)木陀泻芏?，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管選擇其中的哪一款，都會(huì)有用的不趁手的地方，畢竟不是為你量身定制的。有些大廠在長(zhǎng)期的使用過程中積累了一定的經(jīng)驗(yàn)，其消息隊(duì)列的使用場(chǎng)景也相對(duì)穩(wěn)定固化，或者目前市面上的消息中間件無法滿足自身需求，并且也具備足夠的精力和人力而選擇自研來為自己量身打造一款消息中間件。但是絕大多數(shù)公司還是不會(huì)選擇重復(fù)造輪子，那么選擇一款合適自己的消息中間件顯得尤為重要。就算是前者，那么在自研出穩(wěn)定且可靠的相關(guān)產(chǎn)品之前還是會(huì)經(jīng)歷這樣一個(gè)選型過程。

在整體架構(gòu)中引入消息中間件，勢(shì)必要考慮很多因素，比如成本及收益問題，怎么樣才能達(dá)到最優(yōu)的性價(jià)比？雖然消息中間件種類繁多，但是各自都有各自的側(cè)重點(diǎn)，選擇合適自己、揚(yáng)長(zhǎng)避短無疑是最好的方式。如果你對(duì)此感到無所適從，本文或許可以參考一二。

二、各類消息隊(duì)列簡(jiǎn)述

ActiveMQ是Apache出品的、采用Java語(yǔ)言編寫的完全基于JMS1.1規(guī)范的面向消息的中間件，為應(yīng)用程序提供高效的、可擴(kuò)展的、穩(wěn)定的和安全的企業(yè)級(jí)消息通信。不過由于歷史原因包袱太重，目前市場(chǎng)份額沒有后面三種消息中間件多，其最新架構(gòu)被命名為Apollo，號(hào)稱下一代ActiveMQ，有興趣的同學(xué)可行了解。

RabbitMQ是采用Erlang語(yǔ)言實(shí)現(xiàn)的AMQP協(xié)議的消息中間件，最初起源于金融系統(tǒng)，用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息。RabbitMQ發(fā)展到今天，被越來越多的人認(rèn)可，這和它在可靠性、可用性、擴(kuò)展性、功能豐富等方面的卓越表現(xiàn)是分不開的。

Kafka起初是由LinkedIn公司采用Scala語(yǔ)言開發(fā)的一個(gè)分布式、多分區(qū)、多副本且基于zookeeper協(xié)調(diào)的分布式消息系統(tǒng)，現(xiàn)已捐獻(xiàn)給Apache基金會(huì)。它是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，以可水平擴(kuò)展和高吞吐率而被廣泛使用。目前越來越多的開源分布式處理系統(tǒng)如Cloudera、Apache Storm、Spark、Flink等都支持與Kafka集成。

RocketMQ是阿里開源的消息中間件，目前已經(jīng)捐獻(xiàn)個(gè)Apache基金會(huì)，它是由Java語(yǔ)言開發(fā)的，具備高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用等特點(diǎn)，經(jīng)歷過雙11的洗禮，實(shí)力不容小覷。

ZeroMQ號(hào)稱史上最快的消息隊(duì)列，基于C語(yǔ)言開發(fā)。ZeroMQ是一個(gè)消息處理隊(duì)列庫(kù)，可在多線程、多內(nèi)核和主機(jī)之間彈性伸縮，雖然大多數(shù)時(shí)候我們習(xí)慣將其歸入消息隊(duì)列家族之中，但是其和前面的幾款有著本質(zhì)的區(qū)別，ZeroMQ本身就不是一個(gè)消息隊(duì)列服務(wù)器，更像是一組底層網(wǎng)絡(luò)通訊庫(kù)，對(duì)原有的Socket API上加上一層封裝而已。

目前市面上的消息中間件還有很多，比如騰訊系的PhxQueue、CMQ、CKafka，又比如基于Go語(yǔ)言的NSQ，有時(shí)人們也把類似Redis的產(chǎn)品也看做消息中間件的一種，當(dāng)然它們都很優(yōu)秀，但是本文篇幅限制無法窮極所有，下面會(huì)針對(duì)性的挑選RabbitMQ和Kafka兩款典型的消息中間件來做分析，力求站在一個(gè)公平公正的立場(chǎng)來闡述消息中間件選型中的各個(gè)要點(diǎn)。

三、選型要點(diǎn)概述

衡量一款消息中間件是否符合需求需要從多個(gè)維度進(jìn)行考察，首要的就是功能維度，這個(gè)直接決定了你能否最大程度上的實(shí)現(xiàn)開箱即用，進(jìn)而縮短項(xiàng)目周期、降低成本等。如果一款消息中間件的功能達(dá)不到想要的功能，那么就需要進(jìn)行二次開發(fā)，這樣會(huì)增加項(xiàng)目的技術(shù)難度、復(fù)雜度以及增大項(xiàng)目周期等。

1. 功能維度

功能維度又可以劃分個(gè)多個(gè)子維度，大致可以分為以下這些：

優(yōu)先級(jí)隊(duì)列

下表是對(duì)Kafka與RabbitMQ功能的總結(jié)性對(duì)比及補(bǔ)充說明。

作者：朱小廝?

來源：CSDN?

原文：https://blog.csdn.net/u013256816/article/details/79838428?

版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！