摘要：?消息隊(duì)列Kafka是一個(gè)分布式的、高吞吐量、高可擴(kuò)展性消息隊(duì)列服務(wù)，廣泛用于日志收集、監(jiān)控?cái)?shù)據(jù)聚合、流式數(shù)據(jù)處理、在線和離線分析等，是大數(shù)據(jù)生態(tài)中不可或缺的產(chǎn)品之一，阿里云提供全托管服務(wù)，用戶無需部署運(yùn)維，更專業(yè)、更可靠、更安全。本文就將帶你走進(jìn)消息隊(duì)列Kafka。

摘要：消息隊(duì)列Kafka是一個(gè)分布式的、高吞吐量、高可擴(kuò)展性消息隊(duì)列服務(wù)，廣泛用于日志收集、監(jiān)控?cái)?shù)據(jù)聚合、流式數(shù)據(jù)處理、在線和離線分析等，是大數(shù)據(jù)生態(tài)中不可或缺的產(chǎn)品之一，阿里云提供全托管服務(wù)，用戶無需部署運(yùn)維，更專業(yè)、更可靠、更安全。本文就將帶你走進(jìn)消息隊(duì)列Kafka。

以下內(nèi)容根據(jù)演講視頻以及PPT整理而成。

本期發(fā)布會視頻分享鏈接，戳這里！
本期發(fā)布會PPT下載鏈接，戳這里！

消息隊(duì)列Kafka
消息隊(duì)列Kafka是一個(gè)分布式的、高吞吐量、高可擴(kuò)展性消息隊(duì)列服務(wù)。相比于Apache Kafka，消息隊(duì)列Kafka所提供的是全托管的服務(wù)。這里也簡單地介紹一下Apache Kafka，Apache Kafka是一個(gè)分布式的基于push-subscribe的消息系統(tǒng)，它具備快速、可擴(kuò)展、可持久化的特點(diǎn)。它現(xiàn)在是Apache旗下的一個(gè)開源系統(tǒng)，作為hadoop生態(tài)系統(tǒng)的一部分，目前被廣泛使用在大數(shù)據(jù)場景中。

而消息隊(duì)列 Kafka 針對Apache Kafka提供全托管服務(wù)，徹底解決開源產(chǎn)品長期以來的痛點(diǎn)。用戶只需專注于業(yè)務(wù)開發(fā)，無需部署運(yùn)維，低成本、更彈性、更可靠。消息隊(duì)列產(chǎn)品最大的特點(diǎn)就是全托管服務(wù)，這里主要涉及到兩個(gè)特性：兼容性和便捷性。首先，對于兼容性，消息隊(duì)列Kafka能夠100%兼容Apache Kafka，對于用戶而言，可使用各種語言的開源客戶端進(jìn)行無縫接入，目前使用開源Kafka的用戶，只需要更改一個(gè)接入點(diǎn)就可以使用消息隊(duì)列Kafka產(chǎn)品。同時(shí)，消息隊(duì)列Kafka兼容Apache Kafka的所有生態(tài)。其次，對于便捷性而言，消息隊(duì)列Kafka不需要部署，用戶只要在購買消息隊(duì)列Kafka后，填入實(shí)例信息，15分鐘內(nèi)就能使用消息隊(duì)列Kafka的服務(wù)了，因此是非常便捷易用的。

上述是對于消息隊(duì)列Kafka的整體介紹，接下來將分為痛點(diǎn)、優(yōu)勢以及場景這三個(gè)模塊與大家進(jìn)行較為細(xì)節(jié)的分享。首先將與大家分享目前阿里云針對于消息隊(duì)列服務(wù)所收集到的用戶痛點(diǎn)，以及根據(jù)這些痛點(diǎn)來解決問題，消息隊(duì)列Kafka所具備的優(yōu)勢又是什么，最后還將與大家介紹一下消息隊(duì)列Kafka所適用的場景。

