不同的發(fā)行版本
- Apache kafak
- Confluent kafka
- CDH kafak
迭代版本
- 0.7版本 ： 只提供了最基礎(chǔ)的消息隊(duì)列功能
- 0.8版本 ： 引入了副本機(jī)制
- 0.9.0.0版本 : 增加安全認(rèn)證/權(quán)限功能挽唉；使用java重寫(xiě)了新版本的消費(fèi)者api缸濒；引入了kafak Connect組件;
- 0.10.0.0版本 ： 引入kafka Streams, 升級(jí)成分布式流處理平臺(tái)
- 0.11.0.0版本 ： 提供了冪等性Producer API及事務(wù)API羹幸；對(duì)kafka>消息格式做了重構(gòu)
- 1.0和2.0版本 ： Kafka Streams的優(yōu)化改進(jìn)
使用時(shí)盡量保持服務(wù)器端版本和客戶(hù)端版本一致
如何估算生產(chǎn)環(huán)境所需Kafka 服務(wù)器數(shù)量
假設(shè)公司的機(jī)房環(huán)境是千兆網(wǎng)絡(luò)蛉威，即 1Gbps; 業(yè)務(wù)需求1 小時(shí)內(nèi)處理 1TB 的業(yè)務(wù)數(shù)據(jù)扬绪；需要多少臺(tái) Kafka 服務(wù)器來(lái)完成這個(gè)業(yè)務(wù)呢萤晴？
帶寬是 1Gbps几迄，即每秒處理 1Gb, 假設(shè) Kafka 會(huì)用到 70% 的帶寬資源, 再額外預(yù)留出 2/3 的資源牺勾，即單臺(tái)服務(wù)器使用帶寬 700Mb / 3 ≈ 240Mbps;
1 小時(shí)內(nèi)處理 1TB 數(shù)據(jù), 根據(jù)這個(gè)目標(biāo)，我們每秒需要處理 2336Mb (1024 * 1024 * 8 / 3600 )的數(shù)據(jù)毅整，除以 240趣兄，約等于 10 臺(tái)服務(wù)器； 如果消息還需要額外復(fù)制兩份悼嫉，那么總的服務(wù)器臺(tái)數(shù)還要乘以 3艇潭，即 30 臺(tái)。
如何估算生產(chǎn)環(huán)境所需Kafka 的磁盤(pán)容量
假如每天1 億條消息戏蔑，每條消息大小1KB, 每條消息保存兩份且留存兩周的時(shí)間蹋凝；那么kafka集群需要預(yù)留多少磁盤(pán)空間？
每天的消息大小為1 億 * 1KB * 2 / 1000 / 1000 = 200GB总棵； 還要為索引等文件預(yù)留出 10% 的磁盤(pán)空間仙粱，那么兩周所需要的磁盤(pán)空間為：200GB * 1.1 * 14 = 大約 3TB 左右；假設(shè)壓縮比是 0.75彻舰，那么最后你需要規(guī)劃的存儲(chǔ)空間就是 0.75 * 3 = 2.25TB伐割。
重要的生產(chǎn)運(yùn)維參數(shù)
建議配置多個(gè)路徑，且最好掛載到不同磁盤(pán)上
log.dirs：/home/kafka1,/home/kafka2,/home/kafka3多個(gè) Kafka 集群使用同一套 ZooKeeper 集群時(shí)
zookeeper.connect: zk1:2181,zk2:2181,zk3:2181/kafka1listeners給內(nèi)網(wǎng)訪問(wèn)刃唤； advertised.listeners主要是為外網(wǎng)訪問(wèn)用的隔心；Broker 端和 Client 端應(yīng)用配置中最好全部填寫(xiě)主機(jī)名
listeners：SSL: //localhost:9092
advertised.listeners：是否允許自動(dòng)創(chuàng)建 Topic
auto.create.topics.enable：false是否允許 Unclean Leader 選舉
unclean.leader.election.enable：false是否允許定期進(jìn)行 Leader 選舉
auto.leader.rebalance.enable：false都是控制一條消息數(shù)據(jù)被保存多長(zhǎng)時(shí)間
log.retention.hours=168 表示默認(rèn)保存 7 天的數(shù)據(jù)指定 Broker 為消息保存的總磁盤(pán)容量大小
log.retention.bytes：值默認(rèn)是 -1控制 Broker 能夠接收的最大消息大小
message.max.bytes：默認(rèn)的 1000012 太少了，還不到 1MB
不丟失消息的參考配置
發(fā)送消息時(shí)使用帶回調(diào)的接口
producer.send(msg, callback)表明所有ISR中副本 Broker 都要接收到消息尚胞，該消息才算是“已提交”
Producer端的參數(shù) 設(shè)置設(shè)置 acks = all自動(dòng)重試消息發(fā)送
Producer端的參數(shù)設(shè)置retries > 0將消息多保存幾份
Broker 端的參數(shù) replication.factor >= 3控制的是消息至少要被寫(xiě)入到多少個(gè)副本才算是“已提交”
Broker 端的參數(shù) min.insync.replicas > 1硬霍； 默認(rèn)值為 1確保 replication.factor > min.insync.replicas。如果兩者相等笼裳，那么只要有一個(gè)副本掛機(jī)唯卖，整個(gè)分區(qū)就無(wú)法正常工作了
確保消息消費(fèi)完成再提交
Consumer 端的參數(shù) enable.auto.commit=false；并采用手動(dòng)提交位移的方式
減少Rebalance
Consumer 端參數(shù)躬柬，多久沒(méi)有接受到心跳移除consumer
建議session.timeout.ms = 6s 默認(rèn)10sConsumer 端參數(shù)拜轨，Consumer 實(shí)例發(fā)送心跳請(qǐng)求的頻率，要保證 Consumer 實(shí)例在被判定為“dead”之前允青，能夠發(fā)送至少 3 輪的心跳請(qǐng)求
建議heartbeat.interval.ms = 2sConsumer 端參數(shù)橄碾，Consumer 端應(yīng)用程序兩次調(diào)用 poll 方法的最大時(shí)間間隔。 超過(guò)Consumer 會(huì)主動(dòng)發(fā)起“離開(kāi)組”的請(qǐng)求（一般發(fā)生在手動(dòng)提交）
建議max.poll.interval.ms 設(shè)置得大一點(diǎn)颠锉，比下游最大處理時(shí)間稍長(zhǎng)一點(diǎn)法牲；默認(rèn)5分鐘； 或改小點(diǎn)max.poll.records（默認(rèn)500）
