[toc]

• 概述
• 關(guān)于消息隊(duì)列的幾個(gè)問題
• 為什么使用消息隊(duì)列？
• 消息隊(duì)列的缺點(diǎn)
• 消息隊(duì)列如何選型
  • RabbitMQ
  • 阿里云MNS
  • 阿里云ONS / RocketMQ
  • Kafka
  • 產(chǎn)品總結(jié)
• 如何保證消息隊(duì)列的可用性
• 如何保證消息不被重復(fù)消費(fèi)(冪等性)
• 如何保證消費(fèi)的可靠傳輸
  • 生產(chǎn)者丟數(shù)據(jù)
  • 消息隊(duì)列丟數(shù)據(jù)
  • 消費(fèi)者丟數(shù)據(jù)
  • 結(jié)論
    • 生產(chǎn)者丟數(shù)據(jù)
    • 消息隊(duì)列丟數(shù)據(jù)
    • 消費(fèi)者丟數(shù)據(jù)
• 如何保證消息的順序性
• Kafka
  • 名詞解釋
  • partition
  • 消費(fèi)組
  • 在 zk 中存了什么
  • Kafka的API
  • Kakfa Broker Leader的選舉
  • kafka常見的一些問題
    • 消息傳輸一致性語義
    • kafka 為什么這么快
    • 怎么保證發(fā)送消息不丟失(多副本同步機(jī)制)
  • kafka 參考文獻(xiàn)

概述

2019317131343

分析一個(gè)消息隊(duì)列主要從這幾個(gè)點(diǎn)出來。
在后半部分主要分析了 kafka 對以上幾點(diǎn)的保證。

關(guān)于消息隊(duì)列的幾個(gè)問題

為什么用RocketMQ或者是Kafka？技術(shù)選型的依據(jù)是什么？

你們怎么保證消息中間件的高可用性？避免消息中間件故障后引發(fā)系統(tǒng)整體故障？

使用消息中間件技術(shù)的時(shí)候，你們怎么保證投遞出去的消息一定不會丟失？

你們怎么保證投遞出去的消息只有一條且僅僅一條，不會出現(xiàn)重復(fù)的數(shù)據(jù)？

如果消費(fèi)了重復(fù)的消息怎么保證數(shù)據(jù)的準(zhǔn)確性？

你們線上業(yè)務(wù)用消息中間件的時(shí)候，是否需要保證消息的順序性？

如果不需要保證消息順序，為什么不需要？假如我有一個(gè)場景要保證消息的順序，你們應(yīng)該如何保證？

下游消費(fèi)系統(tǒng)如果宕機(jī)了，導(dǎo)致幾百萬條消息在消息中間件里積壓，此時(shí)怎么處理？

你們線上是否遇到過消息積壓的生產(chǎn)故障？如果沒遇到過，你考慮一下如何應(yīng)對？

你們用的是RabbitMQ？那你說說RabbitMQ的底層架構(gòu)原理，邏輯架構(gòu)、物理架構(gòu)以及數(shù)據(jù)持久化機(jī)制？

你們RabbitMQ的最高峰QPS每秒是多少？線上如何部署的，部署了多少臺機(jī)器，機(jī)器的配置如何？

你們用的是Kafka？那你說說Kafka的底層架構(gòu)原理，磁盤上數(shù)據(jù)如何存儲的，整體分布式架構(gòu)是如何實(shí)現(xiàn)的？

再說說Kafka是如何保證數(shù)據(jù)的高容錯(cuò)性的？零拷貝等技術(shù)是如何運(yùn)用的？高吞吐量下如何優(yōu)化生產(chǎn)者和消費(fèi)者的性能？

你們用的是RocketMQ？RocketMQ很大的一個(gè)特點(diǎn)是對分布式事務(wù)的支持，你說說他在分布式事務(wù)支持這塊機(jī)制的底層原理？

如果讓你來動手實(shí)現(xiàn)一個(gè)分布式消息中間件，整體架構(gòu)你會如何設(shè)計(jì)實(shí)現(xiàn)？

為什么使用消息隊(duì)列？

image.png

消息隊(duì)列的缺點(diǎn)

201931713116