一、痛點(diǎn)：自建Kafka的煩惱
Apache Kafka運(yùn)維難度大
對于Kafka而言，從用戶視角來看，是一個(gè)非常簡單的產(chǎn)品，其所提供的是發(fā)布與訂閱模型。那么，在對于Kafka進(jìn)行運(yùn)維方面而言，其難度又會非常大，這是因?yàn)樗粌H僅需要關(guān)注整個(gè)集群之內(nèi)像broker、controller類似的角色，還需要關(guān)注其所依賴的一些產(chǎn)品像ZooKeeper等。所以對于以上這些模塊的運(yùn)維不僅僅涉及到參數(shù)的調(diào)優(yōu)，同時(shí)隨著業(yè)務(wù)的增長，還會面臨擴(kuò)縮容等問題。此外，還需要關(guān)注磁盤以及網(wǎng)絡(luò)情況。因此，綜上所述，自建Kafka的運(yùn)維成本和運(yùn)維難度都是非常大的。接下來就為大家分享一些具體的例子。

數(shù)據(jù)混亂
一些用戶反饋在自己使用Kafka集群的時(shí)候出現(xiàn)了數(shù)據(jù)混亂的問題。大家都知道，在Kafka集群里面存在Controller和Broker兩種角色，在Controller出現(xiàn)異常的情況之下，會從Broker里面自動(dòng)地選擇一個(gè)Broker成為新的Controller。但是由于網(wǎng)絡(luò)等異常情況，最開始掛掉的Controller可能重新復(fù)活了，那么在復(fù)活之后，對于整個(gè)集群而言就會出現(xiàn)“腦裂”的情況。因?yàn)镃ontroller的主要職責(zé)是管理整個(gè)集群的分區(qū)和副本的狀態(tài)，而當(dāng)出現(xiàn)“腦裂”就會造成數(shù)據(jù)混亂的問題，而這對于用戶而言，是不可接受的。

ZooKeeper不可用
整個(gè)Kafka集群對于ZK是強(qiáng)依賴的，而ZooKeeper的運(yùn)維工作也是龐大而復(fù)雜的。比如在運(yùn)維人員對于ZooKeeper不是非常了解的情況之下，可能不知道如何部署ZooKeeper，不知道如何保證ZK在同機(jī)房或者多機(jī)房的情況下保證其一定可用，而這些往往需要運(yùn)維人員的思考和權(quán)衡。而ZooKeeper上面會存儲Kafka的重要數(shù)據(jù)，當(dāng)ZK不可用的情況下，整個(gè)集群的災(zāi)備選組以及存儲的數(shù)據(jù)都會受到影響。

帶寬關(guān)注
對于用戶而言，自建Kafka時(shí)不僅僅需要關(guān)注其外圍的依賴產(chǎn)品，其實(shí)還需要關(guān)注一個(gè)在集群內(nèi)部經(jīng)常會遇到的問題——帶寬。站在用戶的使用角度來看，經(jīng)常需要做出對于副本數(shù)的權(quán)衡。而為了提升可靠性以及容災(zāi)能力，集群往往需要三副本，而當(dāng)副本數(shù)量一多，那么就會涉及到機(jī)器之間的數(shù)據(jù)復(fù)制，這種情況就會增加網(wǎng)絡(luò)的帶寬。同時(shí)，由于Broker之間是對等的，并且需要從Controller里面同步數(shù)據(jù)。這樣一來，Controller不僅僅需要承擔(dān)自己的本身的任務(wù)，還需要對外提供服務(wù)，而就其本身的設(shè)計(jì)而言，這兩部分任務(wù)是沒有優(yōu)先級先后的，所以在集群規(guī)模大的情況之下，就會引發(fā)網(wǎng)絡(luò)帶寬的擁堵問題。而阿里云消息隊(duì)列Kafka就已經(jīng)幫助用戶解決了上述問題了，用戶不需要去做備份之間的權(quán)衡，阿里云會幫助用戶實(shí)現(xiàn)數(shù)據(jù)的三副本存儲，并且使得服務(wù)可用性能夠達(dá)到99.9%

