亚洲AV成人精品一区二区三区,欧美草比视频,草久在线,精品成人人妻AV一区二区,《抗日性艳史电影》,在办公室伦流澡到高潮在线观看,一级片手机在线观看,老鸭窝永久地址

最近工作中呢，頻頻用到消息中心，包括異步轉(zhuǎn)同步的功能，分布式收集日志信息等功能，在面試中也常會(huì)問到候選人關(guān)于消息中心的知識(shí)點(diǎn)，但大多數(shù)程序員，尤其是工作兩三年的，雖然平時(shí)工作中都有用到消息中心，但都總是不能夠說明白其中的原理，于是覺得有必要把消息中心作為一個(gè)篇章，專門進(jìn)行總結(jié)梳理一番~

看的時(shí)候，建議大家不妨先看看問題，自己先嘗試回答一下，再看答案?？纯醋约赫莆盏萌绾瘟?/span>

那準(zhǔn)備好了的話，我們就要開始啦啊~

01.為什么要使用消息中心？

消息中心，有以下幾大作用：

消息通訊：可以作為基本的消息通訊，比如聊天室等工具的使用
異步處理 : 將一些實(shí)時(shí)性要求不是很強(qiáng)的業(yè)務(wù)異步處理，起到緩沖的作用，一定程度上也會(huì)避免因?yàn)橛行┫M(fèi)者處理的太慢或者網(wǎng)絡(luò)問題導(dǎo)致的通訊等待太久，因而導(dǎo)致的單個(gè)服務(wù)崩潰，甚至產(chǎn)生多個(gè)服務(wù)間的雪崩效應(yīng)；
應(yīng)用解耦 : ? 消息隊(duì)列將消息生產(chǎn)者和消費(fèi)者分離開來，可以實(shí)現(xiàn)應(yīng)用解耦
流量削峰:? ?可以通過在應(yīng)用前端采用消息隊(duì)列來接收請(qǐng)求，可以達(dá)到削峰的目的：請(qǐng)求超過隊(duì)列長度直接不處理，重定向至錯(cuò)誤頁面。類似于網(wǎng)關(guān)限流的作用
冗余存儲(chǔ)：消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化，直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險(xiǎn)

02.聊聊Kafka的特點(diǎn)

可靠性：Kafka是分布式的、可分區(qū)的、數(shù)據(jù)可備份的、高度容錯(cuò)的
可擴(kuò)展性：在無需停機(jī)的情況下實(shí)現(xiàn)輕松擴(kuò)展
消息持久性：Kafka支持將消息持久化到本地磁盤
高性能：Kafka的消息發(fā)布訂閱具有很高的吞吐量，即便存儲(chǔ)了TB級(jí)的消息，它依然能保持穩(wěn)定的性能

03.你會(huì)在哪些場(chǎng)景選擇使用Kafka？

1）日志信息收集記錄

我個(gè)人接觸的項(xiàng)目中，Kafka使用最多的場(chǎng)景，就是用它與FileBeats和ELK組成典型的日志收集、分析處理以及展示的框架

該圖為FileBeats+Kafka+ELK集群架構(gòu)。Kafka在框架中，作為消息緩沖隊(duì)列

FileBeats先將數(shù)據(jù)傳遞給消息隊(duì)列，Logstash server（二級(jí)Logstash）拉取消息隊(duì)列中的數(shù)據(jù)，進(jìn)行過濾和分析，然后將數(shù)據(jù)傳遞給Elasticsearch進(jìn)行存儲(chǔ)，最后，再由Kibana將日志和數(shù)據(jù)呈現(xiàn)給用戶

由于引入了Kafka緩沖機(jī)制，即使遠(yuǎn)端Logstash server因故障停止運(yùn)行，數(shù)據(jù)也不會(huì)丟失，可靠性得到了大大的提升

2）用戶軌跡跟蹤：kafka經(jīng)常被用來記錄web用戶或者app用戶的各種活動(dòng)，如瀏覽網(wǎng)頁、搜索、點(diǎn)擊等操作，這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到kafka的topic中，然后消費(fèi)者通過訂閱這些topic來做實(shí)時(shí)的監(jiān)控分析，當(dāng)然也可以保存到數(shù)據(jù)庫

3）運(yùn)營指標(biāo)：kafka也經(jīng)常用來記錄運(yùn)營監(jiān)控?cái)?shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)，生產(chǎn)各種操作的集中反饋，比如報(bào)警和報(bào)告

4）流式處理：比如spark streaming和storm

04.Kafka使用哪種方式消費(fèi)消息，pull還是push？

Kafka的消費(fèi)者使用pull（拉）的方式將消息從broker中拉下來

1 這樣做的好處是：

1）Kafka可以根據(jù)consumer的消費(fèi)能力以適當(dāng)?shù)乃俾氏M(fèi)消息

