kafka文件機(jī)制：

• Partition Owner registry :

  1. 用來標(biāo)記partition正在被哪個(gè)consumer消費(fèi).臨時(shí)znode有序。此節(jié)點(diǎn)表達(dá)了"一個(gè)partition"只能被group下一個(gè)consumer消費(fèi),同時(shí)當(dāng)group下某個(gè)consumer失效,那么將會(huì)觸發(fā)負(fù)載均衡(即:讓partitions在多個(gè)consumer間均衡消費(fèi),接管那些"游離"的partitions)。

• ??持久化 ：

  1. kafka使用文件存儲(chǔ)消息(append only log),這就直接決定kafka在性能上嚴(yán)重依賴文件系統(tǒng)的本身特性.且無論任何OS下,對(duì)文件系統(tǒng)本身的優(yōu)化是非常艱難的.文件緩存/直接內(nèi)存映射等是常用的手段.
  2. 因?yàn)閗afka是對(duì)日志文件進(jìn)行append操作,因此磁盤檢索的開支是較小的;同時(shí)為了減少磁盤寫入的次數(shù),broker會(huì)將消息暫時(shí)buffer起來,當(dāng)消息的個(gè)數(shù)(或尺寸)達(dá)到一定閥值時(shí),再flush到磁盤,這樣減少了磁盤IO調(diào)用的次數(shù).
  3. 對(duì)于kafka而言,較高性能的磁盤,將會(huì)帶來更加直接的性能提升岛请。

• 性能 ：

  1. 除磁盤IO之外,我們還需要考慮網(wǎng)絡(luò)IO,這直接關(guān)系到kafka的吞吐量問題.kafka并沒有提供太多高超的技巧;對(duì)于producer端,可以將消息buffer起來,當(dāng)消息的條數(shù)達(dá)到一定閥值時(shí),批量發(fā)送給broker;對(duì)于consumer端也是一樣,批量fetch多條消息.不過消息量的大小可以通過配置文件來指定. 對(duì)于kafka broker端,sendfile系統(tǒng)調(diào)用可以潛在的提升網(wǎng)絡(luò)IO的性能 : 將文件的數(shù)據(jù)映射到系統(tǒng)內(nèi)存中,socket直接讀取相應(yīng)的內(nèi)存區(qū)域即可,而無需進(jìn)程再次copy和交換( 這里涉及到"磁盤IO數(shù)據(jù)"/"內(nèi)核內(nèi)存"/"進(jìn)程內(nèi)存"/"網(wǎng)絡(luò)緩沖區(qū)",多者之間的數(shù)據(jù)copy)旭寿。
  2. 其實(shí)對(duì)于producer/consumer/broker三者而言,CPU的開支應(yīng)該都不大, 因此啟用消息壓縮機(jī)制是一個(gè)良好的策略;壓縮需要消耗少量的CPU資源,不過對(duì)于kafka而言,網(wǎng)絡(luò)IO更應(yīng)該需要考慮.可以將任何在網(wǎng)絡(luò)上傳輸?shù)南⒍冀?jīng)過壓縮. kafka支持gzip/snappy 等多種壓縮方式.

• ??負(fù)載均衡 :

  1. kafka集群中的任何一個(gè)broker,都可以向producer提供metadata信息, 這些metadata中包含"集群中存活的servers列表"、"partitions leader列表" 等信息(請(qǐng)參看zookeeper中的節(jié)點(diǎn)信息)崇败。
  2. 當(dāng)producer獲取到metadata信息之后, producer將會(huì)和Topic下所有partition leader保持socket連接;消息由producer直接通過socket發(fā)送到broker,中間不會(huì)經(jīng)過任何"路由層"盅称。
  3. 異步發(fā)送，將多條消息暫且在客戶端buffer起來,并將他們批量發(fā)送到broker;小數(shù)據(jù)IO太多,會(huì)拖慢整體的網(wǎng)絡(luò)延遲,批量延遲發(fā)送事實(shí)上提升了網(wǎng)絡(luò)效率;不過這也有一定的隱患,比如當(dāng)producer失效時(shí),那些尚未發(fā)送的消息將會(huì)丟失后室。