磁盤運(yùn)維
用戶自建Kafka還會遇到其他的一些問題，比如磁盤的運(yùn)維問題。從0.110版本之后，Consumer offsets不僅僅存儲在ZK端，其可以作為一個(gè)普通的Topic存儲在Kafka集群里面。而整個(gè)Consumer offsets的留存策略決定了磁盤的占用情況，因此有可能因?yàn)樵O(shè)置了錯(cuò)誤的參數(shù)導(dǎo)致磁盤的占用過高。同時(shí)，用戶經(jīng)常看到的情況是：自己的集群有100T的磁盤，僅僅使用了幾十T就已經(jīng)出現(xiàn)了不可寫的情況。大家都知道，在Producer里面可以通過兩種方式對于數(shù)據(jù)進(jìn)行分區(qū)，通過Hash可能會造成Hash的傾斜，而使用RoundBobin的方式也可能導(dǎo)致磁盤占用不均。對于用戶而言，其可能看到的情況是用戶明明購買了很多的磁盤，磁盤也沒有被占滿，但是Producer卻已經(jīng)不可寫了。而關(guān)于磁盤運(yùn)維的細(xì)節(jié)問題，消息隊(duì)列Kafka就已經(jīng)幫助用戶解決掉了。

數(shù)據(jù)丟失
其實(shí)，對于用戶而言，最苦惱的就是數(shù)據(jù)丟失問題。Kafka為用戶提供了三種數(shù)據(jù)存儲策略，第一種可以認(rèn)為是OneWay方式，第二種相當(dāng)于將一個(gè)備份的數(shù)據(jù)落盤，最后一種相當(dāng)于將所有備份數(shù)據(jù)落盤才能成功。對于這三種方式的選擇過程，其實(shí)就是可用性與性能之間的博弈。在網(wǎng)絡(luò)負(fù)載很高或者磁盤很難寫入的情況下，就可能造成磁盤寫入失敗。同時(shí)，Kafka的數(shù)據(jù)最開始是存儲在PageCache上面的，并且會定時(shí)地刷到磁盤上，但是并不是每條消息發(fā)送成功都會存儲在磁盤上的。如果出現(xiàn)斷電或者機(jī)器故障的情況，存儲在內(nèi)存中的數(shù)據(jù)就會丟失。此外，還有一種情況就是當(dāng)單批數(shù)據(jù)量超過限制也會丟失數(shù)據(jù)。而使用消息隊(duì)列Kafka，用戶就不需要去做這些數(shù)據(jù)上面的選型的博弈和考慮，因?yàn)橹灰㈥?duì)列Kafka發(fā)送數(shù)據(jù)成功，那么這些數(shù)據(jù)就會被持久化，保證了數(shù)據(jù)不會丟失。因?yàn)橄㈥?duì)列Kafka做了這些優(yōu)化，數(shù)據(jù)的可靠性就能夠達(dá)到8個(gè)9(即99.999999%)

二、優(yōu)勢
在前面與大家分享了自建Kafka所遇到的痛點(diǎn)，接下來將會結(jié)合上述的痛點(diǎn)與大家分享阿里云消息隊(duì)列Kafka的優(yōu)勢所在以及其是如何解決上述痛點(diǎn)的。

開箱即用
阿里云的消息隊(duì)列Kafka是開箱即用的，是100%兼容Apache Kafka的，原來正在使用Apache Kafka的用戶只需要更改接入點(diǎn)就可以無縫地接入，并且消息隊(duì)列Kafka也能夠支持開源版本所支持的各種客戶端，與此同時(shí)也能夠兼容Apache Kafka的全部生態(tài)。并且消息隊(duì)列Kafka不需要用戶進(jìn)行部署，只需要在購買之后填入用戶的實(shí)例信息，在15分鐘之內(nèi)就能使用消息隊(duì)列Kafka的服務(wù)，非常便捷。