2）消費(fèi)者可以控制自己的消費(fèi)方式：可以使用批量消費(fèi)，也可以選擇逐條消費(fèi)

3）消費(fèi)者還可以選擇不同的提交方式來實(shí)現(xiàn)不同的傳輸語義，要是使用了push的方式，就沒有這些優(yōu)點(diǎn)了

2 缺點(diǎn)是：

會(huì)出現(xiàn)一種情況：如果Kafka沒有數(shù)據(jù)，消費(fèi)者會(huì)專門有個(gè)線程去等待數(shù)據(jù)，可能會(huì)陷入循環(huán)等待中

3 Kafka如何避免這一缺點(diǎn)：

我們可以通過在拉請(qǐng)求中設(shè)置參數(shù)，允許消費(fèi)者請(qǐng)求在等待數(shù)據(jù)到達(dá)的“長輪詢”中進(jìn)行阻塞（并且可選地等待到給定的字節(jié)數(shù)，以確保大的傳輸大小）來避免這一問題

4 關(guān)于push的方式的話，它的優(yōu)點(diǎn)是：

1）相對(duì)于pull的方式來說，它不需要專門有一個(gè)消息去等待，而可能造成線程循環(huán)等待的問題

2）它的缺點(diǎn)是：

push（推）模式一般是會(huì)以同樣的速率將消息推給消費(fèi)者，很難適應(yīng)消費(fèi)速率不同的消費(fèi)者，這樣很容易造成有些消費(fèi)能力比較低的consumer來不及處理消息，導(dǎo)致出現(xiàn)拒絕服務(wù)以及網(wǎng)絡(luò)擁塞的情況

05.Kafka與Zookeeper是什么關(guān)系？

Kafka的數(shù)據(jù)會(huì)存儲(chǔ)在zookeeper上。包括broker和消費(fèi)者consumer的信息

其中,

broker信息：包含各個(gè)broker的服務(wù)器信息、Topic信息

消費(fèi)者信息：主要存儲(chǔ)每個(gè)消費(fèi)者消費(fèi)的topic的offset的值

06.聊聊Kafka的架構(gòu)

總的來說，Kafka是分為三個(gè)角色：Producer、Kafka集群以及Consumer

生產(chǎn)者將消息發(fā)送到Kafka集群，然后消費(fèi)者再去Kafka集群進(jìn)行消息的消費(fèi)

稍微具體一點(diǎn)，就是下面這幅圖

1）圖中，除了包含前面說到的生產(chǎn)者Producer、Kafka集群以及消費(fèi)者Consumer三個(gè)角色之外，還包含了用于存儲(chǔ)信息的注冊(cè)中心-Zookeeper

2）生產(chǎn)者：很明顯，它是消息的生產(chǎn)者，用于發(fā)送消息的客戶端

3）消費(fèi)者：消息的消費(fèi)者，用于消費(fèi)消息的客戶端。

4）消費(fèi)者組：kafka的消費(fèi)者角色，還有消費(fèi)者組的概念，也就是說每個(gè)消費(fèi)者組中可以包含多個(gè)consumer。其中，Kafka規(guī)定，消費(fèi)者組中的消費(fèi)者不能同時(shí)消費(fèi)topic中的同一分區(qū)

比如說，圖中，消費(fèi)者組中包含Consumer A 和Consumer B兩個(gè)，對(duì)于有兩個(gè)分區(qū)的topic A,Consumer A消費(fèi)了partition0,這時(shí)Consumer B就不能消費(fèi)partition0的消息了，它只能消費(fèi)partition1中的消息

延伸出消息如何保證順序？

因?yàn)殛?duì)列的先進(jìn)先出的特點(diǎn)，保證了消息在發(fā)送的時(shí)候是有序的，而在同一個(gè)分區(qū)中，它是被一個(gè)消費(fèi)者所消費(fèi)的，那么它就也可以在一個(gè)分區(qū)中，保證消費(fèi)消息時(shí)的順序性。而在一個(gè)有兩個(gè)及兩個(gè)以上的topic內(nèi)的話，就不能保證消息的順序性了

因此，想要保證消息的順序性，只在新建topic時(shí)，指定一個(gè)分區(qū)即可

5）Kafka集群:消息存儲(chǔ)轉(zhuǎn)發(fā)的地方，一般是集群的方式存在，而每個(gè)集群節(jié)點(diǎn)稱為一個(gè)broker

6）Zookeeper:用于存儲(chǔ)broker信息和消費(fèi)者信息

7）broker:即Kafka集群的一臺(tái)機(jī)器，可包含多個(gè)Topic

8）Topic : 主題，可以理解為一個(gè)隊(duì)列

