Kafka中消息是以topic進(jìn)行分類(lèi)的，生產(chǎn)者生產(chǎn)消息，消費者消費消息，都是面向topic的。 topic是邏輯上的概念，而partition是物理上的概念，每個(gè)partition對應于一個(gè)log文件，該log文件中存儲的就是producer生產(chǎn)的數據。Producer生產(chǎn)的數據會(huì )被不斷追加到該log文件末端，且每條數據都有自己的offset。消費者組中的每個(gè)消費者，都會(huì )實(shí)時(shí)記錄自己消費到了哪個(gè)offset，以便出錯恢復時(shí)，從上次的位置繼續消費。

Kafka是一個(gè)分布式的基于發(fā)布/訂閱模式的消息隊列，主要應用于大數據實(shí)時(shí)處理領(lǐng)域。

? Kafka的Producer發(fā)送消息采用的是異步發(fā)送的方式。在消息發(fā)送的過(guò)程中，涉及到了兩個(gè)線(xiàn)程——main線(xiàn)程和Sender線(xiàn)程，以及一個(gè)線(xiàn)程共享變量——RecordAccumulator。main線(xiàn)程將消息發(fā)送給RecordAccumulator，Sender線(xiàn)程不斷從RecordAccumulator中拉取消息發(fā)送到Kafka broker。 Consumer消費數據時(shí)的可靠性是很容易保證的，因為數據在Kafka中是持久化的，故不用擔心數據丟失問(wèn)題。 ? 由于consumer在消費過(guò)程中可能會(huì )出現斷電宕機等故障，consumer恢復后，需要從故障前的位置的繼續消費，所以consumer需要實(shí)時(shí)記錄自己消費到了哪個(gè)offset，以便故障恢復后繼續消費。 ? 所以offset的維護是Consumer消費數據是必須考慮的問(wèn)題。

通過(guò)Flink官網(wǎng)可以看到Flink里面就默認支持了不少sink，比如也支持Kafka sink connector（FlinkKafkaProducer），那么這篇文章我們就來(lái)看看如何將數據寫(xiě)入到Kafka。

上一篇文章介紹了 Flink Data Sink，也介紹了 Flink 自帶的 Sink，那么如何自定義自己的 Sink 呢？這篇文章將寫(xiě)一個(gè) demo 教大家將從 Kafka Source 的數據 Sink 到 MySQL 中去。

Source 就是數據的來(lái)源，中間的 Compute 其實(shí)就是 Flink 干的事情，可以做一系列的操作，操作完后就把計算后的數據結果 Sink 到某個(gè)地方。（可以是 MySQL、ElasticSearch、Kafka、Cassandra 等）。這里我說(shuō)下自己目前做告警這塊就是把 Compute 計算后的結果 Sink 直接告警出來(lái)了（發(fā)送告警消息到釘釘群、郵件、短信等），這個(gè) sink 的意思也不一定非得說(shuō)成要把數據存儲到某個(gè)地方去。其實(shí)官網(wǎng)用的 Connector 來(lái)形容要去的地方更合適，這個(gè) Connector 可以有 MySQL、ElasticSearch、Kafka、Cassandra RabbitMQ 等。

在 Data Source 介紹 文章中，我給大家介紹了 Flink Data Source 以及簡(jiǎn)短的介紹了一下自定義 Data Source，這篇文章更詳細的介紹下，并寫(xiě)一個(gè) demo 出來(lái)讓大家理解。

Data Sources 是什么呢？就字面意思其實(shí)就可以知道：數據來(lái)源。 Flink 做為一款流式計算框架，它可用來(lái)做批處理，即處理靜態(tài)的數據集、歷史的數據集；也可以用來(lái)做流處理，即實(shí)時(shí)的處理些實(shí)時(shí)數據流，實(shí)時(shí)的產(chǎn)生數據流結果，只要數據源源不斷的過(guò)來(lái)，Flink 就能夠一直計算下去，這個(gè) Data Sources 就是數據的來(lái)源地。

flink 的安裝參照：flink 簡(jiǎn)單入門(mén)， 我們來(lái)了解下flink的配置文件。