java—12 kafka

目錄

一、消息隊列的優缺點

二、常用MQ

1. Kafka

2.?RocketMQ

3.?RabbitMQ

4.?ActiveMQ

5.?ZeroMQ

6. MQ選型對比

適用場景——從公司基礎建設力量角度出發

適用場景——從業務場景角度出發

四、基本概念和操作

1. kafka常用術語

2. kafka常用指令

3.?單播消息（group.id相同）

4. 多播消息（group.id不相同）

5. 消費組

?編輯6.?稀疏索引

五、kafka集群

1. 集群搭建

2. 集群啟動和驗證

3. Topic的意義

4. Topic和Partition

5. 分區

6. 副本

7.?集群操作指令

8.?多分區&多副本

9.?多分區消費組

10. Controller

11.?Rebalance機制

12.?HW和LEO

六、高頻面試題

1. 如何防止消息丟失？

2.?如何防止消息的重復消費?

3.?如何做到順序消費?

4.?如何解決消息積壓的問題?

5.?如何實現延遲隊列?

6.?Kafka如何做到單機上百萬的高吞吐量呢？

7.?Kafka高吞吐——非零拷貝技術

8.?Kafka高吞吐——零拷貝技術

一、消息隊列的優缺點

消息隊列的優點：

  1. ① 實現系統解耦
  2. ② 實現異步調用：接口“超時”時，用異步調用節省時間。秒殺中的流程鏈：訂單--庫存--支付--物流，在秒殺的時候，可以將庫存提前放到Redis中，所以只需要關注訂單創建環節即可，
  3. ③ 流量削峰

消息隊列的缺點：

  1. ① 系統可用性降低：當MQ掛掉時，引入的東西越多，出問題的概率越大
  2. ② 提升系統的復雜度
  3. ③ 數據一致性問題：網絡抖動時會出現問題

二、常用MQ

1. Kafka

Apache Kafka是一個分布式消息發布訂閱系統。它最初由LinkedIn公司基于獨特的設計實 現為一個分布式的日志提交系統(a distributed commit log)，之后成為Apache項目的一 部分。Kafka性能高效、可擴展良好并且可持久化。它的分區特性，可復制和可容錯都是 其不錯的特性。

優點：

  1. 客戶端語言豐富：支持Java、.Net、PHP、Ruby、Python、Go等多種語言
  2. 高性能：單機寫入TPS約在100萬條/秒，消息大小10個字節；
  3. 提供完全分布式架構，并有replica機制，擁有較高的可用性和可靠性，理論上支持消息無限堆積；
  4. 消費者采用Pull方式獲取消息。消息有序，通過控制能夠保證所有消息被消費且僅被消費一次；
  5. 在日志領域比較成熟，被多家公司和多個開源項目使用。有管理界面Kafka-Manager / EFAK；

缺點：

  1. Kafka單機超過64個隊列/分區時，Load時會發生明顯的飆高現象。隊列越多，負載越高，發送消息響 應時間變長；
  2. 使用短輪詢方式，實時性取決于輪詢間隔時間；
  3. 消費失敗不支持重試；
  4. 社區更新較慢。

2.?RocketMQ

RocketMQ出自阿里的開源產品，用Java語言實現，在設計時參考了Kafka，并做出了自 己的一些改進，消息可靠性上比Kafka更好。RocketMQ在阿里內部被廣泛應用在訂單， 交易，充值，流計算，消息推送，日志流式處理，binglog分發等場景。

優點：

  1. 單機支持1萬以上持久化隊列；
  2. RocketMQ的所有消息都是持久化的，先寫入系統PAGECACHE，然后刷盤，可以保證內存與磁盤都有 一份數據，而訪問時，直接從內存讀取。
  3. 模型簡單，接口易用（JMS的接口很多場合并不太實用）；
  4. 性能非常好，可以允許大量堆積消息在Broker中；
  5. 支持多種消費模式，包括集群消費、廣播消費等；
  6. 各個環節分布式擴展設計，支持主從和高可用；開發度較活躍，版本更新很快。

缺點：

  1. 支持的客戶端語言不多，目前是Java及C++，其中C++還不成熟；
  2. RocketMQ社區關注度及成熟度也不及Kafka；
  3. 沒有Web管理界面，提供了一個 CLI (命令行界面) 管理工具帶來查詢、管理和診斷各種問題；
  4. 沒有在MQ核心里實現JMS等接口；

3.?RabbitMQ

rabbitmq.com