• Topic模型 ：

  1. 在kafka中,partition中的消息只有一個(gè)consumer在消費(fèi),且不存在消息狀態(tài)的控制,也沒有復(fù)雜的消息確認(rèn)機(jī)制,可見kafka broker端是相當(dāng)輕量級(jí)的.當(dāng)消息被consumer接收之后,consumer可以在本地保存最后消息的offset,并間歇性的向zookeeper提交offset.由此可見,consumer客戶端也很輕量級(jí)缩膝。松弛得控制就會(huì)引起重復(fù)消費(fèi)與消息丟失等問題。
  2. kafka中consumer負(fù)責(zé)維護(hù)消息的消費(fèi)記錄,而broker則不關(guān)心這些,這種設(shè)計(jì)不僅提高了consumer端的靈活性,也適度的減輕了broker端設(shè)計(jì)的復(fù)雜度;這是和眾多JMS prodiver的區(qū)別.

• ??log ：

  1. 每個(gè)log entry格式為"4個(gè)字節(jié)的數(shù)字N表示消息的長(zhǎng)度" + "N個(gè)字節(jié)的消息內(nèi)容"; 每個(gè)日志都有一個(gè)offset來唯一的標(biāo)記一條消息, offset的值為8個(gè)字節(jié)的數(shù)字,表示此消息在此partition中所處的起始位置.
  2. 每個(gè)partition在物理存儲(chǔ)層面由多個(gè)log file組成(稱為segment) .segment file的命名為"最小offset".kafka.例如"00000000000.kafka";其中"最小offset"表示此segment中起始消息的offset.
  3. 獲取消息時(shí),需要指定offset和最大chunk尺寸,offset用來表示消息的起始位置,chunk size用來表示最大獲取消息的總長(zhǎng)度(間接的表示消息的條數(shù)). 根據(jù)offset,可以找到此消息所在segment文件,然后根據(jù)segment的最小offset取差值,得到它在file中的相對(duì)位置,直接讀取輸出即可.

• Partition Owner registry :

  1. 用來標(biāo)記partition正在被哪個(gè)consumer消費(fèi).臨時(shí)znode岸霹。此節(jié)點(diǎn)表達(dá)了"一個(gè)partition"只能被group下一個(gè)consumer消費(fèi),同時(shí)當(dāng)group下某個(gè)consumer失效,那么將會(huì)觸發(fā)負(fù)載均衡(即:讓partitions在多個(gè)consumer間均衡消費(fèi),接管那些"游離"的partitions)疾层。例如：當(dāng)consumer啟動(dòng)時(shí),所觸發(fā)的操作 :

A) 首先進(jìn)行"Consumer id Registry";
B) 然后在"Consumer id Registry"節(jié)點(diǎn)下注冊(cè)一個(gè)watch用來監(jiān)聽當(dāng)前group中其他consumer的"leave"和"join";只要此znode path下節(jié)點(diǎn)列表變更,都會(huì)觸發(fā)此group下consumer的負(fù)載均衡.(比如一個(gè)consumer失效,那么其他consumer接管partitions).
C) 在"Broker id registry"節(jié)點(diǎn)下,注冊(cè)一個(gè)watch用來監(jiān)聽broker的存活情況;如果broker列表變更,將會(huì)觸發(fā)所有的groups下的consumer重新balance.

??總結(jié)?? :
① Producer端使用zookeeper用來"發(fā)現(xiàn)"broker列表,以及和Topic下每個(gè)partition leader建立socket連接并發(fā)送消息.
② Broker端使用zookeeper用來注冊(cè)broker信息,以及監(jiān)測(cè)partition leader存活性.
③ Consumer端使用zookeeper用來注冊(cè)consumer信息,其中包括consumer消費(fèi)的partition列表等,同時(shí)也用來發(fā)現(xiàn)broker列表,并和partition leader建立socket連接,并獲取消息。