消息隊(duì)列如何選型

2019317131255

RabbitMQ

RabbitMQ

阿里云MNS

• MNS產(chǎn)品介紹

阿里云ONS / RocketMQ

• ONS產(chǎn)品介紹
• ONS開源社區(qū)對應(yīng)產(chǎn)品——RocketMQ

Kafka

詳見下文分析重點(diǎn)分析。

產(chǎn)品總結(jié)

事務(wù)支持方面，ONS/RocketMQ較為優(yōu)秀，但是不支持消息批量操作, 不保證消息至少被消費(fèi)一次.

Kafka提供完全分布式架構(gòu), 并有replica機(jī)制, 擁有較高的可用性和可靠性, 理論上支持消息無限堆積, 支持批量操作, 消費(fèi)者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次. 但是官方提供的運(yùn)維工具不友好，開源社區(qū)的運(yùn)維工具支持的版本一般落后于最新版本的Kafka.

目前使用的MNS服務(wù)，擁有HTTP REST API, 使用簡單, 數(shù)據(jù)可靠性高, 但是不保證消息有序，不能回溯數(shù)據(jù).

RabbitMQ為重量級消息系統(tǒng)， 支持多協(xié)議(很多協(xié)議是目前業(yè)務(wù)用不到的), 但是不支持回溯數(shù)據(jù), master掛掉之后， 需要手動從slave恢復(fù), 可用性略遜一籌.

如何保證消息隊(duì)列的可用性

以rcoketMQ為例，他的集群就有

• 多master 模式
• 多master多slave異步復(fù)制模式

• 多 master多slave同步雙寫模式

  
  
  多master多slave模式部署架構(gòu)圖

第一眼看到這個(gè)圖，就覺得和kafka好像，只是NameServer集群，在kafka中是用zookeeper代替，都是用來保存和發(fā)現(xiàn)master和slave用的。

通信過程如下:

Producer 與 NameServer集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)選擇）建立長連接，定期從 NameServer 獲取 Topic 路由信息，并向提供 Topic 服務(wù)的 Broker Master 建立長連接，且定時(shí)向 Broker 發(fā)送心跳。

Producer 只能將消息發(fā)送到 Broker master，但是 Consumer 則不一樣，它同時(shí)和提供 Topic 服務(wù)的 Master 和 Slave建立長連接，既可以從 Broker Master 訂閱消息，也可以從 Broker Slave 訂閱消息。

那么kafka呢？
為了對比說明直接上kafka的拓補(bǔ)架構(gòu)圖

image.png

如上圖所示，一個(gè)典型的Kafka集群中包含若干Producer（可以是web前端產(chǎn)生的Page View，或者是服務(wù)器日志，系統(tǒng)CPU、Memory等），若干broker（Kafka支持水平擴(kuò)展，一般broker數(shù)量越多，集群吞吐率越高），若干Consumer Group，以及一個(gè)Zookeeper集群。Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發(fā)生變化時(shí)進(jìn)行rebalance。Producer使用push模式將消息發(fā)布到broker，Consumer使用pull模式從broker訂閱并消費(fèi)消息。

如何保證消息不被重復(fù)消費(fèi)(冪等性)

最騷的一個(gè)操作，消費(fèi)者業(yè)務(wù)自己去保證冪等性。

換一個(gè)說法，如何保證消息隊(duì)列的冪等性?

另外說一點(diǎn)，冪等性的保證需要在一次請求中所有鏈路都是冪等的，再能最終保證這次請求的冪等，比如前段按鈕點(diǎn)擊兩次，后端認(rèn)為都是這是兩次不同的請求，當(dāng)然處理成兩次請求，所以說一個(gè)請求的冪等性，需要全局的冪等才能保證。

其實(shí)無論是哪種消息隊(duì)列，造成重復(fù)消費(fèi)原因其實(shí)都是類似的。正常情況下，消費(fèi)者在消費(fèi)消息時(shí)候，消費(fèi)完畢后，會發(fā)送一個(gè)確認(rèn)信息給消息隊(duì)列，消息隊(duì)列就知道該消息被消費(fèi)了，就會將該消息從消息隊(duì)列中刪除。只是不同的消息隊(duì)列發(fā)送的確認(rèn)信息形式不同。