RabbitMQ于2007年發布，是一個在AMQP(高級消息隊列協議)基礎上完成的，可復用的企 業消息系統，是當前最主流的消息中間件之一。它提供了多種技術可以讓你在性能和可靠 性之間進行權衡。這些技術包括持久性機制、投遞確認、發布者證實和高可用性機制；靈 活的路由，消息在到達隊列前是通過交換機進行路由的。RabbitMQ為典型的路由邏輯提 供了多種內置交換機類型。

優點：

  1. 由于Erlang語言的特性，消息隊列性能較好，支持高并發；
  2. 健壯、穩定、易用、跨平臺、支持多種語言、文檔齊全；
  3. 有消息確認機制和持久化機制，可靠性高； 高度可定制的路由；
  4. 管理界面較豐富，在互聯網公司也有較大規模的應用，社區活躍度高。

缺點：

  1. 實現了代理架構，意味著消息在發送到客戶端之前可以在中央節點上排隊。此特性使得RabbitMQ易 于使用和部署，但是使得其運行速度較慢，因為中央節點增加了延遲，消息封裝后也比較大；需要學習比 較復雜的接口和協議，學習和維護成本較高。
  2. 盡管結合 Erlang 語言本身的并發優勢，性能較好，但是不利于做二次開發和維護；

4.?ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ是一個完全支持JMS1.1和J2EE 1.4規范的JMS Provider實現。它非常快速，支持多種語言的客戶端和協議，而且可以非常容易的嵌入到 企業的應用環境中，并有許多高級功能。

優點：基于java，適合二次開發

  1. 可以用JDBC：可以將數據持久化到數據庫。雖然使用JDBC會降低ActiveMQ的性能，但是數據庫一直都 是開發人員最熟悉的存儲介質；
  2. 支持JMS規范：支持JMS規范提供的統一接口;
  3. 支持自動重連和錯誤重試機制；
  4. 有安全機制：支持基于shiro，jaas等多種安全配置機制，可以對Queue/Topic進行認證和授權；
  5. 監控完善：擁有完善的監控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API；
  6. 界面友善：提供的WebConsole可以滿足大部分情況，還有很多第三方的組件可以使用，比如hawtio；

缺點：

  1. 社區活躍度不及RabbitMQ高；
  2. 根據其他用戶反饋，會出莫名其妙的問題，會丟失消息；
  3. 目前重心放到activemq6.0產品Apollo，對5.x的維護較少；
  4. 不適合用于上千個隊列的應用場景；

5.?ZeroMQ

號稱史上最快的消息隊列，它實際類似于Socket的一系列接口，他跟Socket的區別是：普 通的socket是端到端的（1:1的關系），而ZMQ卻是可以N：M 的關系，人們對BSD套接字 的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協議 （TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網絡編程更為簡單。ZMQ用 于node與node間的通信，node可以是主機或者是進程。

引用官方的說法： “ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的 一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列 庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是“成為標準網絡協議棧 的一部分，之后進入Linux內核”。

與RabbitMQ相比，ZMQ并不像是一個傳統意義上的消息隊列服務器，事實上，它也根本不 是一個服務器，更像一個底層的網絡通訊庫，在Socket API之上做了一層封裝，將網絡通 訊、進程通訊和線程通訊抽象為統一的API接口。支持“Request-Reply “，”Publisher Subscriber“，”Parallel Pipeline”三種基本模型和擴展模型。

6. MQ選型對比

偏業務的選前三種，非業務或者日志的選kafka。?

總結：消息隊列的選型需要根據具體應用需求而定，ZeroMQ小而美，RabbitMQ大而穩，Kakfa和RocketMQ快而強勁。

適用場景——從公司基礎建設力量角度出發

中小型軟件公司，建議選RabbitMQ 首先：erlang語言天生具備高并發的特性，而且他的管理界面用起來十分方便。他的弊端 也很明顯，雖然RabbitMQ是開源的，然而國內有幾個能定制化開發erlang的程序員呢？所幸， RabbitMQ的社區十分活躍，可以解決開發過程中遇到的bug，這點對于中小型公司來說十分重 要。

其次：不考慮Kafka的原因是，一方面中小型軟件公司不如互聯網公司，數據量沒那么大， 選消息中間件，應首選功能比較完備的，所以kafka排除。 最后：不考慮RocketMQ的原因是，RocketMQ是阿里出品，如果阿里放棄維護RocketMQ， 中小型公司一般抽不出人來進行RocketMQ的定制化開發，因此不推薦。