• Leader的選擇 :

  1. 必須保證贡避，一旦一個(gè)消息被提交了痛黎，但是leader down掉了予弧，新選出的leader必須可以提供這條消息。大部分的分布式系統(tǒng)采用了多數(shù)投票法則選擇新的leader,對(duì)于多數(shù)投票法則湖饱，就是根據(jù)所有副本節(jié)點(diǎn)的狀況動(dòng)態(tài)的選擇最適合的作為leader.Kafka并不是使用這種方法掖蛤。
  2. ??Kafka動(dòng)態(tài)維護(hù)了一個(gè)同步狀態(tài)的副本的集合（a set of in-sync replicas），簡(jiǎn)稱ISR井厌，在這個(gè)集合中的節(jié)點(diǎn)都是和leader保持高度一致的蚓庭，任何一條消息必須被這個(gè)集合中的每個(gè)節(jié)點(diǎn)讀取并追加到日志中了，才會(huì)通知外部這個(gè)消息已經(jīng)被提交了仅仆。因此這個(gè)集合中的任何一個(gè)節(jié)點(diǎn)隨時(shí)都可以被選為leader.ISR在ZooKeeper中維護(hù)彪置。ISR中有f+1個(gè)節(jié)點(diǎn)，就可以允許在f個(gè)節(jié)點(diǎn)down掉的情況下不會(huì)丟失消息并正常提供服蝇恶。ISR的成員是動(dòng)態(tài)的拳魁，如果一個(gè)節(jié)點(diǎn)被淘汰了，當(dāng)它重新達(dá)到“同步中”的狀態(tài)時(shí)撮弧，他可以重新加入ISR.這種leader的選擇方式是非撑税茫快速的，適合kafka的應(yīng)用場(chǎng)景贿衍。

• 副本管理 ：

  1. ??Kafka盡量的使所有分區(qū)均勻的分布到集群所有的節(jié)點(diǎn)上而不是集中在某些節(jié)點(diǎn)上授舟，另外主從關(guān)系也盡量均衡，這樣每個(gè)節(jié)點(diǎn)都會(huì)擔(dān)任一定比例的分區(qū)的leader.
  2. 優(yōu)化leader的選擇過程也是很重要的贸辈，它決定了系統(tǒng)發(fā)生故障時(shí)的空窗期有多久释树。Kafka選擇一個(gè)節(jié)點(diǎn)作為“controller”,當(dāng)發(fā)現(xiàn)有節(jié)點(diǎn)down掉的時(shí)候它負(fù)責(zé)在有用分區(qū)的所有節(jié)點(diǎn)中選擇新的leader,這使得Kafka可以批量的高效的管理所有分區(qū)節(jié)點(diǎn)的主從關(guān)系。如果controller down掉了擎淤，活著的節(jié)點(diǎn)中的一個(gè)會(huì)備切換為新的controller.

• Leader與副本同步 ：

  1. ??對(duì)于某個(gè)分區(qū)來說奢啥，保存正分區(qū)的"broker"為該分區(qū)的"leader"，保存?zhèn)浞莘謪^(qū)的"broker"為該分區(qū)的"follower"嘴拢。備份分區(qū)會(huì)完全復(fù)制正分區(qū)的消息桩盲，包括消息的編號(hào)等附加屬性值。為了保持正分區(qū)和備份分區(qū)的內(nèi)容一致席吴，Kafka采取的方案是在保存?zhèn)浞莘謪^(qū)的"broker"上開啟一個(gè)消費(fèi)者進(jìn)程進(jìn)行消費(fèi)赌结，從而使得正分區(qū)的內(nèi)容與備份分區(qū)的內(nèi)容保持一致。一般情況下孝冒，一個(gè)分區(qū)有一個(gè)“正分區(qū)”和零到多個(gè)“備份分區(qū)”柬姚。可以配置“正分區(qū)+備份分區(qū)”的總數(shù)量庄涡，關(guān)于這個(gè)配置量承，不同主題可以有不同的配置值。注意，生產(chǎn)者宴合，消費(fèi)者只與保存正分區(qū)的"leader"進(jìn)行通信焕梅。
  2. Kafka允許topic的分區(qū)擁有若干副本，這個(gè)數(shù)量是可以配置的卦洽，你可以為每個(gè)topic配置副本的數(shù)量贞言。Kafka會(huì)自動(dòng)在每個(gè)副本上備份數(shù)據(jù)，所以當(dāng)一個(gè)節(jié)點(diǎn)down掉時(shí)數(shù)據(jù)依然是可用的阀蒂。
  3. ??創(chuàng)建副本的單位是topic的分區(qū)该窗，每個(gè)分區(qū)都有一個(gè)leader和零或多個(gè)followers.所有的讀寫操作都由leader處理，一般分區(qū)的數(shù)量都比broker的數(shù)量多的多蚤霞，各分區(qū)的leader均勻的分布在brokers中酗失。所有的followers都復(fù)制leader的日志，日志中的消息和順序都和leader中的一致昧绣。followers向普通的consumer那樣從leader那里拉取消息并保存在自己的日志文件中规肴。
  4. ??Kafka判斷一個(gè)節(jié)點(diǎn)是否活著有兩個(gè)條件 :
     ① 節(jié)點(diǎn)必須可以維護(hù)和ZooKeeper的連接，Zookeeper通過心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連接夜畴。
     ② 如果節(jié)點(diǎn)是個(gè)follower,他必須能及時(shí)的同步leader的寫操作拖刃，延時(shí)不能太久。
  5. ??只有當(dāng)消息被所有的副本加入到日志中時(shí)贪绘，才算是“committed”兑牡，只有committed的消息才會(huì)發(fā)送給consumer，這樣就不用擔(dān)心一旦leader down掉了消息會(huì)丟失税灌。Producer也可以選擇是否等待消息被提交的通知均函，這個(gè)是由參數(shù)acks決定的。

