Kafkaの概念|アーキテクチャ|ビルド|ビューコマンド

カフカの概要

1. メッセージ キュー (MQ) が必要な主な理由は
、同時実行性の高い環境では、同期リクエストの処理が遅すぎて、リクエストがブロックされることが多いためです。たとえば、多数のリクエストが同時にデータベースにアクセスすると、行ロックやテーブル ロックが発生し、最終的にはリクエスト スレッドが多すぎて蓄積され、接続エラーが多すぎて雪崩現象が発生します。
メッセージ キューを使用して、リクエストを非同期に処理することでシステムへの負荷を軽減します。メッセージ キューは、非同期処理、トラフィックのピークカット、アプリケーションの切り離し、メッセージ通信などのシナリオでよく使用されます。

現在、より一般的な MQ ミドルウェアには、ActiveMQ、RabbitMQ、RocketMQ、Kafka などが含まれます。

メッセージキューを使用する 2 つの利点

(1) 分離により、
同じインターフェースの制約に従っている限り、両側の処理を独立して拡張または変更できます。

(2) 回復性
システムの一部に障害が発生しても、システム全体には影響しません。メッセージ キューによりプロセス間の結合が軽減されるため、メッセージを処理するプロセスがハングアップした場合でも、キューに追加されたメッセージはシステムの回復後に引き続き処理できます。

(3) バッファリングは、
システムを通過するデータ フローの速度を制御および最適化し、生成メッセージと消費メッセージの処理速度の不一致を解決するのに役立ちます。

(4) 柔軟性とピーク処理能力
トラフィックが急激に増加した場合でも、アプリケーションは機能し続ける必要がありますが、そのようなバースト トラフィックは一般的ではありません。このようなピークアクセスに対処するためにリソースを常にスタンバイ状態に投資するのは、間違いなく多大な無駄です。メッセージ キューを使用すると、主要コンポーネントが突然の過負荷要求によって完全にクラッシュすることなく、突然のアクセス圧力に耐えることができます。

(5) 非同期通信
多くの場合、ユーザーはメッセージをすぐに処理したくない、またはその必要がありません。メッセージ キューは、ユーザーがメッセージをすぐに処理せずにキューに入れることができる非同期処理メカニズムを提供します。必要なだけメッセージをキューに入れ、必要に応じて処理します。

//メッセージ キューの 2 つのモード
(1) ポイントツーポイント モード (1 対 1、コンシューマがアクティブにデータをプルし、メッセージが受信されるとメッセージがクリアされる) メッセージ プロデューサーがメッセージ キューにメッセージを送信し、次にメッセージ コンシューマーがメッセージを送信します
。メッセージキューからメッセージを送信する メッセージを取り出して消費します。メッセージが消費されると、メッセージ キューにはそれ以上のストレージがなくなるため、メッセージ コンシューマは、すでに消費されたメッセージを消費することはできません。メッセージ キューは複数のコンシューマをサポートしますが、メッセージの場合、それを消費できるのは 1 つのコンシューマのみです。

(2) パブリッシュ/サブスクライブ モード (1 対多、オブザーバー モードとも呼ばれ、コンシューマがデータを消費した後、メッセージはクリアされません) メッセージ プロデューサー (パブリッシュ) がメッセージをトピックにパブリッシュします
。メッセージ コンシューマ (subscribe ) を使用してメッセージを消費します。ピアツーピア方式とは異なり、トピックにパブリッシュされたメッセージはすべてのサブスクライバーによって消費されます。
パブリッシュ/サブスクライブ モードでは、オブジェクト間の 1 対多の依存関係が定義されるため、オブジェクト (ターゲット オブジェクト) の状態が変化するたびに、それに依存するすべてのオブジェクト (オブザーバー オブジェクト) が通知され、自動的に更新されます。

Kafka の 3 つの定義

Kafka は、分散パブリッシュ/サブスクライブ ベースのメッセージ キュー (MQ、メッセージ キュー) であり、主にビッグ データのリアルタイム処理の分野で使用されます。

3.1 Kafka の概要

Kafka はもともと Linkedin によって開発されました. Zookeeper 連携に基づいた、パーティションをサポートするレプリカベースの分散メッセージ ミドルウェア システムです. その最大の特徴は、大量のデータをリアルタイムに処理できることです. さまざまな需要シナリオに対応するために、 Hadoop ベースのバッチ処理システム、低遅延リアルタイム システム、Spark/Flink ストリーミング処理エンジン、nginx アクセス ログ、メッセージ サービスなど、scala 言語で書かれたシステムに、Linkedin が 2010 年に貢献し、Apache Foundation となりました
。トップのオープンソースプロジェクト。