大型軟件公司 根據具體使用在RocketMQ和kafka之間二選一。 一方面，大型軟件公司，具備足夠的資金搭建分布式環境，也具備足夠大的數據量。 針對RocketMQ，大型軟件公司也可以抽出人手對RocketMQ進行定制化開發，畢竟國內有 能力改JAVA源碼的人，還是相當多的。 至于kafka，根據業務場景選擇，如果有日志采集功能，肯定是首選kafka了。

適用場景——從業務場景角度出發

RocketMQ定位于非日志的可靠消息傳輸（日志場景也OK），目前RocketMQ在阿里集團被 廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發等場景。

Kafka是LinkedIn開源的分布式發布-訂閱消息系統，目前歸屬于Apache頂級項目。Kafka主 要特點是基于Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集 和傳輸。0.8版本開始支持復制，不支持事務，對消息的重復、丟失、錯誤沒有嚴格要求， 適合產生大量數據的互聯網服務的數據收集業務。

RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基于AMQP協議來實現。AMQP的主 要特征是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。AMQP協議更 多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要 求還在其次。

三、安裝

四、基本概念和操作

1. kafka常用術語（面）

名詞解釋
Broker【節點】一個Kafka節點就是一個Broker，一個和多個Broker可以組成 一個Kafka集群
Topic【主題】Kafka根據topic對消息進行歸類，發布到kafka集群的每套消 息都需要指定一個topic，topic是一個邏輯概念，物理上是不存在的
Producer【生產者】用于向Kafka中發送消息
Consumer【消費者】從Kafka中獲取消息（kafka中是拉pull的方式；RocketMQ可推可拉，本質是拉，因為有個中間代理從MQ拉過來再推給消費者）
Consumer Group【消費組】每個Consumer都會歸屬于一個消費組，一條消息可以同時 被多個不同的消費組消費，但是只能被一個消費組中的消費者消費
Partition

【分片】物理上的概念，可以將一個topic上的數據拆分為多分放到 Partition中，每個Patition內部的消息是有序的。

作用：1. 防止數據全部放在一起造成全部丟失；2. 獲得一個更高的存儲量（總存儲量為所有分片的加和）

2. kafka常用指令

創建主題

  • ./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic muse -- partitions 1 --replication-factor 1

查看主題

  • ./kafka-topics.sh --list --bootstrap-server localhost:9092

開啟消息生產端

  • ./kafka-console-producer.sh --topic muse --bootstrap-server localhost:9092

開啟消息消費端

  • ./kafka-console-consumer.sh --topic muse --bootstrap-server localhost:9092
  • ./kafka-console-consumer.sh --topic muse --bootstrap-server localhost:9092 --from-beginning

3. kafka中的消息讀取

消息是會被存儲在kafka中的文件里的（存儲路徑可以通過server.properties文件中的log.dirs屬性來指定），并且是順序存儲的，消息有偏移量的概念，所以我們可以指定偏移量去讀取某個位置的消息。默認位置從消息的結尾。

4.?單播消息（group.id相同）（面）

一個消費組里，只會有一個消費者能夠消費到某個topic中的消息。

首先，打開兩個窗口，分別執行如下語句開啟消費端，那么就在“museGroup1”消費組中創 建了兩個Consumer

  • ./kafka-console-consumer.sh --topic muse --bootstrap-server localhost:9092 --consumer-property group.id=museGroup1

然后：Producer端發送3條消息，我們發現，只有一個Consumer收到了消息。

5. 多播消息（group.id不相同）（面）

當業務場景中，需要同一個topic下的消息被多個消費者消費，那么我們可以采用創建多個消費組的方式，那么這種方式就是多播消息。打開兩個窗口，分別執行如下指令：

  • ./kafka-console-consumer.sh --topic muse --bootstrap-server localhost:9092 --consumer property group.id=museGroup1
  • ./kafka-console-consumer.sh --topic muse --bootstrap-server localhost:9092 --consumer property group.id=museGroup2

最后，Producer端發送3條消息，我們發現，兩個Consumer都收到了消息。如下所示：

6. 消費組

查看當前主題下有哪些消費組

  • ./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list

查看消費組中的具體信息

  • ./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group museGroup1 --describe

其中，展現出來的信息有如下含義：

  • CURRENT-OFFSET：當前消費組已消費消息的偏移量。
  • LOG-END-OFFSET：主題對應分區消息的結束偏移量（水位——HW）。
  • LAG：當前消費組堆積未消費的消息數量。