全托管
當(dāng)用戶購買了消息隊(duì)列Kafka之后，阿里云會對于整個(gè)集群進(jìn)行維護(hù)并提供托管服務(wù)，這對于用戶而言，是完全的0維護(hù)成本。這樣的0維護(hù)成本又是怎樣做到的呢？阿里云消息隊(duì)列Kafka提供了秒級的健康巡檢以及自恢復(fù)體系，阿里云有專業(yè)的研發(fā)和運(yùn)維團(tuán)隊(duì)來保障整個(gè)健康巡檢的正常運(yùn)行以及自動(dòng)化維護(hù)體系的可實(shí)施性。對于用戶而言，健康巡檢是整個(gè)托管的基石。那么阿里云又是如何為用戶提供健康巡檢的呢？為用戶所提供的健康巡檢又是哪些內(nèi)容呢？其實(shí)可以分為三個(gè)層次，即機(jī)器維度、業(yè)務(wù)維度以及業(yè)務(wù)性能上面的運(yùn)維。比如阿里云會關(guān)注網(wǎng)絡(luò)是否異常，磁盤是否故障這樣系統(tǒng)級別的運(yùn)維和巡檢。此外，阿里云消息隊(duì)列Kafka還會提供業(yè)務(wù)級別的巡檢，將會關(guān)注生產(chǎn)和消費(fèi)是否正常運(yùn)行，也會關(guān)注Kafka對外提供的整體服務(wù)是否正常運(yùn)行，這些都屬于業(yè)務(wù)層面上的巡檢。從性能上面，也會關(guān)注像磁盤IO請求的速度這樣指標(biāo)，通過磁盤IO請求速度的變化推測出負(fù)載的情況，并進(jìn)行一些告警以及自動(dòng)化的處理。通過上述這樣的健康巡檢方式來檢測集群的健康狀況。

高可靠、高可用
對于消息隊(duì)列Kafka而言，它不僅僅對外承諾服務(wù)的數(shù)據(jù)可靠性達(dá)到了99.999999%以及服務(wù)的可用性達(dá)到了99.9%。消息隊(duì)列Kafka對外承諾的數(shù)據(jù)可靠性和服務(wù)可用性不僅僅是通過健康巡檢來保證的，同時(shí)還做了非常多的優(yōu)化。這里簡單介紹阿里云對于消息隊(duì)列Kafka所做的兩個(gè)優(yōu)化。在存儲層，通過存儲與計(jì)算的分離來實(shí)現(xiàn)優(yōu)化。其次，阿里云消息服務(wù)Kafka還提供了自動(dòng)災(zāi)備，而自動(dòng)災(zāi)備的范圍很大，這里可以簡單列出幾點(diǎn)：第一點(diǎn)就是當(dāng)一個(gè)Broker掛掉的時(shí)候，備用的Broker將會直接啟動(dòng)起來，同時(shí)宕機(jī)的Broker的流量將會自動(dòng)分配到存活的Broker上面，從而實(shí)現(xiàn)了業(yè)務(wù)完全無感知的效果。正是通過以上的方式，阿里云消息隊(duì)列Kafka實(shí)現(xiàn)了極高的數(shù)據(jù)可靠性以及服務(wù)的可用性，因此用戶根本無需擔(dān)心數(shù)據(jù)的可靠性以及服務(wù)可用性。