• ????partiton中文件存儲(chǔ)方式 :

  1. 每個(gè)partion(目錄)相當(dāng)于一個(gè)巨型文件被平均分配到多個(gè)大小相等segment(段)數(shù)據(jù)文件中菱涤。但每個(gè)段segment file消息數(shù)量不一定相等苞也，這種特性方便old segment file快速被刪除。
  2. 每個(gè)partiton只需要支持順序讀寫就行了狸窘，segment文件生命周期由服務(wù)端配置參數(shù)決定墩朦。
  3. 這樣做的好處就是能快速刪除無用文件坯认，有效提高磁盤利用率翻擒。

• ????partiton中segment文件存儲(chǔ)結(jié)構(gòu) :

  1. producer發(fā)message到某個(gè)topic，message會(huì)被均勻的分布到多個(gè)partition上（隨機(jī)或根據(jù)用戶指定的回調(diào)函數(shù)進(jìn)行分布）牛哺，kafka broker收到message往對(duì)應(yīng)partition leader的最后一個(gè)segment上添加該消息陋气，當(dāng)某個(gè)segment上的消息條數(shù)達(dá)到配置值或消息發(fā)布時(shí)間超過閾值時(shí)，segment上的消息會(huì)被flush到磁盤引润，只有flush到磁盤上的消息consumer才能消費(fèi)巩趁，segment達(dá)到一定的大小后將不會(huì)再往該segment寫數(shù)據(jù)，broker會(huì)創(chuàng)建新的segment。
  2. 每個(gè)part在內(nèi)存中對(duì)應(yīng)一個(gè)index议慰，記錄每個(gè)segment中的第一條消息偏移蠢古。
  3. segment file組成：由2大部分組成，分別為index file和data file别凹，此2個(gè)文件一 一對(duì)應(yīng)草讶，成對(duì)出現(xiàn)，后綴".index"和“.log”分別表示為segment索引文件炉菲、數(shù)據(jù)文件.
  4. segment文件命名規(guī)則：partion全局的第一個(gè)segment從0開始堕战，后續(xù)每個(gè)segment文件名為上一個(gè)全局partion的最大offset(偏移message數(shù))。數(shù)值最大為64位long大小拍霜，19位數(shù)字字符長(zhǎng)度嘱丢，沒有數(shù)字用0填充。
  5. 每個(gè)segment中存儲(chǔ)很多條消息祠饺，消息id由其邏輯位置決定越驻，即從消息id可直接定位到消息的存儲(chǔ)位置，避免id到位置的額外映射道偷。
  6. 下圖所示segment文件列表形象說明了上述2個(gè)規(guī)則：
     Kafka文件格式
     索引文件存儲(chǔ)大量元數(shù)據(jù)伐谈，數(shù)據(jù)文件存儲(chǔ)大量消息，索引文件中元數(shù)據(jù)指向?qū)?yīng)數(shù)據(jù)文件中message的物理偏移地址试疙。其中以索引文件中 元數(shù)據(jù)3,497為例诵棵，依次在數(shù)據(jù)文件中表示第3個(gè)message(在全局partiton表示第368772個(gè)message)、以及該消息的物理偏移地址為497祝旷。
     message
     
     關(guān)鍵字解釋說明 ：
     ① 8 byte offset在parition(分區(qū))內(nèi)的每條消息都有一個(gè)有序的id號(hào)履澳，這個(gè)id號(hào)被稱為偏移(offset),它可以唯一確定每條消息在parition(分區(qū))內(nèi)的位置。即offset表示partiion的第多少message
     ② 4 byte message sizemessage大小
     ③ 4 byte CRC32用crc32校驗(yàn)message
     ④ 1 byte “magic"表示本次發(fā)布Kafka服務(wù)程序協(xié)議版本號(hào)
     ⑤ 1 byte “attributes"表示為獨(dú)立版本怀跛、或標(biāo)識(shí)壓縮類型距贷、或編碼類型。
     ⑥ 4 byte key length表示key的長(zhǎng)度,當(dāng)key為-1時(shí)吻谋，K byte key字段不填
     ⑦ K byte key可選
     ⑧ value bytes payload表示實(shí)際消息數(shù)據(jù)忠蝗。
  7. ??segment index file采取稀疏索引存儲(chǔ)方式，它減少索引文件大小漓拾，通過mmap可以直接內(nèi)存操作阁最，稀疏索引為數(shù)據(jù)文件的每個(gè)對(duì)應(yīng)message設(shè)置一個(gè)元數(shù)據(jù)指針,它 比稠密索引節(jié)省了更多的存儲(chǔ)空間，但查找起來需要消耗更多的時(shí)間骇两。
     8.??kafka會(huì)記錄offset到zk中速种。但是，zk client api對(duì)zk的頻繁寫入是一個(gè)低效的操作低千。0.8.2 kafka引入了native offset storage配阵，將offset管理從zk移出，并且可以做到水平擴(kuò)展。其原理就是利用了kafka的compacted topic棋傍，offset以consumer group,topic與partion的組合作為key直接提交到compacted topic中救拉。同時(shí)Kafka又在內(nèi)存中維護(hù)了三元組來保存最新的offset信息，consumer來取最新offset信息的時(shí)候直接內(nèi)存里拿即可瘫拣。當(dāng)然近上，kafka允許你快速的checkpoint最新的offset信息到磁盤上。

