跨IDC讀寫導(dǎo)致帶寬壓力大問題。多個業(yè)務(wù)還可能有重復(fù)consume和produce，造成跨IDC網(wǎng)絡(luò)的極大浪費(fèi)， 另外跨IDC網(wǎng)絡(luò)并不穩(wěn)定，經(jīng)常遇到一些異常
業(yè)務(wù)直接使用官方裸客戶端有困難，要進(jìn)行二次封裝
異常情況會catch不全
使用好kafka對業(yè)務(wù)有較高要求
客戶端容錯不能完全cover住360場景要求。當(dāng)網(wǎng)絡(luò)或集群異常直至不可用性時，數(shù)據(jù)就會丟失
不支持exactly once語義，需要業(yè)務(wù)配合實(shí)現(xiàn)
......
數(shù)據(jù)高可用支持不足，如果分片的所有副本都分布在單個機(jī)架上，數(shù)據(jù)有丟失風(fēng)險高
數(shù)據(jù)分片(partition)分布不均衡。如果集群節(jié)點(diǎn)數(shù)量遠(yuǎn)大于分區(qū)數(shù)，kafka默認(rèn)分配算法會造成數(shù)據(jù)傾斜，某些節(jié)點(diǎn)分配多，一些分配很少硬件資源利用率低
集群內(nèi)新老機(jī)器因配置差異負(fù)載不均衡。隨著時間推移硬件快速發(fā)展，新加入的機(jī)器性能是老機(jī)器成幾何倍數(shù)提高，如果平均分配，則負(fù)載不均衡，新機(jī)器吃不飽，老機(jī)器吃不了。
360選型Kafka從下面幾個維度考慮：社區(qū)活躍度、客戶端支持、吞吐量、數(shù)據(jù)可靠性比較
從kafka架構(gòu)設(shè)計亮點(diǎn)分析
Kafka性能和吞吐都很高，通過sendfile和pagecache來實(shí)現(xiàn)zero copy機(jī)制，順序讀寫的特性使得用普通磁盤就可以做到很大的吞吐，相對來說性價比比較高。
Kafka通過replica和isr機(jī)制來保證數(shù)據(jù)的高可用。
Kafka集群有兩個管理角色：controller主要是做集群的管理；coordinator主要做業(yè)務(wù)級別的管理。他們都由Kafka里面的某個broker來擔(dān)任，當(dāng)某個broker failover時，選舉其中一個broker來替代即可，從中可以發(fā)現(xiàn)Kafka一個去中心化的設(shè)計，但controller本身也是一個瓶頸，可以類比于hadoop的namenode。
分布式系統(tǒng)實(shí)現(xiàn)要么是CP，要么是AP。Kafka實(shí)現(xiàn)比較靈活，不同業(yè)務(wù)可以根據(jù)自身業(yè)務(wù)特點(diǎn)來對topic級別做偏CP或偏AP的配置。
根據(jù)以上多個MQ多維度比較，綜合權(quán)衡優(yōu)劣勢考慮，360最終選擇了Kafka
目前集群有千億級日志量，PB級數(shù)據(jù)量
集群規(guī)模：100多臺萬兆機(jī)器，
cpu 24 core、network 10Gb/s、128GB、磁盤 4TB*12 JBOD
單topic的最大峰值60萬QPS
集群的峰值大概在500萬QPS
部署版本為kafka-1.1.1
改造跨IDC讀寫帶寬大問題
利用mirrormaker進(jìn)行IDC同步數(shù)據(jù)，IDC間數(shù)據(jù)只同步一份
一是屏蔽了異常對業(yè)務(wù)的影響
節(jié)省了IDC之間的帶寬，通過同步機(jī)制能保證這份數(shù)據(jù)只傳輸一份
所有業(yè)務(wù)只做本地讀寫
硬件資源池docker化，提供服務(wù)SLA
解決Kafka客戶端易用性和穩(wěn)定性
基于Kafka官網(wǎng)客戶端進(jìn)行二次封裝，封裝原則如下
對業(yè)務(wù)進(jìn)行細(xì)節(jié)屏蔽掉，暴露出足夠簡單的接口
框架處理所有細(xì)節(jié)，減少業(yè)務(wù)犯錯概率
針對producer和consumer分別提高2個組件LogProducer和LogConsumer
極端情況仍然可用
網(wǎng)絡(luò)或集群異常保證仍然可用，如果網(wǎng)絡(luò)或集群不可用，數(shù)據(jù)會先落到本地，等恢復(fù)的時候再從本地磁盤恢復(fù)到Kafka中。
提供LogProducer
支持at least once語義
提供LogConsumer
支持at least once
exactly once語義，需要業(yè)務(wù)去實(shí)現(xiàn)rollback接口
解決數(shù)據(jù)和資源均衡性及利用率問題
用一致性hash環(huán)增加虛擬節(jié)點(diǎn)，解決數(shù)據(jù)分片(partition)分布不均衡問題
新建hash circle：通過vnode_str（比如hostname-v0）做一個MD5的hash，得到虛擬節(jié)點(diǎn)的vnode_key，再用ring字典來保存虛擬節(jié)點(diǎn)到物理節(jié)點(diǎn)的映射，同時將vnode_key加入到sorted_keys的list中
在hash環(huán)中分配replica: 將(topic_name partition_num replica_num)作為key用相同的MD5 hash算法得到replica_key, 接著二分查找該replica_key在sorted_keys中的position, 最后用ring字典來映射到物理機(jī)node, 至此replica分配完成
用多機(jī)架均衡分配副本解決副本聚集單機(jī)架可用性低問題
實(shí)現(xiàn)replica的rack aware，物理節(jié)點(diǎn)上面會有rack信息，在為replica分配物理節(jié)點(diǎn)的時候會記錄已經(jīng)分配的rack信息，如果有重復(fù)的情況，就會把vnode_key找到position的位置 1找下一個物理節(jié)點(diǎn)，我們會確保三個replica的物理rack一定是不一樣的（假如replica=3）
用分區(qū)及副本的權(quán)重數(shù)量分配解決新老機(jī)器配置差異負(fù)載不均衡問題
添加物理節(jié)點(diǎn)只需遷移很小一部分?jǐn)?shù)據(jù)；
對不同配置的物理機(jī)做權(quán)重設(shè)置，可以支持異構(gòu)集群的部署；
啟用鑒權(quán)、授權(quán)和ACL，增強(qiáng)安全性
白名單機(jī)制，通過工單申請流程管理合法topics、consumers，過濾非法的
監(jiān)控報警支持
用jmx exporter promehteus grafana來做圖表展示，每個broker上面部署jmx exporter, prometheus會去pull這些數(shù)據(jù)，最后通過grafana來展示
用Kafka manager做瞬態(tài)指標(biāo)的監(jiān)控
用burrow做consumer lag的監(jiān)控
用wonder來做告警，這個是360內(nèi)部實(shí)現(xiàn)的一個組件，類似zabbix
SLA保障
把業(yè)務(wù)分為三類優(yōu)先級，高優(yōu)先級重點(diǎn)保障，低優(yōu)先topic降級
當(dāng)突然服務(wù)負(fù)載高，緊急情況下可對低優(yōu)先級服務(wù)降級。例如：進(jìn)行請求/復(fù)制限流
千億級數(shù)據(jù)量的Kafka深度實(shí)踐：https://mp.weixin.qq.com/s/5p1IgayVXvCSLLc0Zvoqew
博客地址引用：https://www.cnblogs.com/lizherui/p/12656777.html
來源：https://www.icode9.com/content-4-674451.html
