編者薦語：
感謝大家支持，我是國棟，目前新書已上架各大線上平臺！！
多謝PowerData社區(qū)對此的支持。感謝機械工業(yè)出版社編輯老師長期的指導。感謝Tencent同事們的指點與陪伴。
作者簡介
國棟，騰訊軟件工程師，Apache Pulsar、Apache Flink 等項目的貢獻者，杭州電子科技大學碩士。
曾參與某大型數(shù)據(jù)中臺建設(shè)項目，以及消息隊列服務（Pulsar、Kafka）及其相關(guān)數(shù)據(jù)總線服務的開發(fā)與建設(shè)工作。在 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ù)架構(gòu)中不可或缺的一部分。目前 Kafka 也不局限于分布式消息隊列，而在向“集成分發(fā)、存儲和計算的流式數(shù)據(jù)平臺”發(fā)展。
與此同時，大數(shù)據(jù)"新秀"Pulsar 是站在 Kafka 與 RocketMQ 的肩膀上，針對 Kafka 使用與維護過程中的痛點問題，結(jié)合云原生、存算分離的架構(gòu)趨勢，所提出新的架構(gòu)思想的新一代消息隊列架構(gòu)。（站在巨人肩膀上，在開源軟件與計算機發(fā)展的歷史上，參考現(xiàn)有軟件架構(gòu)，有針對性地現(xiàn)有架構(gòu)的痛點，提出新一代的解決方案是促進行業(yè)發(fā)展的巨大貢獻。）
作者在某一線互聯(lián)網(wǎng)公司負責維護數(shù)據(jù)總線與數(shù)據(jù)集成服務，其在 Kafka 與 Plusar 的基礎(chǔ)之上，又抽象了一層數(shù)據(jù)管道的概念，使兩種消息隊列可以插拔式嵌入服務中，并在業(yè)務場景下進行靈活切換。因此，筆者可以同時深入使用 Kafka 與 Plusar 這兩種消息隊列。
Kafka 經(jīng)歷了這么多復雜業(yè)務場景的考驗，作為大數(shù)據(jù)信息隊列的事實標準，即使放在現(xiàn)在依舊是大數(shù)據(jù)場景下的首要選擇。
Pulsar 在前人基礎(chǔ)上，從架構(gòu)底層重新定義大數(shù)據(jù)消息隊列，結(jié)合其本身云原生、多租戶、存算分離的特性，在很多業(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 設(shè)計理念非常簡單，就是一個?以 append-only 日志作為核心的數(shù)據(jù)存儲結(jié)構(gòu)。簡單來說，就是我們把數(shù)據(jù)以日志的方式進行組織，所有對于日志的寫操作，都提交在日志的最末端，讀取時也只能順序讀取。
從當下的角度看待當時的 Kafka 設(shè)計確實簡單又十分優(yōu)雅！Kafka 能實現(xiàn)上述的：橫向拓展、持久化、高吞吐、高性能都得益于這個基礎(chǔ)設(shè)計。
順序讀寫，高吞吐：HDD 的隨機讀取和寫入因為其本身原因會非常慢，但其實如果能夠把所有的讀和寫都按照順序來進行操作，會發(fā)現(xiàn)它幾乎可以媲美內(nèi)存的隨機訪問。Kafka 利用 append-only 日志作為核心的數(shù)據(jù)存儲結(jié)構(gòu)，只會對文件進行順序的磁盤讀寫操作，完美利用了磁盤順序讀寫快速的優(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 都會設(shè)置有 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)零拷貝?？偣舶l(fā)生 2 次內(nèi)核數(shù)據(jù)拷貝、2 次上下文切換和一次系統(tǒng)調(diào)用，消除了 CPU 數(shù)據(jù)拷貝。
【零拷貝（Zero-copy）技術(shù)指在計算機執(zhí)行操作時，CPU 不需要先將數(shù)據(jù)從一個內(nèi)存區(qū)域復制到另一個內(nèi)存區(qū)域，從而可以減少上下文切換以及 CPU 的拷貝時間。它的作用是在數(shù)據(jù)報從網(wǎng)絡設(shè)備到用戶程序空間傳遞的過程中，減少數(shù)據(jù)拷貝次數(shù)，減少系統(tǒng)調(diào)用，實現(xiàn) CPU 的零參與，徹底消除 CPU 在這方面的負載】
從當下的角度看待 Kafka 的設(shè)計還是那么簡潔和優(yōu)雅，Kafka 能實現(xiàn)上述的：橫向拓展、持久化、高吞吐、高性能都得益于以 append-only 日志作為核心的數(shù)據(jù)存儲結(jié)構(gòu)這個基礎(chǔ)設(shè)計。但是，這種簡單的設(shè)計也有一些弊端，但是在 Kafka 剛出的那個時候，這個設(shè)計和功能確實太優(yōu)秀了。
后 Kafka 時代
何為后 Kafka 時代？
Kafka 作為一個老的基礎(chǔ)組件，很多讀者都已經(jīng)對其設(shè)計和原理十分熟悉，在后起之秀 Pulsar 的沖擊下，很多人或許會猶豫究竟要選擇哪個技術(shù)。不禁讓人思考：Kafka 老矣，尚能飯否？
Kafka 使用痛點
首先先說結(jié)論，后 Kafka 時代下，Kafka 的某些設(shè)計已經(jīng)比較落后了。在運營/運維 Kafka 的過程中，其實遇到了很多問題。
而很多問題是在基礎(chǔ)架構(gòu)確定之后，就決定了會有這樣的結(jié)果。
單機器的分區(qū)上限問題
雖然 Kafka 的 topic partition 是順序?qū)懭?，但是?broker 上有成百上千個 topic partition 時，從磁盤角度看就變成了隨機寫入，此時磁盤讀寫性能會隨著 topic partition 數(shù)量的增加而降低，因此?Kafka broker 上存儲的 topic partition 數(shù)量是有限制的。在微服務與云原生場景下，需要創(chuàng)建大量 Topic 用于進程間通信，導致 Kafka 吞吐性能低下。
【Kafka 的設(shè)計是每個 Topic 包括若干個 Partition，每個 Partition 同一時刻只會寫一個存儲文件。當存儲文件寫滿后（例如 1G），再寫下一個存儲文件。這樣的存儲機制在 Topic 比較少的情況下并不會有問題，大數(shù)據(jù)場景下通常 Topic 不需要設(shè)置太多。而用在大規(guī)模微服務的場景下由于業(yè)務的需求，需要設(shè)置很多 Topic，通常幾百甚至上千個。當 Kafka 設(shè)置了幾百個 Topic 后，由于其特有的存儲模型，每個 Broker 節(jié)點會創(chuàng)建數(shù)百個文件，而眾多的文件在被讀取時，部分數(shù)據(jù)會被加載到操作系統(tǒng)的 Page Cache 中，使用過多的 Page Cache 會令系統(tǒng)極其不穩(wěn)定。這也是為什么 Kafka 在多 Topic 時，性能表現(xiàn)很差的原因?！?/p>
非存算分離架構(gòu)帶來的擴容問題
Kafka 并不是一個存儲與計算分離的架構(gòu)，因此無法單獨從存儲和計算的維度進行擴容。
單分區(qū)文件目錄綁定單臺 broker 帶來的 IO 瓶頸
Kafka 中根據(jù)設(shè)置的保留期來刪除消息。有可能消息沒被消費，過期后被刪除。不支持 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 架構(gòu)下，做到讀寫分離的收益不如主寫主讀方案。
Kafka 中 IO 不隔離，因此消費者在清除 Backlog 時會影響其他生產(chǎn)者和消費者。
【Backlog 是指已經(jīng)被寫入但尚未被消費的消息隊列，消費者消費消息時需要從 Backlog 中讀取數(shù)據(jù)。如果一個消費者清除了 Backlog，那么其他消費者就無法再讀取這些消息。
此外，如果消費者消費消息的速度較慢，而生產(chǎn)者持續(xù)發(fā)送消息，導致消息堆積，這時候清除 Backlog 可以幫助消費者快速消費積壓的消息。但是，清除 Backlog 也可能導致生產(chǎn)者發(fā)送的消息被刪除，這會影響到其他消費者讀取消息的順序和完整性。
因此，在清除 Backlog 之前，需要謹慎考慮其影響，并確保所有相關(guān)方都已經(jīng)做好了相應的準備。在實際使用中，可以采用多個消費者訂閱同一個 Topic 的方式來分攤消息的消費壓力，以提高系統(tǒng)的穩(wěn)定性和可靠性?！?/p>
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)勢
開源領(lǐng)域中有諸多優(yōu)秀開源消息隊列，例如 RabbitMQ、Apache RocketMQ、Apache ActiveMQ 和 Apache Kafka。
在前人的基礎(chǔ)上，Pulsar 實現(xiàn)了很多上一代消息系統(tǒng)或者上一代流數(shù)據(jù)系統(tǒng)沒有實現(xiàn)的功能和特性，比如云原生、多租戶、存儲與計算分離、分層存儲這些特性。針對之前消息隊列系統(tǒng)的痛點，Pulsar 做了很多針對化的解決措施。
什么是 Pulsar？
（1）Pulsar 是一個分布式消息平臺，可以同時處理流式數(shù)據(jù)和異構(gòu)系統(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ù)存儲的基礎(chǔ)上構(gòu)建了消息隊列和流服務的統(tǒng)一模型。這使得 Pulsar 不僅有消息隊列的功能（類似 RabbitMQ 和 RocketMQ 在業(yè)務系統(tǒng)中的使用），還是一個數(shù)據(jù)流的處理模型（類似 Kafka 在大數(shù)據(jù)系統(tǒng)中的定位）。
云原生架構(gòu)
云原生是一種在云計算時代構(gòu)建和運行應用程序的方法，可以充分利用和發(fā)揮云平臺的彈性自動化優(yōu)勢。云原生應用程序在云上以最佳方式運行，讓業(yè)務系統(tǒng)的可用性、敏捷性和可擴展性得到大幅提升。
Pulsar 是在消息隊列領(lǐng)域里基于云原生基礎(chǔ)架構(gòu)設(shè)計的產(chǎn)品，擁有諸多云原生應用特性，如無狀態(tài)計算層、計算與存儲分離，可以很好地利用云的彈性（伸縮能力），保證具有足夠的可擴容性和容錯性，能夠很好地在容器化環(huán)境中運行。
Pulsar 的存儲與計算分離架構(gòu)在云原生環(huán)境中有著更大的價值。Pulsar 實例中的存儲節(jié)點可以由一組 Bookie 容器去負責，計算節(jié)點又是由另外一組 Broker 容器去負責。存儲與計算節(jié)點可以完全獨立擴縮容，通過 Kubernetes 這樣的容器編排工具，業(yè)務方可以很快地構(gòu)建彈性擴縮容的云原生消息隊列。
存儲與計算分離
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é)議?；谙㈥犃袇f(xié)議層，目前 Pulsar 已經(jīng)支持了 Kafka、RocketMQ、AMQP 和 MQTT 等多種協(xié)議?；谙㈥犃袇f(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)相結(jié)合，例如關(guān)系型數(shù)據(jù)庫、非關(guān)系型數(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 問題時，求取解決方案的途徑會更加簡單。
不可否認，復雜的架構(gòu)勢必會帶來新的優(yōu)勢，但是也會帶來復雜性的提高，進而導致出現(xiàn)問題的概率會增加。使用 Pulsar 早期版本時，有時會遇到一些奇怪的 bug，需要開發(fā)與維護人員更多的知識儲備與問題處理能力！
《Apache Pulsar 原理解析與應用實踐》
機械工業(yè)出版社《 Apache Pulsar原理解析與應用實踐》》
本書從項目背景、基本概念、架構(gòu)設(shè)計和工程實踐等多角度出發(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)相結(jié)合。所以，通過 Pulsar 可以輕松構(gòu)建出一整套的數(shù)據(jù)服務。本書對這些內(nèi)容均進行了詳細介紹。
本書包括 3 篇 11 章。
基礎(chǔ)篇（第 1~4 章）首先對 Pulsar 的背景進行簡單介紹，并對多種消息隊列進行重點比較分析；然后對 Pulsar 的基本概念和基本架構(gòu)進行分析，讓讀者對 Pulsar 有一個總體的了解；接著分享了 Pulsar 安裝與部署的方法，以方便讀者快速上手并構(gòu)建自己的服務；最后深度解讀了 Pulsar 的基本使用方法。
原理篇（第 5~7 章）首先深度解讀了 Pulsar 的核心組件 Broker、Bookie、ManagedLedger、主題管理等的原理；然后分析了構(gòu)建在這些核心組件之上的高級特性，如事務管理、消息協(xié)議拓展、分層存儲設(shè)計、消息延遲傳遞與主題壓縮；最后對 Pulsar 提供的輕量化流數(shù)據(jù)處理引擎 Pulsar Function 及 I/O 功能進行剖析。
應用篇（第 8~11 章）首先分享了 Pulsar 在結(jié)構(gòu)化數(shù)據(jù)查詢與實時處理引擎技術(shù)方面的實踐，介紹了 Pulsar 如何與 Trino、Flink、Spark 等引擎相結(jié)合；接著對 Pulsar 安全配置、服務管理、服務監(jiān)控等進行討論；最后介紹了 Pulsar 服務的應用模式，以及 Pulsar 在數(shù)據(jù)集成、動態(tài)數(shù)據(jù)捕獲和高可靠性配置等方面的實踐。
JD鏈接