業(yè)務(wù)監(jiān)控&報(bào)表
在系統(tǒng)層面，阿里云幫助用戶運(yùn)維了整個(gè)集群，保證了可用性和可靠性。在此基礎(chǔ)之上，阿里云還為業(yè)務(wù)方提供了一整套的業(yè)務(wù)監(jiān)控與報(bào)表體系。在這套業(yè)務(wù)監(jiān)控體系里面，主要還是通過三個(gè)維度進(jìn)行，第一個(gè)維度就是實(shí)例，所謂實(shí)例就是用戶可以理解為自建的集群的一個(gè)概念，而實(shí)際上也就是一個(gè)集群，每個(gè)用戶購買一個(gè)實(shí)例的時(shí)候也就能得到一個(gè)真實(shí)的小的集群。對于實(shí)例而言，用戶所需關(guān)注的是其磁盤水位、生產(chǎn)者以及消費(fèi)者的TPS會不會超過閾值這些異常情況。第二個(gè)維度是Topic，阿里云也提供了一些消息堆積的查詢情況，通過直觀的方式，用戶將能夠看到生產(chǎn)者是否在正常地生產(chǎn)著消息，而這在開源的Kafka實(shí)現(xiàn)里面也是用戶的一個(gè)痛點(diǎn)。在開源方案中，沒有這種相應(yīng)的運(yùn)維工具，用戶很難直接去對生產(chǎn)者進(jìn)行監(jiān)控。最后一個(gè)維度，也是用戶使用非常多的就是Consumer Group與Topic對應(yīng)的堆積情況，目前的堆積在后續(xù)也會提供延遲的各種消息。以上這三個(gè)是目前阿里云消息隊(duì)列Kafka所能夠提供的監(jiān)控維度，未來也會根據(jù)用戶的反饋不斷增加相應(yīng)的監(jiān)控維度。

數(shù)據(jù)安全
消息隊(duì)列Kafka提供了一系列數(shù)據(jù)安全的保障體系來保證數(shù)據(jù)的安全。首先所提供就是專有網(wǎng)絡(luò)VPC，VPC網(wǎng)絡(luò)是基于阿里云構(gòu)建的一個(gè)隔離的網(wǎng)絡(luò)環(huán)境，在專有網(wǎng)絡(luò)之間邏輯上徹底隔離。VPC網(wǎng)絡(luò)是屬于用戶自己獨(dú)有的云上私有網(wǎng)絡(luò)，也就是提供給用戶的完全由自己掌控的專有網(wǎng)絡(luò)。理論上，部署在VPC私有網(wǎng)絡(luò)里面就是安全的，不同用戶的云服務(wù)器部署在不同的專有網(wǎng)絡(luò)，不同專有網(wǎng)絡(luò)之間通過隧道ID進(jìn)行隔離。除此之外，有一些用戶還可能有更多的需求，比如政務(wù)云用戶除了VPC的需求之外，還需要組件與組件之間的加密，這樣的場景阿里云也是支持的。此外，阿里云消息隊(duì)列Kafka還支黑白名單以及鑒權(quán)等功能，能夠通過多種的機(jī)制來保證數(shù)據(jù)的安全。

消息隊(duì)列Kafka的優(yōu)勢
上述與大家分享的就是消息隊(duì)列Kafka的優(yōu)勢，再來總結(jié)一下。消息隊(duì)列Kafka是完全兼容Apache Kafka的，Apache Kafka所能夠用到的整個(gè)生態(tài)的產(chǎn)品，比如上端的Flume等產(chǎn)品和下端的Spark、Storm、Flink以及ES等，對于消息隊(duì)列Kafka而言也是完全兼容的。其次，消息隊(duì)列Kafka所提供的是全托管的服務(wù)，也就是說無論集群中出現(xiàn)的是磁盤問題、網(wǎng)絡(luò)問題也好，無論是Kafka本身的還是其所依賴的產(chǎn)品所出現(xiàn)的任何問題，都是有專業(yè)團(tuán)隊(duì)來解決的。對于用戶而言，所能夠看到的是產(chǎn)品99.9%的可用性，并且能夠?yàn)橛脩魩矸浅７€(wěn)定的狀態(tài)，而底層的技術(shù)細(xì)節(jié)則是由阿里云專業(yè)的團(tuán)隊(duì)來處理的。對于高可用以及高可靠這部分而言，其與全托管是存在強(qiáng)關(guān)聯(lián)的。對于數(shù)據(jù)的可靠性而言，都是每一個(gè)產(chǎn)品所最為重視的，因?yàn)楫?dāng)發(fā)生了數(shù)據(jù)的丟失，就可能使得整個(gè)的業(yè)務(wù)邏輯出現(xiàn)錯(cuò)誤，進(jìn)而引發(fā)一些重大的故障。而阿里云所承諾的是當(dāng)用戶使用消息隊(duì)列Kafka發(fā)送消息，只要返回所發(fā)送的消息是成功的，那么這個(gè)數(shù)據(jù)的可靠性就能夠達(dá)到8個(gè)9，這一點(diǎn)也是用戶所無需擔(dān)心的。同時(shí)，阿里云消息隊(duì)列為用戶提供了非常實(shí)用的業(yè)務(wù)報(bào)表以及靈活全面的業(yè)務(wù)監(jiān)控體系，并且業(yè)務(wù)的監(jiān)控和報(bào)表是基于用戶業(yè)務(wù)維度的，包括整個(gè)集群的磁盤水位、Topic以及Consumer Group在內(nèi)的所有的用戶所關(guān)心的業(yè)務(wù)相關(guān)指標(biāo)，這些內(nèi)容都會沉淀在消息隊(duì)列Kafka的控制臺里面，用戶直接登錄控制臺就能夠看到整體業(yè)務(wù)的運(yùn)行情況。最后一點(diǎn)，運(yùn)行在消息隊(duì)列Kafka上的數(shù)據(jù)是非常安全的，通過VPC網(wǎng)絡(luò)的隔離、鑒權(quán)、加密以及黑白名單這一系列的保障能夠保證用戶的數(shù)據(jù)是非常安全的，同時(shí)消息隊(duì)列Kafka所具有的一個(gè)巨大優(yōu)勢就是其購買的每一個(gè)實(shí)例都是用戶購買所獨(dú)享的，用戶之間不會因?yàn)橄嗷ビ绊憣?dǎo)致整個(gè)系統(tǒng)出現(xiàn)不穩(wěn)定的情況。