• Partition Replication原則 :

  1. Kafka高效文件存儲(chǔ)設(shè)計(jì)特點(diǎn) :
     ① Kafka把topic中一個(gè)parition大文件分成多個(gè)小文件段拂铡，通過多個(gè)小文件段壹无，就容易定期清除或刪除已經(jīng)消費(fèi)完文件，減少磁盤占用感帅。
     ② 通過索引信息可以快速定位message和確定response的最大大小斗锭。
     ③ 通過index元數(shù)據(jù)全部映射到memory，可以避免segment file的IO磁盤操作失球。
     ④ 通過索引文件稀疏存儲(chǔ)岖是，可以大幅降低index文件元數(shù)據(jù)占用空間大小。

• ??高效的數(shù)據(jù)傳輸 :

  1. 發(fā)布者每次可發(fā)布多條消息（將消息加到一個(gè)消息集合中發(fā)布）实苞，consumer每次迭代消費(fèi)一條消息豺撑。
  2. 不創(chuàng)建單獨(dú)的cache，使用系統(tǒng)的page cache黔牵。發(fā)布者順序發(fā)布聪轿，訂閱者通常比發(fā)布者滯后一點(diǎn)點(diǎn)，直接使用Linux的page cache效果比較好猾浦，同時(shí)減少了cache管理及垃圾收集的開銷陆错。
  3. page cache中的每個(gè)文件都是一棵基數(shù)樹（radix tree，本質(zhì)上是多叉搜索樹）金赦，樹的每個(gè)節(jié)點(diǎn)都是一個(gè)頁(yè)音瓷。根據(jù)文件內(nèi)的偏移量就可以快速定位到所在的頁(yè)。
  4. Kafka為什么不自己管理緩存夹抗，而非要用page cache绳慎？原因有如下三點(diǎn)：
     ① JVM中一切皆對(duì)象，數(shù)據(jù)的對(duì)象存儲(chǔ)會(huì)帶來所謂object overhead漠烧，浪費(fèi)空間杏愤；
     ② 如果由JVM來管理緩存，會(huì)受到GC的影響沽甥，并且過大的堆也會(huì)拖累GC的效率声邦，降低吞吐量；
     ③ 一旦程序崩潰摆舟，自己管理的緩存數(shù)據(jù)會(huì)全部丟失。
     page cache
  5. producer生產(chǎn)消息時(shí)，會(huì)使用pwrite()系統(tǒng)調(diào)用【對(duì)應(yīng)到Java NIO中是FileChannel.write() API】按偏移量寫入數(shù)據(jù)恨诱，并且都會(huì)先寫入page cache里媳瞪。
  6. consumer消費(fèi)消息時(shí)，會(huì)使用sendfile()系統(tǒng)調(diào)用【對(duì)應(yīng)FileChannel.transferTo() API】照宝，零拷貝地將數(shù)據(jù)從page cache傳輸?shù)絙roker的Socket buffer蛇受，再通過網(wǎng)絡(luò)傳輸。
  7. 同時(shí)厕鹃，page cache中的數(shù)據(jù)會(huì)隨著內(nèi)核中flusher線程的調(diào)度以及對(duì)sync()/fsync()的調(diào)用寫回到磁盤兢仰，就算進(jìn)程崩潰，也不用擔(dān)心數(shù)據(jù)丟失剂碴。

