你好，Kafka，再見(jiàn)，RabbitMQ！
“容器、Kubernetes、DevOps、微服務(wù)、云原生，這些技術(shù)名詞的頻繁出現(xiàn)，預(yù)兆著新的互聯(lián)網(wǎng)技術(shù)時(shí)代的到來(lái)，大數(shù)據(jù)高并發(fā)將不再遙遠(yuǎn)，而是大部分項(xiàng)目都必須面對(duì)的，消息隊(duì)列則是核心利器！成熟的消息隊(duì)列產(chǎn)品很多，該如何技術(shù)選型？下面是翻譯自Confluent 官方博客的消息隊(duì)列性能對(duì)比測(cè)試。
原文地址：https://www.confluent.io/blog/kafka-fastest-messaging-system/”
文：Yiru-Chen??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
云硬件Kafka
性能測(cè)試
眾所周知Kafka快，究竟有多快，跟其他隊(duì)列相比又如何？這里選擇了Kafka、RabbitMQ 和Apache Pulsar進(jìn)行測(cè)試，關(guān)注點(diǎn)是系統(tǒng)吞吐量?和系統(tǒng)延遲，因?yàn)樗鼈兪巧a(chǎn)中事件流處理系統(tǒng)的核心性能指標(biāo)。具體來(lái)說(shuō)，吞吐量測(cè)試測(cè)量隊(duì)列在硬件（特別是磁盤和 CPU）使用方面的效率。延遲測(cè)試測(cè)量每個(gè)系統(tǒng)傳遞實(shí)時(shí)消息的差別，這是實(shí)時(shí)任務(wù)關(guān)鍵型應(yīng)用程序以及微服務(wù)架構(gòu)的核心要求。
最終結(jié)論：
吞吐量：Kafka 在三個(gè)系統(tǒng)中的吞吐量最高，是 RabbitMQ 的 15 倍，Pulsar 的 2 倍。
系統(tǒng)延遲：Kafka 在較高的吞吐量下提供了最低的延遲，同時(shí)還提供了強(qiáng)大的持久性和高可用性。RabbitMQ 可以實(shí)現(xiàn)比 Kafka 更低的端到端延遲，但只能在吞吐量低很多的情況下。
Kafak的高吞吐和低延遲是怎么實(shí)現(xiàn)的？Kafak有著極為優(yōu)秀和出色的設(shè)計(jì)，一是頁(yè)緩存技術(shù)+磁盤順序?qū)懀皇橇憧截惣夹g(shù)！
頁(yè)緩存技術(shù)
磁盤順序?qū)?/strong>
Kafka的消息數(shù)據(jù)是寫在硬盤上的，保證了消息數(shù)據(jù)的可靠性，但寫硬盤還能保證幾十萬(wàn)條/秒的消息處理速度，是怎么做到的？答案是基于操作系統(tǒng)的頁(yè)緩存和磁盤順序?qū)憗?lái)實(shí)現(xiàn)的。
頁(yè)緩存page cache，就是操作系統(tǒng)自己管理的內(nèi)存緩存，也叫os cache。Kafka在寫入消息時(shí)，是直接寫入頁(yè)緩存，然后由操作系統(tǒng)決定什么時(shí)候把頁(yè)緩存里的數(shù)據(jù)刷入磁盤文件中。這樣一來(lái)，消息寫入性能就變成了寫內(nèi)存，不是在寫磁盤，請(qǐng)看下圖。
常規(guī)的磁盤寫入都是隨機(jī)寫，隨便找到文件的某個(gè)位置來(lái)寫數(shù)據(jù)，這樣的性能非常差，但是追加文件末尾按照順序的方式來(lái)寫數(shù)據(jù)的話，其寫入性能跟寫內(nèi)存的性能都相差無(wú)幾的。Kafak就是采用順序?qū)懙姆桨福偌由享?yè)緩存的應(yīng)用，才能做到在普通服務(wù)器上每秒寫入幾十萬(wàn)條消息，實(shí)現(xiàn)了數(shù)據(jù)寫入的超高性能。
零拷貝技術(shù)
解決了寫入問(wèn)題，那消息讀取呢？頻繁的從磁盤讀數(shù)據(jù)然后發(fā)給消費(fèi)者，性能又是如何保證的？Kafka為了解決這個(gè)問(wèn)題，在讀數(shù)據(jù)的時(shí)候是引入零拷貝技術(shù)。
先看圖1是常規(guī)的硬盤讀寫流程，操作系統(tǒng)讀取硬盤數(shù)據(jù)后放在OS Cache，然后需要拷貝一次到Kafka進(jìn)程，然后Kafka再將數(shù)據(jù)拷貝到Socket緩存才能發(fā)送到網(wǎng)卡，這樣流程的性能當(dāng)然沒(méi)有保障。
再看圖2， Kafka的設(shè)計(jì)為直接將操作系統(tǒng)OS Cache中的數(shù)據(jù)發(fā)送到網(wǎng)卡，跳過(guò)了兩次拷貝數(shù)據(jù)的步驟，Socket緩存中僅僅會(huì)拷貝一個(gè)描述符過(guò)去，不會(huì)拷貝數(shù)據(jù)到Socket緩存，大大提升了數(shù)據(jù)讀取性能。
分享大會(huì)第五期
Kafka作為海量數(shù)據(jù)大并發(fā)高吞吐的消息隊(duì)列首選，在底層架構(gòu)設(shè)計(jì)上有太多的技術(shù)點(diǎn)，有人說(shuō)駕馭Kafka隊(duì)列的難度較高。其實(shí)是路子沒(méi)走對(duì)！
—張文亮《深入淺出Kafka：源碼解析與實(shí)踐原理》
此書言論一出，立馬引發(fā)社區(qū)各種呵呵，都說(shuō)是耍嘴皮子功夫？為了向大伙證明實(shí)力，早在7月份他就在籌劃本次分享。?對(duì)Kafka感興趣的小伙伴都來(lái)聽(tīng)聽(tīng)吧！DotNet社區(qū)分享大會(huì)第五期：高吞吐低延遲Kafka實(shí)戰(zhàn)之道！
號(hào)稱自己筆記都能出書的文亮在圈內(nèi)大小算個(gè)人物了，尤其在Kafka技術(shù)領(lǐng)域“屢放厥詞”，作為專業(yè)書的首席作者，文亮好歹也是做了多年開(kāi)發(fā)的老架構(gòu)師了，那駕馭Kafka如何才能走對(duì)路，今晚8點(diǎn)，是翻車還是封神，讓我們拭目以待！