9）Partation:?隊(duì)列Topic的分區(qū)，一個(gè)Topic可以分為多個(gè)分區(qū)，用于高并發(fā)場(chǎng)景的負(fù)載功能；實(shí)際上Topic只是一個(gè)邏輯概念，真正存在的是分區(qū)

10）Offset:即隊(duì)列中當(dāng)前讀取消息的位置。順便說一下，kafka的存儲(chǔ)文件都是按照offset.kafka來命名，使用offset做名字，就方便查找。例如你想找位于2035的位置，只要找到2035.kafka的文件即可

07.Kafka的緩沖池滿了怎么辦？

無論消息是否被消費(fèi)，kafka都會(huì)保留所有消息。而當(dāng)消息的大小，大于設(shè)置的最大值log.retention.bytes（默認(rèn)為1073741824）的值，也就是說這個(gè)緩沖池滿了的時(shí)候，Kafka便會(huì)清除掉舊消息

那么它每次刪除多少消息呢？

topic的分區(qū)partitions，被分為一個(gè)個(gè)小segment，按照segment為單位進(jìn)行刪除(segment的大小也可以進(jìn)行配置，默認(rèn)log.segment.bytes = 1024 * 1024 * 1024)，由時(shí)間從遠(yuǎn)到近的順序進(jìn)行刪除

此外，Kafka還支持基于時(shí)間策略進(jìn)行刪除數(shù)據(jù)，過期時(shí)間默認(rèn)為：log.retention.hours=168

注意：因?yàn)镵afka讀取特定消息的時(shí)間復(fù)雜度為O(1)，即與文件大小無關(guān)，所以這里刪除過期文件與提高 Kafka 性能無關(guān)

08.數(shù)據(jù)傳輸?shù)氖聞?wù)有幾種？

有以下三種：

最多一次（<=1）：?消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸
最少一次(>=1)：消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸
精確的一次（Exactly once）(=1):?不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的

那么，每種傳輸，分別是怎樣實(shí)現(xiàn)的呢？

最多一次：consumer先讀消息，記錄offset，最后再處理消息

這樣，不可避免地存在一種可能：在記錄offset之后，還沒處理消息就出現(xiàn)故障了，新的consumer會(huì)繼續(xù)從這個(gè)offset處理，那么就會(huì)出現(xiàn)有些消息永遠(yuǎn)不會(huì)被處理。那么這種機(jī)制，就是消息最多被處理一次

最少一次：consumer可以先讀取消息，處理消息，最后記錄offset

當(dāng)然如果在記錄offset之前就crash了，新的consumer會(huì)重復(fù)的消費(fèi)一些消息。那么這種機(jī)制，就是消息最多被處理一次

精確一次：可以通過將提交分為兩個(gè)階段來解決：保存了offset后提交一次，消息處理成功之后再提交一次。當(dāng)然也可以直接將消息的offset和消息被處理后的結(jié)果保存在一起，這樣就能夠保證消息能夠被精確地消費(fèi)一次

09.Kafka在什么情況下會(huì)出現(xiàn)消息丟失？

以下幾個(gè)階段，都有可能會(huì)出現(xiàn)消息丟失的情況

1）消息發(fā)送的時(shí)候，如果發(fā)送出去以后，消息可能因?yàn)榫W(wǎng)絡(luò)問題并沒有發(fā)送成功

2）消息消費(fèi)的時(shí)候，消費(fèi)者在消費(fèi)消息的時(shí)候，若還未做處理的時(shí)候，服務(wù)掛了，那這個(gè)消息不就丟失了

3）分區(qū)中的leader所在的broker掛了之后

我們知道，Kafka的Topic中的分區(qū)Partition是leader與follower的主從機(jī)制，發(fā)送消息與消費(fèi)消息都直接面向leader分區(qū)，并不與follower交互，follower則會(huì)去leader中拉取消息，進(jìn)行消息的備份，這樣保證了一定的可靠性

但是，當(dāng)leader副本所在的broker突然掛掉，那么就要從follower中選舉一個(gè)leader，但leader的數(shù)據(jù)在掛掉之前并沒有同步到follower的這部分消息肯定就會(huì)丟失掉

10.Kafka的性能好在什么地方？

Kafka的性能好在兩個(gè)方面：順序?qū)?/span>和零拷貝

1）順序?qū)?br>

我們知道，操作系統(tǒng)每次從磁盤讀寫數(shù)據(jù)的時(shí)候，都需要找到數(shù)據(jù)在磁盤上的地址，再進(jìn)行讀寫。而如果是機(jī)械硬盤，尋址需要的時(shí)間往往會(huì)比較長

而一般來說，如果把數(shù)據(jù)存儲(chǔ)在內(nèi)存上面，少了尋址的過程，性能會(huì)好很多；但Kafka 的數(shù)據(jù)存儲(chǔ)在磁盤上面，依然性能很好，這是為什么呢？