三、場景
以上為大家介紹了消息隊(duì)列Kafka的優(yōu)勢，接下來為大家分享其所適用的場景。其實(shí)，可以認(rèn)為消息隊(duì)列Kafka與開源的Apache Kafka所適用的場景是一樣的，不同之處在于消息隊(duì)列Kafka具有更高的可靠性以及可用性，同時(shí)不需要用戶自己進(jìn)行運(yùn)維。

構(gòu)建日志分析平臺
淘寶、天貓平臺等公司每天都會產(chǎn)生大量的日志。運(yùn)營、運(yùn)維團(tuán)隊(duì)以及一些決策人員需要對于整個(gè)的日志數(shù)據(jù)進(jìn)行分析與統(tǒng)計(jì)。而Kafka本身的性能是非常高效的，同時(shí)Kafka的特性決定它非常適合作為"日志收集中心"，這是因?yàn)镵afka在采集日志的時(shí)候業(yè)務(wù)是無感知的，其能夠兼容自己的上游，能夠直接地通過配置加密消息。當(dāng)日志數(shù)據(jù)發(fā)送到Kafka集群里面，其實(shí)對于業(yè)務(wù)而言是完全無侵入的。同時(shí)其在下游又能夠直接地對接Hadoop/ODPS等離線倉庫存儲和Strom/Spark等實(shí)現(xiàn)實(shí)時(shí)在線分析。在這樣的情況之下，使用Kafka，只需要用戶去關(guān)注整個(gè)流程里面的業(yè)務(wù)邏輯，而無需做更多的開發(fā)就能夠?qū)崿F(xiàn)統(tǒng)計(jì)、分析以及報(bào)表。

網(wǎng)站活動(dòng)跟蹤場景
除了實(shí)現(xiàn)數(shù)據(jù)分析形成報(bào)表之外，Kafka還可以實(shí)現(xiàn)網(wǎng)站活動(dòng)跟蹤場景。通過Kafka可以實(shí)時(shí)地收集到網(wǎng)站的活動(dòng)數(shù)據(jù)，比如用戶對于頁面的瀏覽、搜索以及行為等。消息隊(duì)列Kafka可以通過Topic來對于業(yè)務(wù)上面不同的數(shù)據(jù)模型進(jìn)行切分的。那么，用戶可以按照注冊或者登錄以及購買等進(jìn)行切分，對于下游所需要跟蹤的場景的不同，可以對接不同的處理系統(tǒng)，比如實(shí)時(shí)處理、實(shí)時(shí)監(jiān)控以及離線處理，Kafka在這個(gè)場景里面是非常便捷易用的。