__consumer_offsets-N

kafka默認創建了一個擁有50個分區的主題，名稱為：“__consumer_offsets”。

consumer會將消費分區的offset提交給kafka內部topic：__consumer_offsets，提交過去 的時候，【key】=consumerGroupID+topic+分區號，【value】=當前offset的值。

Kafka會定期清理topic里的消息，最后就保留最新的那條數據。可以通過如下公式確定 consumer消費的offset要提交到哪個__consumer_offsets? ?hash(consumerGroupID)% 主題“__consumer_offsets”的分區數量

7.?稀疏索引（面）

索引是有序的

五、kafka集群

1. 集群搭建

創建kafka-cluster目錄，并解壓kafka_2.13-3.0.0.tgz為3份kafka

修改kafka1的server.propertis配置文件

  • broker.id=10 listeners=PLAINTEXT://localhost:9093 log.dirs=/Users/muse/Lesson/ServerContext/kafka-cluster/kafka1/kafka-logs

修改kafka2的server.propertis配置文件

  • broker.id=11 listeners=PLAINTEXT://localhost:9094 log.dirs=/Users/muse/Lesson/ServerContext/kafka-cluster/kafka2/kafka-logs

修改kafka3的server.propertis配置文件

  • broker.id=12 listeners=PLAINTEXT://localhost:9095 log.dirs=/Users/muse/Lesson/ServerContext/kafka-cluster/kafka3/kafka-logs

2. 集群啟動和驗證

啟動kafka1，kafka2和kafka3

  • ./kafka1/bin/kafka-server-start.sh -daemon ./kafka1/config/server.properties
  • ./kafka2/bin/kafka-server-start.sh -daemon ./kafka2/config/server.properties
  • ./kafka3/bin/kafka-server-start.sh -daemon ./kafka3/config/server.properties

驗證3個Broker是否啟動成功

  • 首先，可以通過ps -ef | grep kafka來查看進程是否啟動
  • 其次：在zookeeper中查看/brokers/ids下中是否有相應的brokerId目錄生成

3. Topic的意義

試想一下，當我們要嘗試發送 /消費消息的時候需要注意什 么呢？“這有啥需要注意的， 發送不就得了！” 結果，我們發現了一個非常重 大的問題，大家都往Kafka中 發送消息，所有的消息都混合 在了一起，就類似所有快遞公 司的快遞員（Producer端）把 快遞都扔到了一個大倉庫里， 結果，去取快遞的小伙伴們 （Consumer端）面對堆積如 山且混亂不堪的“快遞山”—— 瘋了。。。

topic是邏輯的概念，topic+partition是物理概念。

4. Topic和Partition

5. 分區

一個主題中的消息量是非常大的，因此可以通過分區的設置，來分布式存儲這些消息。 并且分區也可以提供消息并發存儲的能力。

作用： 可以存儲更多的數據，并且其中一個分區掛掉之后，不至于全部消息丟失。

6. 副本

如果分片掛掉了，數據就丟失了。那么為了提高系統的可用性。我們把分片復制多個，這 就是副本了。但是，副本的產生，也會隨之帶來數據一致性的問題，即：有的副本寫數據 成功，但是有的副本寫數據失敗。

Leader：kafka的讀寫操作都發生在leader上，leader負責把數據同步給follower。 當leader掛掉了，那么經過主從選舉，從多個follower中選舉產生一個新的leader。

Follower：follower接收leader同步過來的數據，它不提供讀寫（主要是為了保證多副本數據與消費 的一致性）

7.?集群操作指令

為名稱為muse-rp的Topic創建2個分區（--partitions）3個副本（--replication-factor）

  • ./kafka-topics.sh --create --topic muse-rp --bootstrap-server localhost:9093 localhost:9094 localhost:9095 --partitions 2 --replication-factor 3

刪除Topic

  • ./kafka-topics.sh --delete --topic muse-rp --bootstrap-server localhost:9093 localhost:9094 localhost:9095

查看分區和副本分布情況

  • ./kafka-topics.sh --describe --topic muse-rp --bootstrap-server localhost:9093 localhost:9094 localhost:9095

消息發送和消費

  • ./kafka-console-producer.sh --topic muse-rp --bootstrap-server localhost:9093 localhost:9094 localhost:9095
  • ./kafka-console-consumer.sh --topic muse-rp --bootstrap-server localhost:9093 localhost:9094 localhost:9095 --consumer-property group.id=museGroup1

