編者薦語：
感謝大家支持伤提，我是國棟巫俺，目前新書已上架各大線上平臺！肿男！
多謝PowerData社區(qū)對此的支持介汹。感謝機械工業(yè)出版社編輯老師長期的指導。感謝Tencent同事們的指點與陪伴舶沛。
作者簡介
國棟嘹承，騰訊軟件工程師，Apache Pulsar冠王、Apache Flink 等項目的貢獻者赶撰，杭州電子科技大學碩士舌镶。
曾參與某大型數(shù)據(jù)中臺建設項目柱彻，以及消息隊列服務（Pulsar、Kafka）及其相關數(shù)據(jù)總線服務的開發(fā)與建設工作餐胀。在 Apache Pulsar哟楷、Apache Kafka、Apache Flink 落地實踐方面具有豐富經(jīng)驗否灾。
本文章部分內(nèi)容卖擅，節(jié)選自作者新書《Apache Pulsar 原理解析與應用實踐》，機械工業(yè)出版社墨技。
引言
Kafka 自 2011 年被捐獻給 Apache 基金會惩阶，至今已發(fā)展為消息隊列事實標準。作為一個優(yōu)秀的分布式消息系統(tǒng)扣汪，Kafka 被許多企業(yè)采用并成為其大數(shù)據(jù)架構中不可或缺的一部分断楷。目前 Kafka 也不局限于分布式消息隊列，而在向“集成分發(fā)崭别、存儲和計算的流式數(shù)據(jù)平臺”發(fā)展冬筒。
與此同時，大數(shù)據(jù)"新秀"Pulsar 是站在 Kafka 與 RocketMQ 的肩膀上茅主，針對 Kafka 使用與維護過程中的痛點問題舞痰，結合云原生、存算分離的架構趨勢诀姚，所提出新的架構思想的新一代消息隊列架構响牛。（站在巨人肩膀上，在開源軟件與計算機發(fā)展的歷史上，參考現(xiàn)有軟件架構呀打，有針對性地現(xiàn)有架構的痛點论衍，提出新一代的解決方案是促進行業(yè)發(fā)展的巨大貢獻。）
作者在某一線互聯(lián)網(wǎng)公司負責維護數(shù)據(jù)總線與數(shù)據(jù)集成服務聚磺，其在 Kafka 與 Plusar 的基礎之上坯台，又抽象了一層數(shù)據(jù)管道的概念，使兩種消息隊列可以插拔式嵌入服務中瘫寝，并在業(yè)務場景下進行靈活切換蜒蕾。因此，筆者可以同時深入使用 Kafka 與 Plusar 這兩種消息隊列焕阿。
Kafka 經(jīng)歷了這么多復雜業(yè)務場景的考驗咪啡，作為大數(shù)據(jù)信息隊列的事實標準，即使放在現(xiàn)在依舊是大數(shù)據(jù)場景下的首要選擇暮屡。
Pulsar 在前人基礎上撤摸，從架構底層重新定義大數(shù)據(jù)消息隊列，結合其本身云原生褒纲、多租戶准夷、存算分離的特性，在很多業(yè)務場景下可以更加輕松的面對各種調(diào)整莺掠。
在當前云原生迅速發(fā)展的時代衫嵌，我們應該如何抉擇 Kafka 與 Plusar， 本文從多個角度進行對比彻秆，給出參考楔绞。
前 Kafka 時代
哼，一個能打的都沒有唇兑！
Kafka 是 2009 年底 LinkedIn 研發(fā)的一套流數(shù)據(jù)處理平臺酒朵。LinkedIn 發(fā)現(xiàn)當下 MQ 系統(tǒng)有兩個通用缺陷：一是當消費者出現(xiàn)消費不及時的時候，數(shù)據(jù)就會丟掉扎附；二是可延展性問題蔫耽，MQ 系統(tǒng)不能很好地配合數(shù)據(jù)的波峰或波谷。
這些需求正好對應當時的消息隊列系統(tǒng)不能解決的一些問題：橫向拓展帕棉、持久化针肥、高吞吐、高性能香伴、甚至是低成本慰枕。因此 Kafka 這一流處理系統(tǒng)出現(xiàn)后，瞬間成為大數(shù)據(jù)流處理系統(tǒng)的事實標準即纲。
Kafka 設計理念非常簡單具帮，就是一個?以 append-only 日志作為核心的數(shù)據(jù)存儲結構。簡單來說，就是我們把數(shù)據(jù)以日志的方式進行組織蜂厅，所有對于日志的寫操作匪凡，都提交在日志的最末端，讀取時也只能順序讀取掘猿。
從當下的角度看待當時的 Kafka 設計確實簡單又十分優(yōu)雅病游！Kafka 能實現(xiàn)上述的：橫向拓展、持久化稠通、高吞吐衬衬、高性能都得益于這個基礎設計。
順序讀寫改橘，高吞吐：HDD 的隨機讀取和寫入因為其本身原因會非常慢滋尉，但其實如果能夠把所有的讀和寫都按照順序來進行操作，會發(fā)現(xiàn)它幾乎可以媲美內(nèi)存的隨機訪問飞主。Kafka 利用 append-only 日志作為核心的數(shù)據(jù)存儲結構狮惜，只會對文件進行順序的磁盤讀寫操作，完美利用了磁盤順序讀寫快速的優(yōu)點碌识。
【機械硬盤的連續(xù)讀寫性能很好碾篡，但隨機讀寫性能很差，這主要是因為磁頭移動到正確的磁道上需要時間丸冕，隨機讀寫時耽梅，磁頭需要不停地移動，時間都浪費在了磁頭尋址上胖烛，所以性能較低∽缑裕】
多分區(qū)擴展：在 Kafka 中佩番，Topic 只是一個邏輯的概念。每個 Topic 都包含一個或多個 Partition罢杉，不同 Partition 可位于不同節(jié)點趟畏，因此可以充分利用集群優(yōu)勢，實現(xiàn)機器間的并行處理滩租。同時由于 Partition 在物理上對應一個文件夾赋秀，即使多個 Partition 位于同一個節(jié)點，也可通過配置讓同一節(jié)點上的不同 Partition 置于不同的磁盤上律想，從而實現(xiàn)磁盤間的并行處理猎莲，充分發(fā)揮多磁盤優(yōu)勢。
多副本下的高可用：每個 broker 中的 partition 都會設置有 replication（副本）的個數(shù)技即，生產(chǎn)者寫入的時候首先根據(jù)分發(fā)策略（有 partition 按 partition著洼，有 key 按 key，都沒有輪詢）寫入到 leader 中，follower（副本）再跟 leader 同步數(shù)據(jù)身笤，這樣有了備份豹悬，也可以保證消息數(shù)據(jù)的不丟失。
低成本：Kafka 的日志存儲持久化到磁盤液荸，在部署時可以使用成本較低的 HDD 磁盤瞻佛。
頁緩存加速：順序?qū)懳募r，讀操作可直接在 Page Cache 內(nèi)進行娇钱。如果消費和生產(chǎn)速度相當涤久，甚至不需要通過物理磁盤（直接通過 Page Cache）交換數(shù)據(jù)，頁緩存會將一些寫操作重新按順序排好忍弛，從而減少磁盤頭的移動時間响迂，并將連續(xù)的小塊寫組裝成大塊的物理寫從而提高性能。
【Cache 層在內(nèi)存中緩存了磁盤上的部分數(shù)據(jù)细疚。當數(shù)據(jù)的請求到達時蔗彤，如果在 Cache 中存在該數(shù)據(jù)且是最新的，則直接將數(shù)據(jù)傳遞給用戶程序疯兼，免除了對底層磁盤的操作然遏，提高了性能】
零拷貝，充分利用 IO：Kafka 在這里采用的方案是通過 NIO 的?transferTo/transferFrom?調(diào)用操作系統(tǒng)的 sendfile 實現(xiàn)零拷貝吧彪〈郑總共發(fā)生 2 次內(nèi)核數(shù)據(jù)拷貝、2 次上下文切換和一次系統(tǒng)調(diào)用姨裸，消除了 CPU 數(shù)據(jù)拷貝秧倾。
【零拷貝（Zero-copy）技術指在計算機執(zhí)行操作時，CPU 不需要先將數(shù)據(jù)從一個內(nèi)存區(qū)域復制到另一個內(nèi)存區(qū)域傀缩，從而可以減少上下文切換以及 CPU 的拷貝時間那先。它的作用是在數(shù)據(jù)報從網(wǎng)絡設備到用戶程序空間傳遞的過程中，減少數(shù)據(jù)拷貝次數(shù)赡艰，減少系統(tǒng)調(diào)用售淡，實現(xiàn) CPU 的零參與，徹底消除 CPU 在這方面的負載】
從當下的角度看待 Kafka 的設計還是那么簡潔和優(yōu)雅慷垮，Kafka 能實現(xiàn)上述的：橫向拓展揖闸、持久化、高吞吐料身、高性能都得益于以 append-only 日志作為核心的數(shù)據(jù)存儲結構這個基礎設計汤纸。但是，這種簡單的設計也有一些弊端惯驼，但是在 Kafka 剛出的那個時候蹲嚣，這個設計和功能確實太優(yōu)秀了递瑰。
后 Kafka 時代
何為后 Kafka 時代？
Kafka 作為一個老的基礎組件隙畜，很多讀者都已經(jīng)對其設計和原理十分熟悉抖部，在后起之秀 Pulsar 的沖擊下，很多人或許會猶豫究竟要選擇哪個技術议惰。不禁讓人思考：Kafka 老矣慎颗，尚能飯否？
Kafka 使用痛點
首先先說結論言询，后 Kafka 時代下俯萎，Kafka 的某些設計已經(jīng)比較落后了。在運營/運維 Kafka 的過程中运杭，其實遇到了很多問題夫啊。
而很多問題是在基礎架構確定之后，就決定了會有這樣的結果辆憔。
單機器的分區(qū)上限問題
雖然 Kafka 的 topic partition 是順序?qū)懭肫裁校钱?broker 上有成百上千個 topic partition 時，從磁盤角度看就變成了隨機寫入虱咧，此時磁盤讀寫性能會隨著 topic partition 數(shù)量的增加而降低熊榛，因此?Kafka broker 上存儲的 topic partition 數(shù)量是有限制的。在微服務與云原生場景下腕巡，需要創(chuàng)建大量 Topic 用于進程間通信玄坦，導致 Kafka 吞吐性能低下。
【Kafka 的設計是每個 Topic 包括若干個 Partition绘沉，每個 Partition 同一時刻只會寫一個存儲文件煎楣。當存儲文件寫滿后（例如 1G），再寫下一個存儲文件梆砸。這樣的存儲機制在 Topic 比較少的情況下并不會有問題转质，大數(shù)據(jù)場景下通常 Topic 不需要設置太多。而用在大規(guī)模微服務的場景下由于業(yè)務的需求帖世，需要設置很多 Topic，通常幾百甚至上千個沸枯。當 Kafka 設置了幾百個 Topic 后日矫，由于其特有的存儲模型，每個 Broker 節(jié)點會創(chuàng)建數(shù)百個文件绑榴，而眾多的文件在被讀取時哪轿，部分數(shù)據(jù)會被加載到操作系統(tǒng)的 Page Cache 中，使用過多的 Page Cache 會令系統(tǒng)極其不穩(wěn)定翔怎。這也是為什么 Kafka 在多 Topic 時窃诉，性能表現(xiàn)很差的原因杨耙。】
非存算分離架構帶來的擴容問題
Kafka 并不是一個存儲與計算分離的架構飘痛，因此無法單獨從存儲和計算的維度進行擴容珊膜。
單分區(qū)文件目錄綁定單臺 broker 帶來的 IO 瓶頸
Kafka 中根據(jù)設置的保留期來刪除消息晨川。有可能消息沒被消費丈牢，過期后被刪除。不支持 TTL骡尽。
但是這其中的本質(zhì)問題來自于：一個分區(qū)只能歸屬于一臺 Broker 機器塑猖，如果想要擴容的話竹祷，只能擴分區(qū)，拆分區(qū)
在極端情況下羊苟，如果原有 Kafka 集群負載到達 50%塑陵，流量這時如果翻三四倍，這對 Kafka 的運維來說簡直是個災難蜡励！
運維成本高
如果某個機器磁盤滿了令花，需要顯式使用工具遷移分區(qū)（Kafka-reassign-partitions.sh）
數(shù)據(jù)存儲和消息隊列服務綁定，集群擴縮容/分區(qū)均衡需要大量拷貝數(shù)據(jù)巍虫，會帶來了很大的運維成本彭则。
隨著 Kafka 集群規(guī)模的增長，Kakfa 集群的運維成本急劇增長占遥，需要投入大量的人力進行日常運維俯抖。在某互聯(lián)網(wǎng)公司中，擴容一臺機器到 Kafka 集群并進行分區(qū)均衡瓦胎，需要 0.5 人/天芬萍；縮容一臺機器需要 1 人/天。
PageCache 污染問題搔啊，造成讀寫性能下降
Kafka 對 page cache 需求巨大柬祠。根據(jù)經(jīng)驗值，為 Kafka 分配 6~8GB 的堆內(nèi)存就已經(jīng)足足夠用了负芋，將剩下的系統(tǒng)內(nèi)存都作為 page cache 空間漫蛔，可以最大化 I/O 效率。
另一個需要特別注意的問題是 lagging consumer旧蛾，即那些消費速率慢莽龟、明顯落后的 consumer。它們要讀取的數(shù)據(jù)有較大概率不在 broker page cache 中锨天，因此會增加很多不必要的讀盤操作毯盈。
比這更壞的是，lagging consumer 讀取的“冷”數(shù)據(jù)仍然會進入 page cache病袄，污染了多數(shù)正常 consumer 要讀取的“熱”數(shù)據(jù)搂赋，連帶著正常 consumer 的性能變差赘阀。在生產(chǎn)環(huán)境中，這個問題尤為重要脑奠。
在 catch-up 讀場景下基公，容易出現(xiàn) PageCache 污染，造成讀寫性能下降捺信。雖然 Kafka 可以利用 PageCache 進行讀取加速酌媒，在一些場景下實踐效果不佳。
不支持讀寫分離
在 Kafka 中迄靠，為了使 consumer 讀取數(shù)據(jù)能夠保持一致秒咨，只允許 consumer 讀取 leader 副本的數(shù)據(jù)的。follower replica 只用作備份數(shù)據(jù)掌挚。
生產(chǎn)者寫入消息雨席、消費者讀取消息的操作都是與 leader 副本進行交互的，從而實現(xiàn)的是一種主寫主讀的生產(chǎn)消費模型吠式。Kafka 并不支持主寫從讀陡厘。
其實 Kafka 的主寫主讀也是有一些優(yōu)點的：
可以簡化代碼的實現(xiàn)邏輯，減少出錯的可能;
將負載粒度細化均攤特占，與主寫從讀相比糙置，不僅負載效能更好，而且對用戶可控;
沒有延時的影響;
在副本穩(wěn)定的情況下是目，不會出現(xiàn)數(shù)據(jù)不一致的情況谤饭。
但是這些也不能算是完全的優(yōu)點，只是在當前 Kafka 架構下懊纳，做到讀寫分離的收益不如主寫主讀方案揉抵。
Kafka 中 IO 不隔離，因此消費者在清除 Backlog 時會影響其他生產(chǎn)者和消費者嗤疯。
【Backlog 是指已經(jīng)被寫入但尚未被消費的消息隊列冤今，消費者消費消息時需要從 Backlog 中讀取數(shù)據(jù)。如果一個消費者清除了 Backlog茂缚，那么其他消費者就無法再讀取這些消息戏罢。
此外，如果消費者消費消息的速度較慢脚囊，而生產(chǎn)者持續(xù)發(fā)送消息帖汞，導致消息堆積，這時候清除 Backlog 可以幫助消費者快速消費積壓的消息凑术。但是，清除 Backlog 也可能導致生產(chǎn)者發(fā)送的消息被刪除所意，這會影響到其他消費者讀取消息的順序和完整性淮逊。
因此催首，在清除 Backlog 之前，需要謹慎考慮其影響泄鹏，并確保所有相關方都已經(jīng)做好了相應的準備郎任。在實際使用中，可以采用多個消費者訂閱同一個 Topic 的方式來分攤消息的消費壓力备籽，以提高系統(tǒng)的穩(wěn)定性和可靠性舶治。】
Kafka2.4.0 的 follower replica fetch 功能允許使用者從最近的副本（非 leader）中獲取數(shù)據(jù)车猬， 這像是朝著讀寫分離方向前進霉猛，但是閱讀 release 日志會發(fā)現(xiàn)：Kafka 能夠從 follower 副本讀數(shù)據(jù),這個功能并不是為了提升讀取性能。
那推出 follower replica fetch 功能的背景是什么呢珠闰？舉個比較常見的場景惜浅，Kafka 存在多個數(shù)據(jù)中心，不同數(shù)據(jù)中心存在于不同的機房伏嗜，當其中一個數(shù)據(jù)中心需要向另一個數(shù)據(jù)中心同步數(shù)據(jù)的時候坛悉，由于只能從 leader replica 消費數(shù)據(jù)，那么它不得不進行跨機房獲取數(shù)據(jù)承绸，而這些流量帶寬通常是比較昂貴的（尤其是云服務器）裸影。即無法利用本地性來減少昂貴的跨機房流量。所以 Kafka 推出這一個功能军熏，就是幫助類似這種場景轩猩，節(jié)約流量資源。這種功能還可以和新推出的 mirror maker2 相互配合羞迷，實現(xiàn)多個數(shù)據(jù)源的數(shù)據(jù)同步界轩。
Pulsar 的優(yōu)勢
開源領域中有諸多優(yōu)秀開源消息隊列，例如 RabbitMQ衔瓮、Apache RocketMQ浊猾、Apache ActiveMQ 和 Apache Kafka。
在前人的基礎上热鞍，Pulsar 實現(xiàn)了很多上一代消息系統(tǒng)或者上一代流數(shù)據(jù)系統(tǒng)沒有實現(xiàn)的功能和特性葫慎，比如云原生、多租戶薇宠、存儲與計算分離偷办、分層存儲這些特性。針對之前消息隊列系統(tǒng)的痛點澄港，Pulsar 做了很多針對化的解決措施椒涯。
什么是 Pulsar？
（1）Pulsar 是一個分布式消息平臺回梧，可以同時處理流式數(shù)據(jù)和異構系統(tǒng)這兩類問題废岂。Pulsar 具有非常靈活的消息傳遞模型祖搓，為了實現(xiàn)更加豐富的消費模式，Pulsar 提出了訂閱的概念湖苞。訂閱是一個數(shù)據(jù)消費的規(guī)則拯欧，它決定了如何將消息傳遞給消費者，通過不同的訂閱模式?jīng)Q定多個消費者在消費時的不同行為财骨。
（2）Pulsar 是一個集消息傳遞镐作、消息存儲、輕量化函數(shù)式計算為一體的流數(shù)據(jù)平臺隆箩。Pulsar 不僅提供了數(shù)據(jù)的存儲與消費能力该贾，還提供了一定的流處理能力。
（3）Pulsar 是一個分布式可擴展的流式存儲系統(tǒng)摘仅，并在數(shù)據(jù)存儲的基礎上構建了消息隊列和流服務的統(tǒng)一模型靶庙。這使得 Pulsar 不僅有消息隊列的功能（類似 RabbitMQ 和 RocketMQ 在業(yè)務系統(tǒng)中的使用），還是一個數(shù)據(jù)流的處理模型（類似 Kafka 在大數(shù)據(jù)系統(tǒng)中的定位）娃属。
云原生架構
云原生是一種在云計算時代構建和運行應用程序的方法六荒，可以充分利用和發(fā)揮云平臺的彈性自動化優(yōu)勢。云原生應用程序在云上以最佳方式運行矾端，讓業(yè)務系統(tǒng)的可用性掏击、敏捷性和可擴展性得到大幅提升。
Pulsar 是在消息隊列領域里基于云原生基礎架構設計的產(chǎn)品秩铆，擁有諸多云原生應用特性砚亭，如無狀態(tài)計算層、計算與存儲分離殴玛，可以很好地利用云的彈性（伸縮能力）捅膘，保證具有足夠的可擴容性和容錯性，能夠很好地在容器化環(huán)境中運行滚粟。
Pulsar 的存儲與計算分離架構在云原生環(huán)境中有著更大的價值寻仗。Pulsar 實例中的存儲節(jié)點可以由一組 Bookie 容器去負責，計算節(jié)點又是由另外一組 Broker 容器去負責凡壤。存儲與計算節(jié)點可以完全獨立擴縮容署尤，通過 Kubernetes 這樣的容器編排工具，業(yè)務方可以很快地構建彈性擴縮容的云原生消息隊列亚侠。
存儲與計算分離
Pulsar 是一個存儲與計算分離的消息隊列曹体，其中提供的計算服務的角色被稱為 Broker，提供存儲服務的角色被稱為 Bookie硝烂。Broker 是服務端的一個無狀態(tài)組件箕别，主要負責兩類職能：數(shù)據(jù)的生產(chǎn)消費與 Pulsar 管理。真正扛起存儲重任的是 BookKeeper。
Broker 服務是無狀態(tài)的究孕，在計算資源不足時可獨立進行擴容啥酱。Bookie 是有狀態(tài)的存儲服務，Pulsar 中的數(shù)據(jù)會以數(shù)據(jù)塊的形式分配在不同的 Bookie 節(jié)點中厨诸。當存儲資源不夠時，可通過增加 Bookie 節(jié)點的形式進行擴容禾酱。Pulsar 會感知 Bookie 集群的變化微酬，并在合適的時機使用新增加的 Bookie 節(jié)點進行存儲，避免了人為遷移數(shù)據(jù)的運維操作颤陶。Broker 服務與 Bookie 服務的擴容相互獨立颗管，避免了資源浪費，提供了 Pulsar 的可維護性滓走。
分層存儲
BookKeeper 集群可以使用廉價的機械硬盤作為存儲介質(zhì)垦江。但是在部署 BookKeeper 集群的過程中，為了最大程度提升寫入與讀取能力搅方，有可能會選擇帶有固態(tài)硬盤（SSD）的機器比吭，這些機器成本較為昂貴。
Pulsar 是一個存儲與計算分離的消息隊列姨涡，消息最初會存儲在 BookKeeper 集群中衩藤，通過內(nèi)部管理組件進行抽象管理。數(shù)據(jù)管理的基本單位是數(shù)據(jù)段涛漂，其中數(shù)據(jù)刪除與創(chuàng)建的基本單位也是數(shù)據(jù)段赏表。Pulsar 社區(qū)提供了分層存儲的能力，在服務端提供了數(shù)據(jù)卸載功能匈仗，可以將每個邏輯上的數(shù)據(jù)段從 BookKeeper 存儲切換為其他類型的存儲瓢剿。
Pulsar 的分層存儲功能允許將較舊的積壓數(shù)據(jù)卸載到長期存儲中，例如 Hadoop HDFS 或 Amazon S3 存儲悠轩，從而釋放 BookKeeper 中的空間并降低存儲成本间狂。通過分層存儲可以實現(xiàn)消息隊列中的冷數(shù)據(jù)與熱數(shù)據(jù)分離，讓成本更加可控哗蜈。
可拔插協(xié)議處理
在 Pulsar 中支持可插拔的協(xié)議處理機制前标，Pulsar 可以在運行時動態(tài)加載額外的協(xié)議處理程序并支持其他消息協(xié)議【嗯耍基于消息隊列協(xié)議層炼列，目前 Pulsar 已經(jīng)支持了 Kafka、RocketMQ音比、AMQP 和 MQTT 等多種協(xié)議俭尖。基于消息隊列協(xié)議層，Pulsar 可以將自身云原生稽犁、分層存儲焰望、自動負載管理等諸多特性推廣至更多的消息隊列系統(tǒng)中
Pulsar 協(xié)議層支持的 Kafka 項目為 KafkaOn Pulsar（KoP）。將 KoP 協(xié)議部署在現(xiàn)有的 Pulsar 集群中已亥，用戶可以在 Pulsar 集群中繼續(xù)使用原生 Kafka 協(xié)議熊赖，同時能夠利用 Pulsar 的強大功能，完善存量 Kafka 應用的使用體驗虑椎。
數(shù)據(jù)可靠性
Pulsar 可以通過冪等性生產(chǎn)者在單個分區(qū)上寫入數(shù)據(jù)震鹉，并保證其可靠性。通過客戶端的自增序列 ID捆姜、重試機制與服務端的去重機制传趾，冪等生產(chǎn)者可以保證發(fā)送到單個分區(qū)的每條消息只會被持久化一次，且不會丟失數(shù)據(jù)泥技。
另外浆兰，Pulsar 事務中的所有生產(chǎn)或消費操作都作為一個單元提交。一個事務中的所有操作要么全部提交珊豹，要么全部失敗簸呈。Pulsar 保障每條消息只寫入或處理一次，即使發(fā)生故障也不會丟失數(shù)據(jù)或重復平夜。如果事務中止蝶棋，則該事務中的所有寫入和確認都將自動回滾。綜上所述忽妒，可以發(fā)現(xiàn) Kafka 與 Pulsar 的事務功能都是為了支持精確一次語義的玩裙。
豐富的生態(tài)支持
當用戶在使用消息隊列或者流式服務時，有時遇到的應用場景僅是對消息進行搬運段直，或者進行一些簡單的統(tǒng)計吃溅、過濾、匯總等操作鸯檬。通過 Pulsar Function 就可以原生支持這些功能决侈。官方提供了多種導入數(shù)據(jù)與導出數(shù)據(jù)的連接器。通過 Pulsar I/O 提供的能力可以通過簡單的配置喧务，靈活地將 Pulsar 與外部系統(tǒng)相結合赖歌，例如關系型數(shù)據(jù)庫、非關系型數(shù)據(jù)庫（如 MongoDB）功茴、數(shù)據(jù)湖庐冯、Hadoop 生態(tài)等。
Kafka 依舊優(yōu)秀
我的字典里坎穿，沒有老這個字展父。
不屈的靈魂返劲，不滅的斗志，不老的心栖茉。
在筆者遇到的業(yè)務挑戰(zhàn)中篮绿，即使是國內(nèi)的頭部游戲業(yè)務沖擊下，在合理的配置與使用中吕漂，Kafka 依舊十分穩(wěn)健亲配。
什么樣的場景下可以繼續(xù)用 Kafka??大部分情況下都可以毫不猶豫的選擇 Kafka
在集群內(nèi) topic 不多或 topic 增長速度不是特別快的情況下，Kafka 依舊是很好的選擇痰娱。
不需要復雜的企業(yè)級場景的時候弃榨，Kafka 仍舊是首選。例如不需要多租戶與云原始等特性時梨睁，不需要應對特別復雜的吞吐量挑戰(zhàn)時，不需要分層存儲等特性時娜饵，
Kafka 原生的集群模式使用簡單坡贺，能滿足大部分業(yè)務的需要。Kafka 生態(tài)更加完善箱舞，國內(nèi)外的資料與先驅(qū)者更加多遍坟，在遇到 Kafka 問題時，求取解決方案的途徑會更加簡單晴股。
不可否認愿伴，復雜的架構勢必會帶來新的優(yōu)勢，但是也會帶來復雜性的提高电湘，進而導致出現(xiàn)問題的概率會增加隔节。使用 Pulsar 早期版本時，有時會遇到一些奇怪的 bug寂呛，需要開發(fā)與維護人員更多的知識儲備與問題處理能力怎诫！
《Apache Pulsar 原理解析與應用實踐》
機械工業(yè)出版社《 Apache Pulsar原理解析與應用實踐》》
本書從項目背景、基本概念贷痪、架構設計和工程實踐等多角度出發(fā)幻妓，全面解讀 Pulsar 的核心原理與應用方法。作為云原生的分布式消息隊列和流數(shù)據(jù)平臺劫拢，Pulsar 不僅支持云原生肉津、多租戶、跨區(qū)域數(shù)據(jù)復制等高級功能舱沧，還支持消息隊列事務妹沙、分層存儲、可插拔的消息隊列協(xié)議狗唉、Pulsar Function初烘、Pulsar I/O、Pulsar SQL 等拓展功能，且可與 Apache Spark肾筐、Apache Flink 等計算引擎哆料，及 Apache Flume、Apache Kafka吗铐、Logstash 等社區(qū)生態(tài)相結合东亦。所以，通過 Pulsar 可以輕松構建出一整套的數(shù)據(jù)服務唬渗。本書對這些內(nèi)容均進行了詳細介紹典阵。
本書包括 3 篇 11 章。
基礎篇（第 1~4 章）首先對 Pulsar 的背景進行簡單介紹镊逝，并對多種消息隊列進行重點比較分析壮啊；然后對 Pulsar 的基本概念和基本架構進行分析，讓讀者對 Pulsar 有一個總體的了解撑蒜；接著分享了 Pulsar 安裝與部署的方法歹啼，以方便讀者快速上手并構建自己的服務；最后深度解讀了 Pulsar 的基本使用方法座菠。
原理篇（第 5~7 章）首先深度解讀了 Pulsar 的核心組件 Broker狸眼、Bookie、ManagedLedger浴滴、主題管理等的原理拓萌；然后分析了構建在這些核心組件之上的高級特性，如事務管理升略、消息協(xié)議拓展微王、分層存儲設計、消息延遲傳遞與主題壓縮降宅；最后對 Pulsar 提供的輕量化流數(shù)據(jù)處理引擎 Pulsar Function 及 I/O 功能進行剖析骂远。
應用篇（第 8~11 章）首先分享了 Pulsar 在結構化數(shù)據(jù)查詢與實時處理引擎技術方面的實踐，介紹了 Pulsar 如何與 Trino腰根、Flink激才、Spark 等引擎相結合；接著對 Pulsar 安全配置额嘿、服務管理瘸恼、服務監(jiān)控等進行討論；最后介紹了 Pulsar 服務的應用模式册养，以及 Pulsar 在數(shù)據(jù)集成东帅、動態(tài)數(shù)據(jù)捕獲和高可靠性配置等方面的實踐。
JD鏈接