3.2 Kafkaの特徴

●高スループット、低遅延
Kafka は 1 秒あたり数十万のメッセージを処理でき、最小遅延はわずか数ミリ秒です。各トピックは複数のパーティションに分割でき、コンシューマ グループはパーティション上で消費操作を実行して、負荷分散と消費機能を向上させます。

●スケーラビリティ
Kafka クラスターはホット拡張をサポートします

●永続性と信頼性
メッセージはローカルディスクに永続化され、データ損失を防ぐためのデータバックアップもサポートされています。

●フォールトトレランスにより、
クラスタ内のノードの障害が許容されます（複数コピーの場合、コピー数がnの場合、n-1ノードの障害が許容されます）。

●高い同時実行性
数千のクライアントの同時読み取りと書き込みをサポートします。

3.3 Kafka システムアーキテクチャ

(1) ブローカー
kafka サーバーはブローカーです。クラスターは複数のブローカーで構成されます。ブローカーは複数のトピックに対応できます。

(2) トピックは
キューとして理解でき、プロデューサーとコンシューマーの両方が同じトピックに直面します。
データベースのテーブル名や ES のインデックスと同様に、
異なるトピックのメッセージは個別に保存されます。

(3) パーティション
スケーラビリティを実現するために、非常に大きなトピックを複数のブローカー (つまりサーバー) に分散でき、トピックを 1 つ以上のパーティションに分割でき、各パーティションは順序付きキューになります。Kafka は、パーティション内のレコードが順序どおりであることのみを保証しますが、トピック内の異なるパーティションの順序は保証しません。

各トピックには少なくとも 1 つのパーティションがあり、プロデューサはデータを生成するときに、割り当て戦略に従ってパーティションを選択し、指定されたパーティションのキューの最後にメッセージを追加します。

3.4 パーティションデータのルーティングルール

1. パーティションが指定されている場合は、それを直接使用します。
2. パーティションが指定されていないが、キー (メッセージ内の属性に相当) が指定されている場合、キーの値に対してハッシュ モジュロを実行することによってパーティションが選択されます
。パーティションとキーの両方が指定されておらず、パーティションはポーリングによって選択されます。

各メッセージには、メッセージのオフセットを識別するために使用される自己増加する番号があり、識別シーケンスは 0 から始まります。

各パーティションのデータは、複数のセグメント ファイルを使用して保存されます。

トピックに複数のパーティションがある場合、データを使用するときにデータの順序は保証されません。メッセージの消費順序が厳密に保証されているシナリオ (商品のフラッシュセールや赤い封筒の入手など) では、パーティションの数を 1 に設定する必要があります。

●brokerはトピックデータを保管します。トピックに N 個のパーティションがあり、クラスターに N 個のブローカーがある場合、各ブローカーはトピックのパーティションを保存します。
●トピックに N 個のパーティションがあり、クラスターに (N+M) 個のブローカーがある場合、トピックのパーティションを保存する N 個のブローカーがあり、残りの M 個のブローカーはトピックのパーティション データを保存しません。
● トピックに N 個のパーティションがあり、クラスター内のブローカーの数が N 未満の場合、1 つのブローカーがトピックの 1 つ以上のパーティションを保存します。実際の運用環境では、Kafka クラスター内のデータの不均衡を容易に引き起こす可能性があるこの状況を避けるようにしてください。

//パーティションの理由
●クラスタ内で拡張すると便利 各パーティションは配置されているマシンに合わせて調整でき、トピックは複数のパーティションで構成できるため、クラスタ全体がデータに適応できます任意のサイズ; ●
はい パーティション単位で読み書きできるため、同時実行性が向上します。

(4) レプリカ
コピー: クラスター内のノードに障害が発生した場合でも、ノード上のパーティション データが失われず、Kafka が引き続き動作できるようにするために、Kafka はコピー メカニズムを提供します。数人のレプリカ、リーダー、そして数人のフォロワー。

(5)
リーダーの各パーティションには複数のコピーがあり、そのうちの 1 つだけがリーダーであり、リーダーは現在データの読み取りと書き込みを担当します。

(6) フォロワー
フォロワーはリーダーに従い、すべての書き込みリクエストはリーダーを通じてルーティングされ、データの変更はすべてのフォロワーにブロードキャストされ、フォロワーとリーダーはデータの同期を維持します。Follower はバックアップのみを担当し、データの読み取りと書き込みは担当しません。
リーダーが失敗した場合は、フォロワーの中から新しいリーダーが選出されます。
フォロワーがハングしたり、スタックしたり、同期が遅すぎたりすると、リーダーは ISR (リーダーによって管理され、リーダーと同期された一連のフォロワー) リストからフォロワーを削除し、新しいフォロワーを作成します。