例如RabbitMQ是發(fā)送一個(gè)ACK確認(rèn)消息，RocketMQ是返回一個(gè)CONSUME_SUCCESS成功標(biāo)志，kafka實(shí)際上有個(gè)offset的概念，簡單說一下(后續(xù)詳細(xì)解釋),就是每一個(gè)消息都有一個(gè)offset，kafka消費(fèi)過消息后，需要提交offset，讓消息隊(duì)列知道自己已經(jīng)消費(fèi)過了。

那造成重復(fù)消費(fèi)的原因?，就是因?yàn)榫W(wǎng)絡(luò)傳輸?shù)鹊裙收希_認(rèn)信息沒有傳送到消息隊(duì)列，導(dǎo)致消息隊(duì)列不知道自己已經(jīng)消費(fèi)過該消息了，再次將該消息分發(fā)給其他的消費(fèi)者。

如何解決?這個(gè)問題針對業(yè)務(wù)場景來答分以下幾點(diǎn)

• (1)你拿到這個(gè)消息做數(shù)據(jù)庫的insert操作。那就容易了，給這個(gè)消息做一個(gè)唯一主鍵，那么就算出現(xiàn)重復(fù)消費(fèi)的情況，就會導(dǎo)致主鍵沖突，避免數(shù)據(jù)庫出現(xiàn)臟數(shù)據(jù)。

• (2)你拿到這個(gè)消息做redis的set的操作，那就容易了，不用解決，因?yàn)槟銦o論set幾次結(jié)果都是一樣的，set操作本來就算冪等操作。

• (3)如果上面兩種情況還不行，上大招。準(zhǔn)備一個(gè)第三方介質(zhì),來做消費(fèi)記錄。以redis為例，給消息分配一個(gè)全局id，只要消費(fèi)過該消息，將<id,message>以K-V形式寫入redis。那消費(fèi)者開始消費(fèi)前，先去redis中查詢有沒消費(fèi)記錄即可。還有一個(gè)方法，采用 setnx 的方案。

如何保證消費(fèi)的可靠傳輸

其實(shí)這個(gè)可靠性傳輸，每種MQ都要從三個(gè)角度來分析:生產(chǎn)者弄丟數(shù)據(jù)、消息隊(duì)列弄丟數(shù)據(jù)、消費(fèi)者弄丟數(shù)據(jù)。

生產(chǎn)者丟數(shù)據(jù)

從生產(chǎn)者弄丟數(shù)據(jù)這個(gè)角度來看，RabbitMQ提供transaction和confirm模式來確保生產(chǎn)者不丟消息。
transaction(事物機(jī)制)機(jī)制就是說，發(fā)送消息前，開啟事物(channel.txSelect())，然后發(fā)送消息，如果發(fā)送過程中出現(xiàn)什么異常，事物就會回滾(channel.txRollback())，如果發(fā)送成功則提交事物(channel.txCommit())。然而缺點(diǎn)就是吞吐量下降了。

生產(chǎn)上用confirm模式的居多。一旦channel進(jìn)入confirm模式，所有在該信道上面發(fā)布的消息都將會被指派一個(gè)唯一的ID(從1開始)，一旦消息被投遞到所有匹配的隊(duì)列之后，rabbitMQ就會發(fā)送一個(gè)Ack給生產(chǎn)者(包含消息的唯一ID)，這就使得生產(chǎn)者知道消息已經(jīng)正確到達(dá)目的隊(duì)列了.如果rabiitMQ沒能處理該消息，則會發(fā)送一個(gè)Nack消息給你，你可以進(jìn)行重試操作。

簡單來講 confirm模式就是生產(chǎn)者發(fā)送請求，到了消息隊(duì)列，消息隊(duì)列會回復(fù)一個(gè)消息收到的應(yīng)答，如果沒收到，生產(chǎn)者開始重試。

消息隊(duì)列丟數(shù)據(jù)