這是因?yàn)椋琄afka采用的是順序?qū)?/span>，直接追加數(shù)據(jù)到末尾。實(shí)際上，磁盤順序?qū)懙男阅軜O高，在磁盤個(gè)數(shù)一定，轉(zhuǎn)數(shù)一定的情況下，基本和內(nèi)存速度一致

因此，磁盤的順序?qū)戇@一機(jī)制，極大地保證了Kafka本身的性能

2）零拷貝

比如：讀取文件，再用socket發(fā)送出去這一過程

buffer = File.read
Socket.send(buffer)

傳統(tǒng)方式實(shí)現(xiàn)：
先讀取、再發(fā)送，實(shí)際會(huì)經(jīng)過以下四次復(fù)制

1、將磁盤文件，讀取到操作系統(tǒng)內(nèi)核緩沖區(qū)Read Buffer
2、將內(nèi)核緩沖區(qū)的數(shù)據(jù)，復(fù)制到應(yīng)用程序緩沖區(qū)Application Buffer
3、將應(yīng)用程序緩沖區(qū)Application Buffer中的數(shù)據(jù)，復(fù)制到socket網(wǎng)絡(luò)發(fā)送緩沖區(qū)
4、將Socket buffer的數(shù)據(jù)，復(fù)制到網(wǎng)卡，由網(wǎng)卡進(jìn)行網(wǎng)絡(luò)傳輸

傳統(tǒng)方式，讀取磁盤文件并進(jìn)行網(wǎng)絡(luò)發(fā)送，經(jīng)過的四次數(shù)據(jù)copy是非常繁瑣的

重新思考傳統(tǒng)IO方式，會(huì)注意到在讀取磁盤文件后，不需要做其他處理，直接用網(wǎng)絡(luò)發(fā)送出去的這種場(chǎng)景下，第二次和第三次數(shù)據(jù)的復(fù)制過程，不僅沒有任何幫助，反而帶來了巨大的開銷。那么這里使用了零拷貝，也就是說，直接由內(nèi)核緩沖區(qū)Read Buffer將數(shù)據(jù)復(fù)制到網(wǎng)卡，省去第二步和第三步的復(fù)制。

這樣必定會(huì)大大減少讀取的開銷，使得Kafka讀取消息的性能有一個(gè)質(zhì)的提升

三總結(jié)

總而言之

本次文章通過10個(gè)常見的Kafka經(jīng)典面試題，帶大家再次重新學(xué)習(xí)了一次Kafka，相信大家能夠掌握得更深入一些了。

想想自己當(dāng)年在畢業(yè)第一年，實(shí)際上就已經(jīng)開始使用Kafka了，但是當(dāng)時(shí)就只知道它是個(gè)消息中心，對(duì)于它的特點(diǎn)啊，原理啊一無所知；第二年，因?yàn)橐鲂马?xiàng)目，有機(jī)會(huì)了解了一下，大概知道了它的框架，一些基本概念，但當(dāng)時(shí)的學(xué)習(xí)，也還只是照本宣科，網(wǎng)上說多少是可以得到多少，但很多東西根本沒法消化，記了很多筆記也總是沒法給別人講得特別清楚；直到現(xiàn)在，有了一定的學(xué)習(xí)和實(shí)戰(zhàn)經(jīng)驗(yàn)，再去看它，你會(huì)發(fā)現(xiàn)似乎一切都變得簡單，你的腦子里很容易就出現(xiàn)了它的架構(gòu)全局，它的一些特點(diǎn)，對(duì)于它的一些設(shè)計(jì)思路表示親切與贊賞。而且很多東西，在看的時(shí)候，你會(huì)覺得更輕松，也會(huì)有一些自己的理解，并且基本不用做太多的筆記，便可以很快理解它的原理，因?yàn)檫@次是真正地學(xué)會(huì)了

所以，每個(gè)階段都有每個(gè)階段該做的事，可能正因?yàn)橹暗奶铠喪降貙W(xué)習(xí)基礎(chǔ)，才會(huì)有今天的快速理解的效果。不斷學(xué)習(xí)才是真理，它會(huì)讓你不斷發(fā)現(xiàn)驚喜，包括對(duì)外界的，也包括對(duì)你自己的

點(diǎn)個(gè)在看支持我吧，轉(zhuǎn)發(fā)就更好了

Kafka經(jīng)典面試題，你都會(huì)嗎？

由于引入了Kafka緩沖機(jī)制，即使遠(yuǎn)端Logstash server因故障停止運(yùn)行，數(shù)據(jù)也不會(huì)丟失，可靠性得到了大大的提升

Kafka經(jīng)典面試題，你都會(huì)嗎？

由于引入了Kafka緩沖機(jī)制，即使遠(yuǎn)端Logstash server因故障停止運(yùn)行，數(shù)據(jù)也不會(huì)丟失，可靠性得到了大大的提升