(7)
プロデューサーはデータの発行者であり、この役割はメッセージ プッシュを Kafka のトピックに発行します。
ブローカーは、プロデューサによって送信されたメッセージを受信した後、データの追加に現在使用されているセグメント ファイルにメッセージを追加します。
プロデューサによって送信されたメッセージはパーティションに保存され、プロデューサはデータ ストレージのパーティションを指定することもできます。

(8) 消費者は
ブローカーからデータをプルできます。コンシューマは複数のトピックからのデータを利用できます。

(9) 消費者グループ（CG）
消費者グループは複数の消費者から構成されます。
すべてのコンシューマはコンシューマ グループに属します。つまり、コンシューマ グループは論理サブスクライバです。コンシューマごとにグループ名を指定できます。グループ名が指定されていない場合は、デフォルトのグループに属します。
複数のコンシューマーを集めて特定のトピックのデータを処理すると、データの消費容量をより速く向上させることができます。
コンシューマ グループ内の各コンシューマは、異なるパーティションからのデータを消費する責任があります。データが繰り返し読み取られるのを防ぐため、パーティションはグループ内の 1 人のコンシューマによってのみ消費されます。
消費者団体は相互に影響を与えません。

(10) offset は
メッセージを一意に識別できます。
オフセットによって読み取られるデータの位置が決まり、スレッドの安全性の問題は発生しません。コンシューマーはオフセットを使用して、次回読み取るメッセージ (つまり、消費場所) を決定します。
メッセージは消費された後、すぐには削除されないため、複数の企業が Kafka メッセージを再利用できます。
特定のサービスでは、ユーザーが制御するオフセットを変更することで、メッセージを再読み取りするという目的を達成することもできます。
メッセージは最終的に削除され、デフォルトのライフサイクルは 1 週間 (7*24 時間) です。

(11) Zookeeper
Kafka は Zookeeper を使用してクラスターのメタ情報を保存します。

消費者は消費過程で停電やダウンタイムなどの障害が発生する可能性があるため、回復後は障害発生前の場所から消費を継続する必要があるため、消費者はどのオフセットを消費したかをリアルタイムで記録する必要があります。障害が回復した後も消費を継続できるようにします。
Kafka バージョン 0.9 より前では、コンシューマはデフォルトでオフセットを Zookeeper に保存していましたが、バージョン 0.9 以降では、コンシューマはデフォルトでオフセットを組み込みの Kafka トピック (__consumer_offsets) に保存しました。

つまり、Zookeeper の役割は、プロデューサーがデータを Kafka クラスターにプッシュするときに、Kafka クラスターのノードがどこにあるかを見つける必要があることです。これらはすべて Zookeeper を通じて見つけられます。消費者がどのデータを消費するかについても、Zookeeper のサポートが必要です。オフセットは Zookeeper から取得され、最後に消費されたデータがどこで消費されたかを記録するため、次のデータを次に消費できるようになります。

4 つのカフカ アーキテクチャ

我自己总结的：几个kafka就有几个broker（代理），生产者（producer）生产数据到主题（topic）中，一个topic由多个partition（分区）组成，一个partition由多个replica（副本）组成，而一个replica由1个leader（领导者）和多个followers（追随者）组成，leader只负责数据的读取，而followers只负责数据的复制，consumer（消费者）从topic里面调取数据来消费。

ファイブビルドカフカ

5.1 環境の準備

基于 之前zookeeper三台机子上操作安装kafka
192.168.10.40   zookeeper   +  kafka
192.168.10.50   zookeeper   +  kafka
192.168.10.60   zookeeper   +  kafka

5.2 Kafkaのインストール

cd /opt/
tar zxvf kafka_2.13-2.7.1.tgz                 #解压
mv kafka_2.13-2.7.1 /usr/local/kafka          #移动改名

wget https://mirrors.tuna.tsinghua.edu.cn/apache/kafka/2.7.1/kafka_2.13-2.7.1.tgz #官方下载安装包

5.3 設定ファイルの変更

cd /usr/local/kafka/config/
cp server.properties{
    
    ,.bak}             #备份