處理消息隊(duì)列丟數(shù)據(jù)的情況，一般是開啟持久化磁盤的配置。這個(gè)持久化配置可以和confirm機(jī)制配合使用，你可以在消息持久化磁盤后，再給生產(chǎn)者發(fā)送一個(gè)Ack信號。這樣，如果消息持久化磁盤之前，rabbitMQ陣亡了，那么生產(chǎn)者收不到Ack信號，生產(chǎn)者會自動重發(fā)。

消費(fèi)者丟數(shù)據(jù)

消費(fèi)者丟數(shù)據(jù)一般是因?yàn)椴捎昧俗詣哟_認(rèn)消息模式。這種模式下，消費(fèi)者會自動確認(rèn)收到信息。這時(shí)rahbitMQ會立即將消息刪除，這種情況下如果消費(fèi)者出現(xiàn)異常而沒能處理該消息(但是消息隊(duì)列那邊已經(jīng)認(rèn)為消息被消費(fèi)了)，就會丟失該消息。

至于解決方案，采用手動確認(rèn)消息即可。

kafka為例

kafka Replication的數(shù)據(jù)流向圖

Producer在發(fā)布消息到某個(gè)Partition時(shí)，先通過ZooKeeper找到該P(yáng)artition的Leader，然后無論該Topic的Replication Factor為多少（也即該P(yáng)artition有多少個(gè)Replica），Producer只將該消息發(fā)送到該P(yáng)artition的Leader。Leader會將該消息寫入其本地Log。每個(gè)Follower都從Leader中pull數(shù)據(jù)。

結(jié)論

生產(chǎn)者丟數(shù)據(jù)

在kafka生產(chǎn)中，基本都有一個(gè)leader和多個(gè)follwer。follwer會去同步leader的信息。因此，為了避免生產(chǎn)者丟數(shù)據(jù)，做如下兩點(diǎn)配置

1. 第一個(gè)配置要在producer端設(shè)置acks=all。這個(gè)配置保證了，follwer同步完成后，才認(rèn)為消息發(fā)送成功。

2. 在producer端設(shè)置retries=MAX，一旦寫入失敗，這無限重試

消息隊(duì)列丟數(shù)據(jù)

針對消息隊(duì)列丟數(shù)據(jù)的情況，無外乎就是，數(shù)據(jù)還沒同步，leader就掛了，這時(shí)zookpeer會將其他的follwer切換為leader,那數(shù)據(jù)就丟失了。針對這種情況，應(yīng)該做兩個(gè)配置。

1. replication.factor參數(shù)，這個(gè)值必須大于1，即要求每個(gè)partition必須有至少2個(gè)副本。

2. min.insync.replicas參數(shù)，這個(gè)值必須大于1，這個(gè)是要求一個(gè)leader至少感知到有至少一個(gè)follower還跟自己保持聯(lián)系這兩個(gè)配置加上上面生產(chǎn)者的配置聯(lián)合起來用，基本可確保kafka不丟數(shù)據(jù)

消費(fèi)者丟數(shù)據(jù)

這種情況一般是自動提交了offset，然后你處理程序過程中掛了。kafka以為你處理好了。再強(qiáng)調(diào)一次offset是干嘛的。

offset：指的是kafka的topic中的每個(gè)消費(fèi)組消費(fèi)的下標(biāo)。簡單的來說就是一條消息對應(yīng)一個(gè)offset下標(biāo)，每次消費(fèi)數(shù)據(jù)的時(shí)候如果提交offset，那么下次消費(fèi)就會從提交的offset加一那里開始消費(fèi)。

比如一個(gè)topic中有100條數(shù)據(jù)，我消費(fèi)了50條并且提交了，那么此時(shí)的kafka服務(wù)端記錄提交的offset就是49(offset從0開始)，那么下次消費(fèi)的時(shí)候offset就從50開始消費(fèi)。

如何保證消息的順序性

針對這個(gè)問題，通過某種算法，將需要保持先后順序的消息放到同一個(gè)消息隊(duì)列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一個(gè)消費(fèi)者去消費(fèi)該隊(duì)列。

有的人會問:那如果為了吞吐量，有多個(gè)消費(fèi)者去消費(fèi)怎么辦？

簡單來說消息的時(shí)序性也可以通過錯(cuò)誤重試來解決。