kafka分區(qū)的原因：

• 指明partition的情況下把将，直接將指明的值直接作為partition的值。
• 沒有指明partition值但有key的值忆矛，將key的hash值與toptic的partition數(shù)進(jìn)行取余得到partition值察蹲。
• 既沒有partition值又沒有key值的情況下，第一次調(diào)用時(shí)隨機(jī)生成一個(gè)整數(shù)（后面每次調(diào)用在這個(gè)整數(shù)上自增）催训，將這個(gè)值與 topic 可用的 partition 總數(shù)取余得到 partition 值洽议，也就是常說的 round-robin 算法。

kafka高吞吐量的原因：

• kafka的消息是不斷追加到文件中的漫拭，這個(gè)特性使kafka可以充分利用磁盤的順序讀寫性能亚兄，順序讀寫不需要硬盤磁頭的尋道時(shí)間，只需很少的扇區(qū)旋轉(zhuǎn)時(shí)間采驻，所以速度遠(yuǎn)快于隨機(jī)讀寫儿捧。生產(chǎn)者負(fù)責(zé)寫入數(shù)據(jù)，Kafka會(huì)將消息持久化到磁盤挑宠，保證不會(huì)丟失數(shù)據(jù)菲盾，Kafka采用了兩個(gè)技術(shù)提高寫入的速度：

  1. 順序?qū)懭?/strong>：硬盤是機(jī)械結(jié)構(gòu)，需要指針尋址找到存儲(chǔ)數(shù)據(jù)的位置各淀，所以懒鉴，如果是隨機(jī)IO，磁盤會(huì)進(jìn)行頻繁的尋址碎浇，導(dǎo)致寫入速度下降临谱。Kafka使用了順序IO提高了磁盤的寫入速度，Kafka會(huì)將數(shù)據(jù)順序插入到文件末尾奴璃，消費(fèi)者端通過控制偏移量來讀取消息悉默，這樣做會(huì)導(dǎo)致數(shù)據(jù)無法刪除，時(shí)間一長(zhǎng)苟穆，磁盤空間會(huì)滿抄课，kafka提供了2種策略來刪除數(shù)據(jù)：基于時(shí)間刪除和基于partition文件的大小刪除唱星。
  2. Memory Mapped Files：這個(gè)和Java NIO中的內(nèi)存映射基本相同，跟磨，mmf直接利用操作系統(tǒng)的Page來實(shí)現(xiàn)文件到物理內(nèi)存的映射间聊，完成之后對(duì)物理內(nèi)存的操作會(huì)直接同步到硬盤。mmf通過內(nèi)存映射的方式大大提高了IO速率抵拘，省去了用戶空間到內(nèi)核空間的復(fù)制哎榴。它的缺點(diǎn)顯而易見--不可靠，當(dāng)發(fā)生宕機(jī)而數(shù)據(jù)未同步到硬盤時(shí)僵蛛，數(shù)據(jù)會(huì)丟失尚蝌，Kafka提供了produce.type參數(shù)來控制是否主動(dòng)的進(jìn)行刷新，如果kafka寫入到mmp后立即flush再返回給生產(chǎn)者則為同步模式充尉，反之為異步模式飘言。

