# Kafka訂閱 - 機制主要透過Topic做索引 ![](https://hackmd.io/_uploads/S16C_-6xT.png) - 利用訊息的index,每個用戶指向特定標籤 ![](https://hackmd.io/_uploads/SJ7kKWpga.png) # Kafka組成 1. Broker:Kafka節點,1個Kafka節點就是1個broker,多個broker可以組成1個Kafka集群。 2. Topic:一類消息,消息存放的目錄即主題,例如page view日誌、click日誌等都可以以topic的形式存在,Kafka集群能夠同時負責多個topic的分發。 3. Partition:topic物理上的分組,1個topic可以分為多個partition,每個partition是1個有序的隊列 4. Segment:partition物理上由多個segment組成,每個Segment存著message信息 5. Producer : 生產message發送到topic下的partition leader 6. Consumer : 訂閱topic消費message, consumer作為1個線程來消費 7. Consumer Group:1個Consumer Group包含多個consumer, 這個是預先在配置文件中配置好的。 ![](https://hackmd.io/_uploads/SkMHjZax6.png) ## Partition介紹 - 一個broker裡面會有好幾個partition ![](https://hackmd.io/_uploads/B1nrpZax6.png) - 新的訂閱 ![](https://hackmd.io/_uploads/Byw_TZalp.png) - 使用者獲取方式 ![](https://hackmd.io/_uploads/HkFcabTxT.png) ## Consumer group ### 分類方式1:RoundRobin > 優點:每次人數不均勻的時候會重新分配,讓每一個consumer group人數均衡 > 缺點:消費混亂 ![](https://hackmd.io/_uploads/rkeuef6xT.png) ### 分類方式2:range > 優點:按主題分配,比較不會混亂 > 缺點:負載會很不均勻 ![](https://hackmd.io/_uploads/B1REGG6e6.png) ![](https://hackmd.io/_uploads/r1pO_mpea.png) 1. BOOTSTRAP_SERVERS_CONFIG = "bootstrap.servers"; > server位置 2. RETRIES_CONFIG = "retries"; > spring.kafka.producer.retries=0 重試機制(允許幾次) 3. RETRY_BACKOFF_MS_CONFIG = "retry.backoff.ms"; > 允許幾秒後重複 4. BATCH_SIZE_CONFIG = "batch.size"; > 每個batch要達到多大大小(kb)才會發送 5. LINGER_MS_CONFIG = "linger.ms"; > 1個Batch被創建之後,最多過多久,不管這個Batch有沒有寫滿,都必須發送出去了。 6. BUFFER_MEMORY_CONFIG = "buffer.memory"; >Kafka的客戶端發送數據到服務器,不是來1條就發1條,而是經過緩沖的,也就是說,通過KafkaProducer發送出去的消息都是先進入到客戶端本地的內存緩沖裏,然後把很多消息收集成1個1個的Batch,再發送到Broker上去的,這樣性能才可能高。 > buffer.memory的本質就是用來約束KafkaProducer能夠使用的內存緩沖的大小的,默認值32MB。 > 如果buffer.memory設置的太小,可能導致的問題是:消息快速的寫入內存緩沖裏,但Sender線程來不及把Request發送到Kafka服務器,會造成內存緩沖很快就被寫滿。而壹旦被寫滿,就會阻塞用戶線程,不讓繼續往Kafka寫消息了。 >所以“buffer.memory”參數需要結合實際業務情況壓測,需要測算在生產環境中用戶線程會以每秒多少消息的頻率來寫入內存緩沖。經過壓測,調試出來1個合理值。 ## KafkaTemplate send message ![](https://hackmd.io/_uploads/ByS3Cw6xT.png) ## @KafkaListener 監聽topic > ![](https://hackmd.io/_uploads/r1P1ydpeT.png)