數(shù)據(jù)在流動(dòng)中產(chǎn)生價(jià)值
前面兩個(gè)例子是將消息隊(duì)列Kafka在整個(gè)解決方案里面承擔(dān)的是數(shù)據(jù)輸入流的角色，而Kafka卻不僅僅可以充當(dāng)數(shù)據(jù)的輸入流，還可以做流計(jì)算處理，比如股市走向分析、氣象數(shù)據(jù)測控、網(wǎng)站用戶行為分析等領(lǐng)域，由于在這些領(lǐng)域中數(shù)據(jù)產(chǎn)生快、實(shí)時(shí)性強(qiáng)、數(shù)據(jù)量大，所以很難統(tǒng)一采集并入庫存儲后再做處理，這便導(dǎo)致傳統(tǒng)的數(shù)據(jù)處理架構(gòu)不能滿足需求。而Kafka Stream以及Storm/Samza/Spark等流計(jì)算引擎的出現(xiàn)，可以根據(jù)業(yè)務(wù)需求對數(shù)據(jù)進(jìn)行計(jì)算分析，最終把結(jié)果保存或者分發(fā)給需要的組件。

多路轉(zhuǎn)發(fā)
大家經(jīng)常會遇到的場景就是對于不同的業(yè)務(wù)維度而言，需要不同的計(jì)算方式，比如對于對賬系統(tǒng)而言，可能需要實(shí)時(shí)的流處理方式；對于統(tǒng)計(jì)分析而言，可以使用批計(jì)算方式。而使用Kafka能夠?qū)崿F(xiàn)多路轉(zhuǎn)發(fā)，上游生產(chǎn)一份數(shù)據(jù)，多個(gè)下游節(jié)點(diǎn)都能夠獲取這份數(shù)據(jù)并做出相應(yīng)的處理，因此Kafka可以完成數(shù)據(jù)多路轉(zhuǎn)發(fā)的功能。

消息隊(duì)列Kafka商業(yè)化發(fā)布
消息隊(duì)列Kafka已經(jīng)在2018年7月1日正式地進(jìn)行了商業(yè)化發(fā)布。目前在華北1、華北2、華東1、華東2、華南1這5個(gè)region可商業(yè)化使用了。目前VPC內(nèi)部署已支持，預(yù)計(jì)在9月會推出非VPC版本，非VPC版本主要解決的是目前公網(wǎng)用戶的一些接入問題以及使用經(jīng)典網(wǎng)絡(luò)的遺留存量用戶問題。在前期，消息隊(duì)列Kafka的主要精力投入在了穩(wěn)定性相關(guān)以及成本優(yōu)化問題方面，而在資源報(bào)警這部分功能排期在8月份上線。

而對于用戶而言，穩(wěn)定性永遠(yuǎn)處于第一位，最后通過本次分享希望用戶能夠記住：阿里云消息隊(duì)列Kafka是非常易用的，和開源版本的Kafka可以實(shí)現(xiàn)0成本切換，同時(shí)數(shù)據(jù)可靠性和服務(wù)可用性都是非常高的，用戶再也不用擔(dān)心由于Kafka的問題導(dǎo)致整個(gè)業(yè)務(wù)的癱瘓。相比于阿里云的另一款產(chǎn)品MQ而言，Kafka也有自己的清晰定位，就是在大數(shù)據(jù)的場景下使用Kafka，而在業(yè)務(wù)之間使用MQ。并且Kafka對于生態(tài)的對接能力是非常強(qiáng)大的，而MQ提供了一些增強(qiáng)的功能，比如事務(wù)、定時(shí)消息以及順序消息等。在本月是阿里云消息隊(duì)列Kafka的首月活動(dòng)，包月將會給予8.5折優(yōu)惠，則包年直接給到8折優(yōu)惠。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。