8.?多分區&多副本

為名稱為muse-rp的Topic創建---------------------------- 2個分區（--partitions） 3個副本（--replication-factor）

9.?多分區消費組

一個partition只能被一個消費組中的一個消費者消費，這樣設計的目的是保證消息的有序 性，但是在多個partition的多個消費者消費的總順序性是無法得到保證的。

partition的數量決定了消費組中Consumer的數量，建議同一個消費組中的Consumer數量 不要超過partition的數量，否則多余的Consumer就無法消費到消息了。

但是，如果消費者掛掉了，那么就會觸發rebalance機制，會由其他消費者來消費該分區。

10. Rebalance機制（面）

當消費者沒有指明分區消費時，消費組里的消費者和分區關系發生了變化，那么就會觸發 rebalance機制。這個機制會重新調整消費者消費哪個分區。

在觸發rebalance機制之前，消費者消費哪個分區有3種策略：

1> range：通過公式來計算某個消費者消費哪個分區。

2> 輪詢：大家輪流對分區進行消費。

3> sticky：在觸發rebalance之后，在消費者消費的原分區不變的基礎上進行調整。

11.?Controller

Kafka集群中的Broker在ZK中創建臨時序號節點，序號最小的節點也就是最先創建的那個 節點，將作為集群的Controller，負責管理整個集群中的所有分區和副本的狀態。

Controller控制器的作用如下：

  • ① 當某個分區的leader副本出現故障時，由控制器負責為該分區選舉出新的leader副本。
  • ② 當檢測到某個分區的ISR集合發生變化時，由控制器負責通知所有broker更新其元數 據信息。
  • ③ 當使用kafka-topics.sh腳本為某個topic增加分區數量時，同樣還是由控制器負責讓 新分區被其他節點感知到。

12.?HW和LEO

HW（HighWatermark）俗稱高水位，取一個partition對應的ISR中最小的LEO（log-end offset）作為HW；

Consumer最多只能消費到HW所在的位置，每個副本都有HW，Leader和Follower各自負 責更新自己的HW的狀態。

對于Leader新寫入的消息，Consumer不能立刻消費，Leader會等待該消息被所有ISR中的副本同步后更新HW，此時消息才能被Consumer所消費。這樣就能保證如果Leader所在的 broker失效，該消息仍然可以從新選舉的Leader中獲取。保證數據的一致性。

具體邏輯請看下一張圖：

六、高頻面試題

1. 如何防止消息丟失？

針對發送方：將ack設置為1或者-1/all可以防止消息丟失，如果要做到99.9999%，ack要設 置為all，并把min.insync.replicas配置成分區備份數

針對接收方：把自動提交修改為手動提交(enable-auto-commit)。（自動提交的話，錯誤的消息可能會被略過而處理接下來的其他消息，可能導致原本可以通過重新提交恢復正常的數據丟失，對業務造成影響。）

發出消息持久化機制參數：

  • acks=0: ?表示producer不需要等待任何broker確認收到消息的ACK回復，就可以繼續發送下一條消息。性能最高，但是最容易丟失消息
  • acks=1: ?表示至少等待leader已經成功將數據寫入本地log，但是不需要等待所有follower都寫入成功，就可以繼續發送下一條消息。
    • 這種情況下，如果follower沒有成功備份數據，而此時leader又掛掉，則消息就會丟失。
  • acks=-1: 表示kafka ISR列表中所有的副本同步數據成功，才返回消息給客戶端，這是最強的數據保證。min.insync.replicas（默認為1，推薦配置>=2）這個配置是用來設置同步副本個數的下限的, 并不是只有 min.insync.replicas 個副本同步成功就返回ack。而是，只要acks=all就意味著ISR列表里面的副本必須都要同步成功。

0：日志采集的情況，數據最高的吞吐量

-1：數據持久化最高的程度

??

2.?如何防止消息的重復消費?

一條消息被消費者消費多次，如果為了不消費到重復的消息，我們需要在消費端增加冪等性處理，例如：

  • ① 通過mysql插入業務id作為主鍵，因為主鍵具有唯一性，所以一次只能插 入一條業務數據。
  • ② 使用redis或zk的分布式鎖，實現對業務數據的冪等操作。

3.?如何做到順序消費?

針對發送方：在發送時將ack配置為非0（0的話可能會有消息丟失，消息補全談不上有序），確保消息至少同步到leader之后再返回ack繼續發 送。但是，只能保證分區內部的消息是順序的，而無法保證一個Topic下的多個分 區總的消息是有序的。