比如我們有一個(gè)微博的操作，發(fā)微博、寫評論、刪除微博，這三個(gè)異步操作。如果是這樣一個(gè)業(yè)務(wù)場景，那只要重試就行。比如你一個(gè)消費(fèi)者先執(zhí)行了寫評論的操作，但是這時(shí)候，微博都還沒發(fā)，寫評論一定是失敗的，等一段時(shí)間。等另一個(gè)消費(fèi)者，先執(zhí)行寫評論的操作后，再執(zhí)行，就可以成功。

總之，針對這個(gè)問題，我的觀點(diǎn)是保證入隊(duì)有序就行，出隊(duì)以后的順序交給消費(fèi)者自己去保證，沒有固定套路。

Kafka

名詞解釋

1. producer：消息生產(chǎn)者，發(fā)布消息到 kafka 集群的終端或服務(wù)。
2. broker：kafka 集群中包含的服務(wù)器。
3. topic：每條發(fā)布到 kafka 集群的消息屬于的類別，即 kafka 是面向 topic 的。
4. partition： 是物理上的概念，每個(gè) topic 包含一個(gè)或多個(gè) partition。kafka 分配的單位是 partition。
5. consumer：從 kafka 集群中消費(fèi)消息的終端或服務(wù)。
6. Consumer group：high-level consumer API 中，每個(gè) consumer 都屬于一個(gè) consumer group，每條消息只能被 consumer group 中的一個(gè) Consumer 消費(fèi)，但可以被多個(gè) consumer group 消費(fèi)。
7. replica：partition 的副本，保障 partition 的高可用。
8. leader：replica 中的一個(gè)角色， producer 和 consumer 只跟 leader 交互。
9. follower：replica 中的一個(gè)角色，從 leader 中復(fù)制數(shù)據(jù)。
10. controller：kafka 集群中的其中一個(gè)服務(wù)器，用來進(jìn)行 leader election 以及 各種 failover。
11. zookeeper：kafka 通過 zookeeper 來存儲集群的 meta 信息。

partition

為了做到水平擴(kuò)展，一個(gè)topic實(shí)際是由多個(gè)partition組成的，遇到瓶頸時(shí)，可以通過增加partition的數(shù)量來進(jìn)行橫向擴(kuò)容。
單個(gè)parition內(nèi)是保證消息有序。

1. 一個(gè)Topic的Partition數(shù)量大于等于Broker的數(shù)量，可以提高吞吐率。
2. 同一個(gè)Partition的Replica盡量分散到不同的機(jī)器，高可用。

消費(fèi)組

訂閱topic是以一個(gè)消費(fèi)組來訂閱的，一個(gè)消費(fèi)組里面可以有多個(gè)消費(fèi)者。

同一個(gè)消費(fèi)組中的兩個(gè)消費(fèi)者，只能消費(fèi)一個(gè)partition。

換句話來說，就是一個(gè)partition，只能被消費(fèi)組里的一個(gè)消費(fèi)者消費(fèi)，但是可以同時(shí)被多個(gè)消費(fèi)組消費(fèi)。

如果消費(fèi)組內(nèi)的消費(fèi)者如果比partition多的話，那么就會有個(gè)別消費(fèi)者一直空閑。

在 zk 中存了什么

2019317192730

Kafka的API

kafka api 提供了很多功能比如

生產(chǎn)者能指定 topic 和 Partition 來投遞消息，并且還有延遲消息，事務(wù)消息等等，詳見下面的 api 文檔
http://kafka.apache.org/documentation.html#api

這個(gè)是 api 的中文文檔
http://orchome.com/66

Kakfa Broker Leader的選舉

Kakfa Broker集群受Zookeeper管理。
這里先說下
關(guān)于partition的分配，還有l(wèi)eader的選舉，總得有個(gè)執(zhí)行者。在kafka中，這個(gè)執(zhí)行者就叫controller。kafka使用zk在broker中選出一個(gè)controller，用于partition分配和leader選舉。