vim server.properties
broker.id=0                   #21行，broker的全局唯一编号，每个broker不能重复，因此要在其他机器上配置 broker.id=1、broker.id=2
listeners=PLAINTEXT://192.168.10.40:9092    #31行，指定监听的IP和端口，如果修改每个broker的IP需区分开来，也可保持默认配置不用修改
num.network.threads=3           #42行，broker 处理网络请求的线程数量，一般情况下不需要去修改
num.io.threads=8                #45行，用来处理磁盘IO的线程数量，数值应该大于硬盘数
socket.send.buffer.bytes=102400       #48行，发送套接字的缓冲区大小
socket.receive.buffer.bytes=102400    #51行，接收套接字的缓冲区大小
socket.request.max.bytes=104857600    #54行，请求套接字的缓冲区大小
log.dirs=/usr/local/kafka/logs        #60行，kafka运行日志存放的路径，也是数据存放的路径
num.partitions=1    #65行，topic在当前broker上的默认分区个数，会被topic创建时的指定参数覆盖
num.recovery.threads.per.data.dir=1    #69行，用来恢复和清理data下数据的线程数量
log.retention.hours=168    #103行，segment文件（数据文件）保留的最长时间，单位为小时，默认为7天，超时将被删除
log.segment.bytes=1073741824    #110行，一个segment文件最大的大小，默认为 1G，超出将新建一个新的segment文件
zookeeper.connect=192.168.10.40:2181,192.168.10.50:2181,192.168.10.60:2181    #123行，配置连接Zookeeper集群地址

  只需修改31行  60行 123行

5.4 他の 2 つの仮想マシンの構成ファイルを編集する

scp -r /usr/local/kafka/ 192.168.10.50:/usr/local/
scp -r /usr/local/kafka/ 192.168.10.60:/usr/local/
vim /usr/local/kafka/config/server.properties
修改21行和31行
broker.id=
listeners=

5.5 3 台のマシンの環境変数を編集する

vim /etc/profile
export KAFKA_HOME=/usr/local/kafka
export PATH=$PATH:$KAFKA_HOME/bin

source /etc/profile

5.6 Zookeeper 起動スクリプトの構成

三台虚拟机同时进行
vim /etc/init.d/kafka

#!/bin/bash
#chkconfig:2345 22 88
#description:Kafka Service Control Script
KAFKA_HOME='/usr/local/kafka'
case $1 in
start)
	echo "---------- Kafka 启动 ------------"
	${KAFKA_HOME}/bin/kafka-server-start.sh -daemon ${KAFKA_HOME}/config/server.properties
;;
stop)
	echo "---------- Kafka 停止 ------------"
	${KAFKA_HOME}/bin/kafka-server-stop.sh
;;
restart)
	$0 stop
	$0 start
;;
status)
	echo "---------- Kafka 状态 ------------"
	count=$(ps -ef | grep kafka | egrep -cv "grep|$$")
	if [ "$count" -eq 0 ];then
        echo "kafka is not running"
    else
        echo "kafka is running"
    fi
;;
*)
    echo "Usage: $0 {start|stop|restart|status}"
esac

chmod +x /etc/init.d/kafka
chkconfig --add kafka

5.7 Kafka テストの開始

service kafka start


定义 
--zookeeper 集群服务器地址，如果有多个 IP 地址使用逗号分割，一般使用一个 IP 即可
--replication-factor：定义分区副本数，1 代表单副本，建议为 2 
--partitions：定义分区数 
--topic：定义 topic 名称

任何一台机子创建topic
kafka-topics.sh --create --zookeeper 192.168.10.40:2181,192.168.10.50:2181,192.168.10.60:2181 --replication-factor 2 --partitions 3 --topic test

查看当前服务器中的所有 topic
kafka-topics.sh --list --zookeeper 192.168.10.40:2181,192.168.10.50:2181,192.168.10.60:2181

查看某个 topic 的详情
kafka-topics.sh  --describe --zookeeper 192.168.10.40:2181,192.168.10.50:2181,192.168.10.60:2181

192.168.10.40发布消息
kafka-console-producer.sh --broker-list 192.168.10.40:9092,192.168.10.50:9092,192.168.10.60:9092  --topic test
192.168.10.50消费消息
kafka-console-consumer.sh --bootstrap-server 192.168.10.40:9092,192.168.10.50:9092,192.168.10.60:9092 --topic test --from-beginning

修改分区数
kafka-topics.sh --zookeeper 192.168.10.40:2181,192.168.10.50:2181,192.168.10.60:2181 --alter --topic test --partitions 6

删除 topic
kafka-topics.sh --delete --zookeeper 192.168.10.40:2181,192.168.10.50:2181,192.168.10.60:2181 --topic test