針對接收方：消息發送到一個分區中，只配置一個消費組的消費者來接收消息，那么這個 Consumer所接收到的消息就是有順序的了，不過這也就犧牲掉了性能。

4.?如何解決消息積壓的問題?※

消息積壓會導致很多問題，比如：磁盤被打滿、Producer發送消息導致kafka 性能過慢，然后就有可能發生服務雪崩。解決的方案如下所示：

① 提升一個Consumer的處理能力。即：在一個消費者中啟動多個線程，讓 多線程加快消費的速度。

② 提升總體Consumer的處理能力。啟動多個消費組，增加Consumer的數量（同時也要增加partition的數量）從而提高消費能力。

③ 如果業務運行，設定某個時間內，如果消息仍沒有被消費，那么Consumer收到消息后，直接廢棄掉，不執行下面的業務邏輯。

5.?如何實現延遲隊列?

（kafka默認不支持延遲隊列）

應用場景：訂單創建成功后如果超過30分鐘沒有付款，則需要取消訂單。

  • ① 創建一個表示“訂單30分鐘未支付”的Topic，如：order_not_paid_30min， 表示延遲30分鐘的消息隊列。
  • ② Producer發送消息的時候，消息內容要帶上訂單生成的時間create_time。
  • ③ Consumer消費Topic中的消息，如果發現now減去create_time不足30分鐘， 則不去消費；記錄當前的offset，不去消費當前以及之后的消息。
  • ④ 通過記錄的offset去獲取消息，如果發現消息已經超過30分鐘且訂單狀態 是“未支付”，那么則將訂單狀態設置為“取消”，然后獲取下一個offset的 消息。

6.?Kafka如何做到單機上百萬的高吞吐量呢？

  • 寫入數據：主要是依靠頁面緩存技術 + 磁盤順序寫實現的。
  • 讀取數據：主要依靠零拷貝技術實現的。

7.?Kafka高吞吐——非零拷貝技術

通過下圖過程的描述，很明顯可以看到存在兩次沒必要的copy，一次是從OS Cache里拷 貝到Kafka進程的緩存里，接著又從Kafka進程的緩存里拷貝回OS的Socket緩存里。而且 為了進行這兩次拷貝，中間還發生了好幾次上下文切換，一會兒是Kafka進程在執行，一 會兒上下文切換到操作系統來執行，所以這種方式來讀取數據是比較消耗性能的。

8.?Kafka高吞吐——零拷貝技術

Kafka為了解決非零拷貝這個問題，在讀數據的時候是引入零拷貝技術。也就是說，通過 OS的sendfile技術直接讓OS Cache中的數據發送到網卡后傳輸給下游的消費者，中間跳 過了兩次拷貝數據的步驟。通過零拷貝技術，就不需要把OS Cache里的數據拷貝到應用 緩存，再從應用緩存拷貝到 Socket 緩存了，兩次拷貝都省略了，所以叫做零拷貝

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/bicheng/78686.shtml
繁體地址，請注明出處：http://hk.pswp.cn/bicheng/78686.shtml
英文地址，請注明出處：http://en.pswp.cn/bicheng/78686.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

14【模塊學習】74HC595：使用學習

14【模塊學習】74HC595：使用學習

74HC595 1、74HC595簡介2、代碼演示2.1、驅動8位流水燈 3、74HC595級聯3.1、驅動16位流水燈3.2、驅動8位數碼管3.3、驅動8x8點陣屏幕3.4、8x8點陣屏幕滾動顯示 1、74HC595簡介 在51單片機中IO引腳資源十分的緊缺，所以常常需要使用75HC595芯片進行驅動那些需要占用多…
閱讀更多...
JAVA后端開發常用的LINUX命令總結

JAVA后端開發常用的LINUX命令總結

一、Linux常用命令大全（2025年最新版） 常用 Linux 命令 文件和目錄管理： cd：用于切換當前工作目錄，如cd /home/user。mkdir：創建新目錄，mkdir -p /home/user/mydir可遞歸創建多級目錄。pwd&am…
閱讀更多...
uniapp-商城-40-shop 購物車 選好了 進行訂單確認4 配送方式3 地址編輯

uniapp-商城-40-shop 購物車 選好了 進行訂單確認4 配送方式3 地址編輯

