Apache Kafka 基礎(chǔ)介紹
介紹完RocketMQ潜支，就不得不介紹一下kafka俯萌，RocketMQ就是照著kafka寫的java版本，在消息中間件中厕氨，kafka性能名列前茅坝辫。
官方文檔：
http://kafka.apache.org/intro.html
Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)篷就，使用Scala編寫。
對于熟悉JMS（Java Message Service）規(guī)范的同學(xué)來說阀溶，消息系統(tǒng)已經(jīng)不是什么新概念了(例如ActiveMQ腻脏，RabbitMQ等)。
Kafka擁有作為一個消息系統(tǒng)應(yīng)該具備的功能银锻，但是確有著獨特的設(shè)計永品。
可以這樣來說，Kafka借鑒了JMS規(guī)范的思想击纬，但是確并沒有完全遵循JMS規(guī)范鼎姐。
kafka是一個分布式的，分區(qū)的消息(官方稱之為commit log)服務(wù)。它提供一個消息系統(tǒng)應(yīng)該具備的功能炕桨，但是確有著獨特的設(shè)計饭尝。
首先，讓我們來看一下基礎(chǔ)的消息(Message)相關(guān)術(shù)語：
| 名詞 | 介紹 |
|---|---|
| Topic | Kafka按照Topic分類來維護消息 |
| Producer | 我們將發(fā)布(publish)消息到Topic的進程稱之為生產(chǎn)者(producer) |
| Consumer | 我們將訂閱(subscribe)Topic并且處理Topic中消息的進程稱之為消費者(consumer) |
| Broker | Kafka以集群的方式運行献宫，集群中的每一臺服務(wù)器稱之為一個代理(broker)钥平。 |
因此，從一個較高的層面上來看姊途，producers通過網(wǎng)絡(luò)發(fā)送消息到Kafka集群涉瘾，然后consumers來進行消費，如下圖：
服務(wù)端(brokers)和客戶端(producer捷兰、consumer)之間通信通過TCP協(xié)議來完成立叛。官方為Kafka提供了一個Java客戶端，但是也可以使用其他語言編寫的客戶端贡茅。
Topic和Log
讓我們首先深入理解Kafka提出一個高層次的抽象概念-Topic秘蛇。
可以理解Topic是一個類別的名稱，所有的message發(fā)送到Topic下面顶考。對于每一個Topic赁还，kafka集群按照如下方式維護一個分區(qū)(Partition,可以就理解為一個隊列Queue)日志文件:
partition是一個有序的message序列，這些message按順序添加到一個叫做commit log的文件中村怪。每個partition中的消息都有一個唯一的編號秽浇，稱之為offset，用來唯一標(biāo)示某個分區(qū)中的message甚负。
提示：每個partition柬焕，都對應(yīng)一個commit-log。一個partition中的message的offset都是唯一的梭域，但是不同的partition中的message的offset可能是相同的斑举。
kafka集群，在配置的時間范圍內(nèi)病涨，維護所有的由producer生成的消息富玷，而不管這些消息有沒有被消費。例如日志保留( log retention )時間被設(shè)置為2天既穆。kafka會維護最近2天生產(chǎn)的所有消息赎懦，而2天前的消息會被丟棄。kafka的性能與保留的數(shù)據(jù)量的大小沒有關(guān)系幻工，因此保存大量的數(shù)據(jù)(日志信息)不會有什么影響励两。
每個consumer是基于自己在commit log中的消費進度(offset)來進行工作的。
在kafka中囊颅，offset由consumer來維護：一般情況下我們按照順序逐條消費commit log中的消息当悔，當(dāng)然我可以通過指定offset來重復(fù)消費某些消息傅瞻，或者跳過某些消息。
這意味kafka中的consumer對集群的影響是非常小的盲憎，添加一個或者減少一個consumer嗅骄，對于集群或者其他consumer來說，都是沒有影響的饼疙，因此每個consumer維護各自的offset溺森。
對log進行分區(qū)（partitioned），有以下目的：
首先窑眯，當(dāng)log文件大小超過系統(tǒng)文件系統(tǒng)的限制時儿惫，可以自動拆分。
每個partition對應(yīng)的log都受到所在機器的文件系統(tǒng)大小的限制伸但，但是一個Topic中是可以有很多分區(qū)的，因此可以處理任意數(shù)量的數(shù)據(jù)留搔。
另一個方面更胖，是為了提高并行度。
Distribution
log的partitions分布在kafka集群中不同的broker上隔显，每個broker可以請求備份其他broker上partition上的數(shù)據(jù)却妨。kafka集群支持配置一個partition備份的數(shù)量。
針對每個partition括眠，都有一個broker起到“l(fā)eader”的作用彪标，0個多個其他的broker作為“follwers”的作用。
leader處理所有的針對這個partition的讀寫請求掷豺，而followers被動復(fù)制leader的結(jié)果捞烟。
如果這個leader失效了，其中的一個follower將會自動的變成新的leader当船。
每個broker都是自己所管理的partition的leader题画，
同時又是其他broker所管理partitions的followers，kafka通過這種方式來達(dá)到負(fù)載均衡德频。
Producers
生產(chǎn)者將消息發(fā)送到topic中去苍息，同時負(fù)責(zé)選擇將message發(fā)送到topic的哪一個partition中。通過round-robin做簡單的負(fù)載均衡壹置，也可以根據(jù)消息中的某一個關(guān)鍵字來進行區(qū)分竞思。通常第二種方式使用的更多。
Consumers
傳統(tǒng)的消息傳遞模式有2種：隊列( queuing)和（ publish-subscribe）钞护。
在queuing模式中盖喷，多個consumer從服務(wù)器中讀取數(shù)據(jù)，消息只會到達(dá)一個consumer患亿。
在 publish-subscribe 模型中传蹈，消息會被廣播給所有的consumer押逼。Kafka基于這2種模式提供了一種consumer的抽象概念：consumer group。
每個consumer都要標(biāo)記自己屬于哪一個consumer group惦界。
發(fā)布到topic中的message中message會被傳遞到consumer group中的一個consumer 實例挑格。
consumer實例可以運行在不同的進程上，也可以在不同的物理機器上沾歪。
如果所有的consumer都位于同一個consumer group 下漂彤，這就類似于傳統(tǒng)的queue模式，并在眾多的consumer instance之間進行負(fù)載均衡灾搏。
如果所有的consumer都有著自己唯一的consumer group挫望，這就類似于傳統(tǒng)的publish-subscribe模型。
更一般的情況是狂窑，通常一個topic會有幾個consumer group媳板，每個consumer group都是一個邏輯上的訂閱者（ logical subscriber ）。每個consumer group由多個consumer instance組成泉哈，從而達(dá)到可擴展和容災(zāi)的功能蛉幸。
這并沒有什么特殊的地方，僅僅是將publish-subscribe模型中的運行在單個進程上的consumers中的consumer替換成一個consumer group丛晦。如下圖所示：
說明：由2個broker組成的kafka集群奕纫，總共有4個Parition(P0-P3)。這個集群由2個Consumer Group烫沙， A有2個 consumer instances 匹层，而B有四個。
消費順序
Kafka比傳統(tǒng)的消息系統(tǒng)有著更強的順序保證锌蓄。
在傳統(tǒng)的情況下升筏，服務(wù)器按照順序保留消息到隊列，如果有多個consumer來消費隊列中的消息煤率，服務(wù)器 會接受消息的順序向外提供消息仰冠。
但是，盡管服務(wù)器是按照順序提供消息蝶糯，但是消息傳遞到每一個consumer是異步的洋只，這可能會導(dǎo)致先消費的 consumer獲取到消息時間可能比后消費的consumer獲取到消息的時間長，導(dǎo)致不能保證順序性昼捍。
這表明识虚，當(dāng)進行并行的消費的時候，消息在多個 consumer之間可能會失去順序性妒茬。
消息系統(tǒng)通常會采取一種“ exclusive consumer”的概念担锤，來確保同一時間內(nèi)只有一個consumer能夠從隊列中進行消費，但是這實際上意味著在消息處理的過程中是不支持并行的乍钻。
Kafka在這方面做的更好肛循。通過Topic中并行度的概念铭腕，即partition，Kafka可以同時提供順序性保證和多個consumer同時消費時的負(fù)載均衡多糠。
實現(xiàn)的原理是通過將一個topic中的partition分配給一個consumer group中的不同consumer instance累舷。通過這種方式，我們可以保證一個partition在同一個時刻只有一個consumer instance在消息夹孔，從而保證順序被盈。
雖然一個topic中有多個partition，但是一個consumer group中同時也有多個consumer instance搭伤，通過合理的分配依然能夠保證負(fù)載均衡只怎。
需要注意的是，一個consumer group中的consumer instance的數(shù)量不能比一個Topic中的partition的數(shù)量多怜俐。
Kafka只在partition的范圍內(nèi)保證消息消費的局部順序性身堡，不能在同一個topic中的多個partition中保證總的消費順序性。
通常來說拍鲤，這已經(jīng)可以滿足大部分應(yīng)用的需求盾沫。
但是，如果的確有在總體上保證消費的順序的需求的話殿漠，那么我們可以通過將topic的partition數(shù)量設(shè)置為1，將consumer group中的consumer instance數(shù)量也設(shè)置為1佩捞。
Guarantees
從較高的層面上來說的話绞幌，Kafka提供了以下的保證：
發(fā)送到一個Topic中的message會按照發(fā)送的順序添加到commit log中。
意思是一忱，如果消息 M1莲蜘，M2由同一個producer發(fā)送，M1比M2發(fā)送的早的話帘营，那么在commit log中票渠，M1的offset就會比commit 2的offset小。
一個consumer在commit log中可以按照發(fā)送順序來消費message
如果一個topic的備份因子( replication factor )設(shè)置為N芬迄，那么Kafka可以容忍N-1個服務(wù)器的失敗问顷，而存儲在commit log中的消息不會丟失。
更多介紹請查看官網(wǎng)文檔：http://kafka.apache.org/intro.html
kafka基礎(chǔ)介紹完成：）禀梳。