所有的Kafka Broker節(jié)點(diǎn)一起去Zookeeper上注冊一個(gè)臨時(shí)節(jié)點(diǎn)，并且只有一個(gè)Kafka Broker會注冊成功，其他的都會失敗，所以這個(gè)成功在Zookeeper上注冊臨時(shí)節(jié)點(diǎn)的這個(gè)Kafka Broker會成為Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。（這個(gè)過程叫Controller在ZooKeeper注冊Watch）。

這個(gè)Controller會監(jiān)聽其他的Kafka Broker的所有信息，如果這個(gè)kafka broker controller宕機(jī)了，在zookeeper上面的那個(gè)臨時(shí)節(jié)點(diǎn)就會消失，此時(shí)所有的kafka broker又會一起去Zookeeper上注冊一個(gè)臨時(shí)節(jié)點(diǎn)。

kafka常見的一些問題

Kafka的用途有哪些？使用場景如何？
Kafka中的ISR、AR又代表什么？ISR的伸縮又指什么
Kafka中的HW、LEO、LSO、LW等分別代表什么？
Kafka中是怎么體現(xiàn)消息順序性的？
Kafka中的分區(qū)器、序列化器、攔截器是否了解？它們之間的處理順序是什么？
Kafka生產(chǎn)者客戶端的整體結(jié)構(gòu)是什么樣子的？
Kafka生產(chǎn)者客戶端中使用了幾個(gè)線程來處理？分別是什么？
Kafka的舊版Scala的消費(fèi)者客戶端的設(shè)計(jì)有什么缺陷？
“消費(fèi)組中的消費(fèi)者個(gè)數(shù)如果超過topic的分區(qū)，那么就會有消費(fèi)者消費(fèi)不到數(shù)據(jù)”這句話是否正確？如果不正確，那么有沒有什么hack的手段？
消費(fèi)者提交消費(fèi)位移時(shí)提交的是當(dāng)前消費(fèi)到的最新消息的offset還是offset+1?
有哪些情形會造成重復(fù)消費(fèi)？
那些情景下會造成消息漏消費(fèi)？
KafkaConsumer是非線程安全的，那么怎么樣實(shí)現(xiàn)多線程消費(fèi)？
簡述消費(fèi)者與消費(fèi)組之間的關(guān)系
當(dāng)你使用kafka-topics.sh創(chuàng)建（刪除）了一個(gè)topic之后，Kafka背后會執(zhí)行什么邏輯？
topic的分區(qū)數(shù)可不可以增加？如果可以怎么增加？如果不可以，那又是為什么？
topic的分區(qū)數(shù)可不可以減少？如果可以怎么減少？如果不可以，那又是為什么？
創(chuàng)建topic時(shí)如何選擇合適的分區(qū)數(shù)？
Kafka目前有那些內(nèi)部topic，它們都有什么特征？各自的作用又是什么？
優(yōu)先副本是什么？它有什么特殊的作用？
Kafka有哪幾處地方有分區(qū)分配的概念？簡述大致的過程及原理
簡述Kafka的日志目錄結(jié)構(gòu)
Kafka中有那些索引文件？
如果我指定了一個(gè)offset，Kafka怎么查找到對應(yīng)的消息？
如果我指定了一個(gè)timestamp，Kafka怎么查找到對應(yīng)的消息？
聊一聊你對Kafka的Log Retention的理解
聊一聊你對Kafka的Log Compaction的理解
聊一聊你對Kafka底層存儲的理解（頁緩存、內(nèi)核層、塊層、設(shè)備層）
聊一聊Kafka的延時(shí)操作的原理
聊一聊Kafka控制器的作用
消費(fèi)再均衡的原理是什么？（提示：消費(fèi)者協(xié)調(diào)器和消費(fèi)組協(xié)調(diào)器）
Kafka中的冪等是怎么實(shí)現(xiàn)的
Kafka中的事務(wù)是怎么實(shí)現(xiàn)的（這題我去面試6家被問4次，照著答案念也要念十幾分鐘，面試官簡直湊不要臉。實(shí)在記不住的話...只要簡歷上不寫精通Kafka一般不會問到，我簡歷上寫的是“熟悉Kafka，了解RabbitMQ....”）
Kafka中有那些地方需要選舉？這些地方的選舉策略又有哪些？
失效副本是指什么？有那些應(yīng)對措施？
多副本下，各個(gè)副本中的HW和LEO的演變過程
為什么Kafka不支持讀寫分離？
Kafka在可靠性方面做了哪些改進(jìn)？（HW, LeaderEpoch）
Kafka中怎么實(shí)現(xiàn)死信隊(duì)列和重試隊(duì)列？
Kafka中的延遲隊(duì)列怎么實(shí)現(xiàn)（這題被問的比事務(wù)那題還要多！！！聽說你會Kafka，那你說說延遲隊(duì)列怎么實(shí)現(xiàn)？）
Kafka中怎么做消息審計(jì)？
Kafka中怎么做消息軌跡？
Kafka中有那些配置參數(shù)比較有意思？聊一聊你的看法
Kafka中有那些命名比較有意思？聊一聊你的看法
Kafka有哪些指標(biāo)需要著重關(guān)注？
怎么計(jì)算Lag？(注意read_uncommitted和read_committed狀態(tài)下的不同)
Kafka的那些設(shè)計(jì)讓它有如此高的性能？
Kafka有什么優(yōu)缺點(diǎn)？
還用過什么同質(zhì)類的其它產(chǎn)品，與Kafka相比有什么優(yōu)缺點(diǎn)？
為什么選擇Kafka?
在使用Kafka的過程中遇到過什么困難？怎么解決的？
怎么樣才能確保Kafka極大程度上的可靠性？
聊一聊你對Kafka生態(tài)的理解