前面說了配送 和地址頁面 當地址頁面為空或需要添加地址時&#xff0c;需要添加地址。 我的地址頁面有個按鈕 就是添加地址 點擊 添加地址 按鈕 后&#xff0c;就會跳轉到地址添加的頁面 1、添加地址頁面 2、添加地址文件夾以及文件的創建 3、添加地址的代碼 <template…
閱讀更多...
現場問題排查-postgresql某表索引損壞導致指定數據無法更新影響卷宗材料上傳

現場問題排查-postgresql某表索引損壞導致指定數據無法更新影響卷宗材料上傳

問題現象 今天突然被拉進一個群&#xff0c;說某地區友商推送編目結果報錯&#xff0c;在我們自己的卷宗系統上傳材料也一直轉圈&#xff0c;也刪除不了案件卷宗&#xff0c;重置模板也沒用&#xff0c;只有個別案件有問題。雖然這事兒不屬于我負責&#xff0c;但還是抽時間給…
閱讀更多...
Redis01-基礎-入門

Redis01-基礎-入門

零、文章目錄 Redis01-基礎-入門 1、認識 NoSQL NoSQL 知識請參考&#xff1a;https://blog.csdn.net/liyou123456789/article/details/132612444 2、認識 Redis &#xff08;1&#xff09;簡介 Redis&#xff08;Remote Dictionary Server&#xff0c;遠程字典服務&…
閱讀更多...
【嘉立創EDA】如何在更新或轉換原理圖到PCB時，保留已有布局器件

【嘉立創EDA】如何在更新或轉換原理圖到PCB時，保留已有布局器件

文章路標?? :one: 文章解決問題:two: 主題內容:three: 參考方法be end..1?? 文章解決問題 操作環境：嘉立創EDA專業版 V2.2.37 本文使用嘉立創EDA，描述在更新或轉換原理圖到PCB時，保留已有布局器件的方法。本文將此過程記錄，以供有需要的讀者參考。 2?? 主題內容 …
閱讀更多...
03 APQC PROCESS CLASSIFICATION FRAMEWORK (PCF)

03 APQC PROCESS CLASSIFICATION FRAMEWORK (PCF)

APQC流程分類框架&#xff08;APQC Process Classification Framework, PCF&#xff09;最初由美國生產力與質量中心&#xff08;American Productivity & Quality Center, APQC&#xff09;開發&#xff0c;旨在用于跨組織的流程性能基準比較。現在&#xff0c;它也常被用…
閱讀更多...
分析型數據庫入門指南：如何選擇適合你的實時分析工具？

分析型數據庫入門指南：如何選擇適合你的實時分析工具？

一、什么是分析型數據庫&#xff1f;為什么需要它&#xff1f; 據Gartner最新報告顯示&#xff0c;超過75%的企業現已在關鍵業務部門部署了專門的分析型數據庫&#xff0c;這一比例還在持續增長。 隨著數據量呈指數級增長&#xff0c;傳統數據庫已無法滿足復雜分析場景的需求…
閱讀更多...
body Param Query 三個 不同的入參 分別是什么意思 在前端 要怎么傳 這三種不同的參數

body Param Query 三個 不同的入參 分別是什么意思 在前端 要怎么傳 這三種不同的參數

在 NestJS 中&#xff0c;Body()、Param() 和 Query() 用于處理不同類型的請求參數。以下是它們的含義及前端傳遞方式&#xff1a; Body()&#xff1a;請求體參數 ? 含義&#xff1a;用于獲取請求體中的數據&#xff08;如 POST/PUT 請求中提交的 JSON、表單數據等&#xff09…
閱讀更多...
神經網絡（自己記錄）

神經網絡（自己記錄）

一、神經網絡基礎 5分鐘-通俗易懂 - 神經網絡 反向傳播算法&#xff08;手算&#xff09;_嗶哩嗶哩_bilibili 二、GAT
閱讀更多...
Redis Slot 槽位分片具體案例

Redis Slot 槽位分片具體案例

?鍵值槽位分配案例? 當執行 SET {kaigejava}k1 v1 時&#xff0c;Redis 會提取 {} 內的有效部分 kaigejava&#xff0c;通過 CRC16 算法計算哈希值&#xff0c;再對 16384 取余得到槽位。例如&#xff1a; 若計算結果為 1495&#xff0c;則該鍵會被分配到槽位 1495 對應的節…
閱讀更多...
【多模態模型】跨模態智能的核心技術與應用實踐

【多模態模型】跨模態智能的核心技術與應用實踐