• 零拷貝：平時(shí)從服務(wù)器讀取靜態(tài)文件時(shí)，服務(wù)器先將文件從磁盤復(fù)制到內(nèi)核空間喉酌，再?gòu)?fù)制到用戶空間热凹，最后再?gòu)?fù)制到內(nèi)核空間并通過網(wǎng)卡發(fā)送出去，而零拷貝則是直接從內(nèi)核到內(nèi)核再到網(wǎng)卡泪电，省去了用戶空間的復(fù)制般妙。

  1. Kafka把所有的消息存放到一個(gè)文件中，當(dāng)消費(fèi)者需要數(shù)據(jù)的時(shí)候直接將文件發(fā)送給消費(fèi)者相速，比如10W的消息共10M碟渺，全部發(fā)送給消費(fèi)者，10M的消息在內(nèi)網(wǎng)中傳輸是非惩晃埽快的苫拍，假如需要1s，那么kafka的tps就是10w旺隙。Zero copy對(duì)應(yīng)的是Linux中sendfile函數(shù)绒极，這個(gè)函數(shù)會(huì)接受一個(gè)offsize來確定從哪里開始讀取。現(xiàn)實(shí)中蔬捷，不可能將整個(gè)文件全部發(fā)給消費(fèi)者垄提，他通過消費(fèi)者傳遞過來的偏移量來使用零拷貝讀取指定內(nèi)容的數(shù)據(jù)返回給消費(fèi)者。

## 查詢集群描述
bin/kafka-topics.sh --describe --zookeeper 

## topic列表查詢
bin/kafka-topics.sh --list --zookeeper 127.0.0.1:2181 

## topic列表查詢（支持0.9版本+）
bin/kafka-topics.sh --list --bootstrap-server localhost:9092

## 新消費(fèi)者列表查詢（支持0.9版本+）
bin/kafka-consumer-groups.sh --list  --new-consumer --bootstrap-server localhost:9092 

## 新消費(fèi)者列表查詢（支持0.10版本+）
bin/kafka-consumer-groups.sh --list  --bootstrap-server localhost:9092 

## 顯示某個(gè)消費(fèi)組的消費(fèi)詳情（僅支持offset存儲(chǔ)在zookeeper上的）
bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper localhost:2181 --group test

## 顯示某個(gè)消費(fèi)組的消費(fèi)詳情（0.9版本 - 0.10.1.0 之前）
bin/kafka-consumer-groups.sh --new-consumer --bootstrap-server localhost:9092 --describe --group test-consumer-group

## 顯示某個(gè)消費(fèi)組的消費(fèi)詳情（0.10.1.0版本+）
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

## 生產(chǎn)者
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

## 消費(fèi)者
bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test

## 新生產(chǎn)者（支持0.9版本+）
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test --producer.config config/producer.properties

## 新消費(fèi)者（支持0.9版本+）
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --new-consumer --from-beginning --consumer.config config/consumer.properties

## 高級(jí)點(diǎn)的用法
bin/kafka-simple-consumer-shell.sh --brist localhost:9092 --topic test --partition 0 --offset 1234  --max-messages 10

bin/kafka-preferred-replica-election.sh --zookeeper zk_host:port/chroot

bin/kafka-producer-perf-test.sh --topic test --num-records 100 --record-size 1 --throughput 100  --producer-props bootstrap.servers=localhost:9092

bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 --partitions 2