消息傳輸一致性語義

Kafka提供3種消息傳輸一致性語義：最多1次，最少1次，恰好1次。

最少1次(at most once)：可能會重傳數(shù)據(jù)，有可能出現(xiàn)數(shù)據(jù)被重復(fù)處理的情況;

最多1次(at least once)：可能會出現(xiàn)數(shù)據(jù)丟失情況;

恰好1次(Exactly once)：并不是指真正只傳輸1次，只不過有一個(gè)機(jī)制。確保不會出現(xiàn)“數(shù)據(jù)被重復(fù)處理”和“數(shù)據(jù)丟失”的情況。

kafka 為什么這么快

1. 生產(chǎn)者寫入：頁緩存技術(shù) + 磁盤順序?qū)?/li>

操作系統(tǒng)本身有一層緩存，叫做page cache，是在內(nèi)存里的緩存，我們也可以稱之為os cache，意思就是操作系統(tǒng)自己管理的緩存。
每新寫一條消息，kafka就是在對應(yīng)的文件append寫，所以性能非常高。

2. 消費(fèi)者讀?。毫?copy 技術(shù)

https://mp.weixin.qq.com/s/sCRC5h0uw2DWD2MixI6pZw

怎么保證發(fā)送消息不丟失(多副本同步機(jī)制)

我覺得的靠的是這兩個(gè)參數(shù)

#acks
props.put("acks", "all")
//0：不進(jìn)行消息接收確認(rèn)，即Client端發(fā)送完成后不會等待Broker的確認(rèn)
//1：由Leader確認(rèn)，Leader接收到消息后會立即返回確認(rèn)信息
//all：集群完整確認(rèn)，Leader會等待所有in-sync的follower節(jié)點(diǎn)都確認(rèn)收到消息后，再返回確認(rèn)信息

這點(diǎn)也就保證了所有節(jié)點(diǎn)都都有一個(gè)副本，及時(shí)leader 宕機(jī)后主節(jié)點(diǎn)也不會
#request.required.acks
# 0：不保證消息的到達(dá)確認(rèn)，只管發(fā)送，低延遲但是會出現(xiàn)消息的丟失，在某個(gè)server失敗的情況下，有點(diǎn)像TCP
# 1：發(fā)送消息，并會等待leader 收到確認(rèn)后，一定的可靠性
# -1：發(fā)送消息，等待leader收到確認(rèn)，并進(jìn)行復(fù)制操作后，才返回，最高的可靠性
并且在落后太多會把落后的節(jié)點(diǎn)剔除。

kafka 參考文獻(xiàn)

這篇主要從生產(chǎn)和消費(fèi)的角度詳細(xì)給出的過程
https://www.cnblogs.com/cyfonly/p/5954614.html