目錄 前言技術背景與價值當前技術痛點解決方案概述目標讀者說明 一、技術原理剖析核心概念圖解核心作用講解關鍵技術模塊說明技術選型對比 二、實戰演示環境配置要求核心代碼實現&#xff08;CLIP圖像-文本檢索&#xff09;運行結果驗證 三、性能對比測試方法論量化數據對比結果…
閱讀更多...
final static 中是什么final static聯合使用呢

final static 中是什么final static聯合使用呢

final static 聯合使用詳解 final 和 static 在 Java 中經常一起使用&#xff0c;主要用來定義類級別的常量。這種組合具有兩者的特性&#xff1a; 基本用法 public class Constants {// 典型的 final static 常量定義public static final double PI 3.141592653589793;pub…
閱讀更多...
1.1 道路結構特征

1.1 道路結構特征

1.1 道路結構特征 1.城市道路分類 道路網的地位、交通功能、沿線的服務功能。快速路 15 30主干路 15 30次干路 15 20支路 10 20 10(20)瀝青路面、水泥混凝土路面、砌塊路面瀝青路面:瀝青混凝土、瀝青貫入式、瀝青表面處治。瀝青混凝土各種等級、瀝青貫入式和瀝青表面處治支路…
閱讀更多...
C++如何使用調試器（如GDB、LLDB）進行程序調試保姆級教程（2萬字長文）

C++如何使用調試器（如GDB、LLDB）進行程序調試保姆級教程（2萬字長文）

C++作為一門高性能、接近底層的編程語言，其復雜性和靈活性為開發者提供了強大的能力，同時也帶來了更高的調試難度。與一些高級語言不同，C++程序往往直接操作內存，涉及指針、引用、多線程等特性，這些都可能成為錯誤的溫床。例如，一個未初始化的指針可能導致程序崩潰，而一…
閱讀更多...
vite+vue構建的網站項目localhost：5173打不開

vite+vue構建的網站項目localhost：5173打不開

原因&#xff1a;關掉了cmd命令提示符&#xff0c;那個端口就沒有被配置上&#xff0c;打開就是這樣的。 解決方法&#xff1a;重新在工作目錄下打開cmd&#xff0c;輸入npm run dev重新啟動項目。 重新出現這樣的界面說明已經成功啟動項目&#xff0c;再次在瀏覽器中刷新并輸入…
閱讀更多...
自主可控鴻道Intewell工業實時操作系統

自主可控鴻道Intewell工業實時操作系統

鴻道Intewell工業實時操作系統是東土科技旗下科東軟件自主研發的新一代智能工業操作系統&#xff0c;以下是相關介紹&#xff1a; 系統架構 -Intewell-C全實時構型&#xff1a;設備上只運行自研RTOS的全實時系統&#xff0c;適用于有功能安全認證需求的實時控制場景&#xf…
閱讀更多...
將大語言模型（LLM）應用于自動駕駛（ADAS）中的幾個方向，及相關論文示例

將大語言模型（LLM）應用于自動駕駛（ADAS）中的幾個方向，及相關論文示例

主要方法集中在如何利用LLM的強大推理能力和語言理解能力來增強自動駕駛系統的感知、決策和規劃能力。以下是幾種典型的方法和思路&#xff1a; 1. 基于LLM的駕駛決策與規劃 方法&#xff1a;將LLM作為駕駛決策的核心模塊&#xff0c;利用其強大的推理能力生成駕駛行為或軌跡…
閱讀更多...
rt-linux下的D狀態的堆棧抓取及TASK_RTLOCK_WAIT狀態

rt-linux下的D狀態的堆棧抓取及TASK_RTLOCK_WAIT狀態

一、背景 在之前的博客 缺頁異常導致的iowait打印出相關文件的絕對路徑-CSDN博客 里的 2.1 一節里的代碼&#xff0c;我們已經有了一個比較強大的抓取D狀態和等IO狀態超過閾值的waker和wakee的堆棧狀態的內核模塊。在之前的博客 增加等IO狀態的喚醒堆棧打印及缺頁異常導致iowa…
閱讀更多...
【Redis】zset類型

【Redis】zset類型

目錄 1、介紹2、底層實現【1】壓縮列表【2】跳躍表哈希表 3、常用命令 1、介紹 有序集合結合了集合和有序列表的特性&#xff0c;每個元素都會關聯一個分數&#xff0c;Redis正是通過這個分數來為集合中的成員進行排序。 2、底層實現 【1】壓縮列表 適用條件 1、元素數量 ≤…
閱讀更多...
最新文章

Copyright @ 2022~2023