spring-boot-route（十四）整合Kafka

時間 2020-10-25

標籤 html java git github redis spring 數據庫 apache bootstrap 緩存欄目 Spring 简体版

原文原文鏈接

在上一章中SpringBoot整合RabbitMQ，已經詳細介紹了消息隊列的做用，這一種咱們直接來學習SpringBoot如何整合kafka發送消息。html

kafka簡介

kafka是用Scala和Java語言開發的，高吞吐量的分佈式消息中間件。高吞吐量使它在大數據領域具備自然的優點，被普遍用來記錄日誌。java

kafka架構分析

注1：圖中的紅色箭頭表示消息的流動過程，藍色表示分區備份，綠色表示kafka集羣註冊到zookeeper。git

注2：在kafka0.9版本以前，消費者消費消息的位置記錄在zookeeper中，在0.9版本以後，消費消息的位置記錄在kafka的一個topic上。github

kafka名詞簡介：redis

Producer：消息生產者
Consumer：消息消費者
Consumer Group（CG）：消費者組，一個topic能夠有多個CG，每一個Partition只會把消息發送給GG中的一個Consumer
Broker：一臺kafka服務器就是一個broker，一個broker有多個topic
Topic：消息主題，消息分類，可看做隊列
Partition：分區，爲了實現擴展，一個大的topic可能分佈到多個broker上，一個topic能夠分爲多個partition，partition中的每條消息都會被分配一個有序的id（offset），每一個partiton中的消息是有序的。
Offset：kafka的存儲文件都是按照offset.kafka來命名的，方便查找，第一個offset爲0000000000.kafka。
Leader：分區具備被備份，主分區
Follower：從分區

1. 生產者分區策略

指定分區。
沒有指定分區但有key值，將key的hash值與當前topic的分區個數進行取餘獲得分區。
若是既沒有指定分區又沒有指定key，第一次調用時隨機生成一個整數（之後調用每次在這個整數上自增），將這個隨機數與該topic的分區數取餘獲得分區。

2. 消息可靠性問題

採用ack確認機制來保證消息的可靠性。spring

kafka在發送消息後會同步到其餘分區副本，等全部副本都接收到消息後，kafka纔會發送ack進行確認。採用這種模式的劣勢就是當其中一個副本宕機後，則消息生產者就不會收到kafka的ack。數據庫

kafka採用ISR來解決這個問題。apache

ISR：Leader維護的一個和leader保持同步的follower集合。bootstrap

當ISR中的folower完成數據同步以後，leader就會向follower發送ack，若是follower長時間未向leader同步數據，則該follower就會被踢出ISR，該時間閥值的設置參數爲replica.lag.time.max.ms，默認時間爲10s，leader發生故障後，就會從ISR中選舉新的leader。緩存

注：本文所講的kafka版本爲0.11，在0.9版本之前成爲ISR還有一個條件，就是同步消息的條數。

ack參數配置

0：生產者不等待broker的ack。

1：leader分區接收到消息向生產者發送ack。

-1（all）：ISR中的leader和follower同步成功後，向生產者發送ack。

3. 消息一致性問題

假如leader中有10條消息，向兩個follower同步數據，follower A同步了8條，follower B同步了9條。這時候leader宕機了，follower A和follower B中的消息是不一致的，剩下兩個follower就會從新選舉出一個leader。

LEO（log end offset）：每一個副本的最後一個offset
HW（high watermark）：全部副本中最小的offset

爲了保證數據的一致性，全部的follower會將各自的log文件高出HW的部分截掉，而後再重新的leader中同步數據。

4. 消息重複性問題

在kafka0.11版本中引入了一個新特性：冪等性。啓用冪等性後，ack默認爲-1。將生產者中的enable.idompotence設置爲true，即啓用了冪等性。

開啓冪等性的Producer在初始化的時候會被分配一個PID，發往同一Partition的消息會附帶Sequence Number。Broker端會對<PID,Partition,SeqNumber>作緩存，當具備相同主鍵的消息提交時，Broker只會緩存一條。可是每次重啓PID就會發生變化，所以只能保證一次會話同一分區的消息不重複。

5. 消費者組分區分配策略

kafka有兩種分配策略，一種是RoundRobin，另外一種是Range

RoundRobin是按照消費者組以輪詢的方式去給消費者分配分區的方式，前提條件是消費者組中的消費者須要訂閱同一個topic。

Range是kafka默認的分配策略，它是經過當前的topic按照必定範圍來分配的，假若有3個分區，消費者組有兩個消費者，則消費者A去消費1和2分區，消費者B去消費3分區。

6. 消費者offset維護

Kafka 0.9 版本以前，consumer默認將offset保存在zookeeper中，0.9 版本開始，offset保存在kafka的一個內置topic中，該topic爲_consumer_offsets。

7. 生產者事務

爲了實現跨分區會話的事務，須要引入一個全局惟一的Tracscation ID，並將Producer 得到的PID與之綁定。這樣當Producer重啓後就能夠經過正在進行的Transaction ID得到原來的PID。

爲了管理Transcation ID，kafka引入了一個新的組件Transcation Coordinator。Producer就是經過和Transcation Coordinator交互得到Transction ID對應的任務狀態。

Spring Boot 整合kafka

1. 引入kafka依賴

<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

2. 配置kafka服務信息

spring:
  kafka:
    # kafka服務地址
    bootstrap-servers: 47.104.155.182:9092
    producer:
      # 生產者消息key序列化方式
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      # 生產者消息value序列化方式
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
    consumer:
      # 消費者組
      group-id: test-consumer-group
      # 消費者消息value反序列化方式
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      # 消費者消息value反序列化方式
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer

3. 消費者

@Component
@Slf4j
@KafkaListener(topics = {"first-topic"},groupId = "test-consumer-group")
public class Consumer {

    @KafkaHandler
    public void receive(String message){
        
        log.info("我是消費者，我接收到的消息是："+message);
    }
}

4. 生產者

@RestController
public class Producer {

    @Autowired
    private KafkaTemplate kafkaTemplate;

    @GetMapping("send")
    public void send(){

        String message = "你好，我是Java旅途";
        // 第一個參數 topic
        // 第二個參數 消息
        kafkaTemplate.send("first-topic",message);
    }
}