非常に詳細な Zookeeper+Kafka+ELK クラスターのデプロイメント

1. 飼育員の概要

1. 飼育員の定義

Zookeeper は、分散フレームワークの調整サービスを提供するオープンソースの分散 Apache プロジェクトです。

2. 飼育員の働きの仕組み

Zookeeper をデザインパターンの観点から理解すると、オブザーバーパターンに基づいて設計された分散サービス管理フレームワークであり、誰もが関心を持つデータの保存と管理を担当し、オブザーバーの登録を受け付けます。データが変更された場合、Zookeeper は、Zookeeper に登録されている観察者に、それに応じて対応するよう通知する責任があります。つまり、Zookeeper = ファイルシステム + 通知メカニズムです。

3. Zookeeper の機能

(1) 動物園の飼育員: リーダーと信者の集団。

(2) Zookeeper クラスター内のノードの半分以上が存続している限り、Zookeeper クラスターは正常に機能します。したがって、Zookeeper は奇数のサーバーをインストールするのに適しています。

(3) グローバルデータの一貫性: 各サーバーは同じデータのコピーを保存するため、クライアントがどのサーバーに接続しても、データは一貫しています。

(4) 更新要求は順次実行されます。同じクライアントからの更新要求は、送信された順に、つまり先入れ先出しで順次実行されます。

(5) データ更新のアトミック性。データ更新は成功するか失敗します。

(6) リアルタイムで、一定の時間範囲内で、クライアントは最新のデータを読み取ることができます。

4. Zookeeperのデータ構造

ZooKeeper データモデルの構造は Linux ファイルシステムに非常に似ており、全体としてツリーとみなすことができ、各ノードは ZNode と呼ばれます。各 ZNode はデフォルトで 1MB のデータを保存でき、各 ZNode はパスによって一意に識別できます。

5. Zookeeper のアプリケーションシナリオ

提供されるサービスには、統合ネーミングサービス、統合構成管理、統合クラスター管理、動的なオンラインおよびオフラインサーバーノード、ソフトロードバランシングなどが含まれます。

●統一ネーミングサービス

分散環境では、多くの場合、識別しやすいようにアプリケーション/サービスに統一した名前を付ける必要があります。例: IP は覚えにくいですが、ドメイン名は覚えやすいです。

●一元的な構成管理

(1) 分散環境では、構成ファイルの同期が非常に一般的です。一般に、Kafka クラスターなど、クラスター内のすべてのノードの構成情報が一貫している必要があります。構成ファイルを変更した後、各ノードに迅速に同期できることを願っています。

(2) ZooKeeperによる構成管理が可能です。構成情報は、ZooKeeper 上の Znode に書き込むことができます。各クライアントサーバーはこの Znode をリッスンします。Znode 内のデータが変更されると、ZooKeeper は各クライアントサーバーに通知します。

●クラスタの一元管理

(1) 分散環境では、各ノードの状態をリアルタイムに把握する必要があります。ノードのリアルタイムのステータスに基づいて一部の調整を行うことができます。

(2) ZooKeeper はノードの状態変化をリアルタイムに監視できます。ZooKeeper 上の ZNode にノード情報を書き込むことができます。この ZNode を監視して、リアルタイムのステータス変化を取得します。

●サーバーはオンラインとオフラインで動的に動作します

クライアントは、サーバーのオンラインおよびオフラインの変更をリアルタイムで把握できます。

●ソフトロードバランシング

Zookeeper の各サーバーへのアクセス数を記録し、アクセス数が最も少ないサーバーに最新のクライアントリクエストを処理させます。

6. 飼育員の選出メカニズム

●選挙メカニズムを初めて開始する

(1) サーバー 1 が起動し、選挙が開始されます。サーバー 1 が投票を行います。この時点で、サーバー 1 は 1 票を持っていますが、過半数 (3 票) には足りず、選挙を完了できず、サーバー 1 のステータスは LOOKING のままです。

(2) サーバー 2 が起動し、別の選挙が開始されます。サーバー 1 とサーバー 2 はそれぞれ自分に投票し、投票情報を交換します。このとき、サーバー 1 は、サーバー 2 の myid が現在投票している myid (サーバー 1) よりも大きいことに気づき、投票をサーバー 2 を推奨するように変更します。この時点では、サーバー 1 が 0 票、サーバー 2 が 2 票で半分以下の結果となっており、選挙は完了せず、サーバー 1 とサーバー 2 のステータスは LOOKING のままです。

(3) サーバー 3 が起動し、選挙が開始されます。この時点で、サーバー 1 とサーバー 2 の両方が投票をサーバー 3 に変更します。この投票の結果: サーバー 1 は 0 票、サーバー 2 は 0 票、サーバー 3 は 3 票です。この時点で、サーバー 3 が過半数の票を獲得しており、サーバー 3 がリーダーに選出されます。サーバー 1 と 2 はステータスを FOLLOWING に変更し、サーバー 3 はステータスを LEADING に変更します。

(4) サーバー 4 が起動し、選挙が開始されます。この時点では、サーバー 1、2、および 3 は LOOKING 状態ではないため、投票情報は変更されません。投票情報を交換した結果：サーバー 3 が 3 票、サーバー 4 が 1 票です。このとき、サーバー 4 は多数決に従い、投票情報をサーバー 3 に変更し、ステータスを FOLLOWING に変更します。

(5) サーバー 5 が起動し、サーバー 4 と同様に弟として動作します。

●選挙の仕組みを始めるのは今回が初めてではない

(1) ZooKeeper クラスター内のサーバーが次の 2 つの状況のいずれかに遭遇すると、リーダーの選出が開始されます。

1) サーバーの初期化が開始されます。

2) サーバーは、実行中はリーダーとの接続を維持できません。

(2) マシンがリーダー選出プロセスに入ると、現在のクラスターは次の 2 つの状態になる場合もあります。

1) クラスター内にすでにリーダーが存在します。

すでにリーダーが存在する場合、マシンがリーダーを選出しようとすると、現在のサーバーのリーダー情報が通知されるため、このマシンではリーダーマシンとの接続を確立してステータスを同期するだけで済みます。

2) 確かにクラスター内にリーダーは存在しません。

ZooKeeper は、SID 1、2、3、4、および 5、および ZXID 8、8、8、7、および 7 を持つ 5 つのサーバーで構成されており、SID 3 のサーバーがリーダーであると仮定します。ある時点でサーバー 3 と 5 に障害が発生したため、リーダーの選出が始まりました。

リーダー選出ルール:

1. より大きな EPOCH を持つものが直接勝ちます。

2. EPOCH は同じで、トランザクション ID が大きい方が勝ちます。

3. トランザクション ID が同じ場合、サーバー ID が大きい方が優先されます。

-------------------------------------------------- ----------------------------------
SID: サーバー ID。ZooKeeper クラスター内のマシンを一意に識別するために使用されます。各マシンは重複できず、myid と一貫性があります。

ZXID: トランザクション ID。ZXID は、サーバーの状態の変化を識別するために使用されるトランザクション ID です。ある時点では、クラスター内の各マシンの ZXID 値がまったく同じではない可能性がありますが、これは ZooKeeper サーバーがクライアントの「更新リクエスト」を処理する論理速度に関係しています。

エポック: 各リーダー用語のコード名。リーダーが存在しない場合、同じ投票ラウンドの論理クロック値は同じになります。このデータは投票が行われるたびに増加します。

2. Zookeeper クラスターのデプロイ

1. Zookeeper クラスターを展開する手順

Zookeeper クラスター用に 3 台のサーバーを準備する

192.168.229.33
192.168.229.77
192.168.229.99

1.1 インストール前の準備

//ファイアウォールをオフにする

systemctl stop firewalld
systemctl disable firewalld
setenforce 0

//JDKをインストールする

yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel
java -version

//インストールパッケージをダウンロードします。
公式ダウンロードアドレス: /dist/zookeeper のインデックス

cd /opt
wget https://archive.apache.org/dist/zookeeper/zookeeper-3.5.7/apache-zookeeper-3.5.7-bin.tar.gz

1.2. Zookeeper のインストール

cd /opt
tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz
mv apache-zookeeper-3.5.7-bin /usr/local/zookeeper-3.5.7

1.3 設定ファイルの変更

cd /usr/local/zookeeper-3.5.7/conf/
cp zoo_sample.cfg zoo.cfg
 
vim zoo.cfg
tickTime=2000 #通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
initLimit=10 #Leader和Follower初始连接时能容忍的最多心跳数（tickTime的数量），这里表示为10*2s
syncLimit=5 #Leader和Follower之间同步通信的超时时间，这里表示如果超过5*2s，Leader认为Follwer死掉，并从服务器列表中删除Follwer
dataDir=/usr/local/zookeeper-3.5.7/data ●修改，指定保存Zookeeper中的数据的目录，目录需要单独创建
dataLogDir=/usr/local/zookeeper-3.5.7/logs ●添加，指定存放日志的目录，目录需要单独创建
clientPort=2181 #客户端连接端口
#添加集群信息
server.1=192.168.2.33:3188:3288
server.2=192.168.2.77:3188:3288
server.3=192.168.2.99:3188:3288

server.A=B:C:D
●Aはどのサーバ番号であるかを示す数字です。クラスターモードでは、zoo.cfg の dataDir で指定されたディレクトリにファイル myid を作成する必要があります。このファイルには A の値であるデータがあります。Zookeeper は起動時にこのファイルを読み取り、内部のデータを取得します。この情報は、どのサーバーであるかを判断するために比較されます。
●Bはこのサーバーのアドレスです。
●C は、このサーバーのフォロワーがクラスター内のリーダーサーバーと情報を交換するときに使用するポートです。
●D は、クラスター内のリーダーサーバーがハングアップした場合、新しいリーダーを再選出して選択するためにポートが必要になります。このポートは、選出中にサーバーが相互に通信するために使用されるポートです。
-------------------------------------------------- ----------------------------------

1.4 構成済みの Zookeeper 構成ファイルを他のマシンにコピーする

scp /usr/local/zookeeper-3.5.7/conf/zoo.cfg 192.168.229.50:/usr/local/zookeeper-3.5.7/conf/
scp /usr/local/zookeeper-3.5.7/conf/zoo.cfg 192.168.229.40:/usr/local/zookeeper-3.5.7/conf/

1.5 各ノードにデータディレクトリとログディレクトリを作成する

mkdir /usr/local/zookeeper-3.5.7/data
mkdir /usr/local/zookeeper-3.5.7/logs

1.6 各ノードのdataDirで指定したディレクトリにmyidファイルを作成する

echo 1 > /usr/local/zookeeper-3.5.7/data/myid
echo 2 > /usr/local/zookeeper-3.5.7/data/myid
echo 3 > /usr/local/zookeeper-3.5.7/data/myid

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

vim /etc/init.d/zookeeper
#!/bin/bash
#chkconfig:2345 20 90
#description:Zookeeper Service Control Script
ZK_HOME='/usr/local/zookeeper-3.5.7'
case $1 in
start)
echo "---------- zookeeper 启动 ------------"
$ZK_HOME/bin/zkServer.sh start
;;
stop)
echo "---------- zookeeper 停止 ------------"
$ZK_HOME/bin/zkServer.sh stop
;;
restart)
echo "---------- zookeeper 重启 ------------"
$ZK_HOME/bin/zkServer.sh restart
;;
status)
echo "---------- zookeeper 状态 ------------"
$ZK_HOME/bin/zkServer.sh status
;;
*)
echo "Usage: $0 {start|stop|restart|status}"
esac

1.8 起動時の自動起動を設定する

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

1.9 Zookeeper を個別に起動する

service zookeeper start

1.10 現在のステータスを表示する

service zookeeper status

2. インスタンスの操作: Zookeeper クラスターのデプロイ

2.1 インストール前の準備

2.2. Zookeeper のインストール

2.3 設定ファイルの変更

1.4 構成済みの Zookeeper 構成ファイルを他のマシンにコピーする

1.5 各ノードにデータディレクトリとログディレクトリを作成する

1.6 各ノードのdataDirで指定したディレクトリにmyidファイルを作成する

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

1.8 起動時の自動起動を設定してサービスを開始する

1.9 現在のステータスを表示する

リーダーが 1 人、フォロワーが 2 人

3. カフカの概要

1. メッセージキュー (MQ) が必要な理由は何ですか?

主な理由は、同時実行性の高い環境では、同期リクエストが時間内に処理されず、リクエストがブロックされることが多いためです。たとえば、多数のリクエストが同時にデータベースにアクセスすると、行ロックやテーブルロックが発生し、最終的にはリクエストスレッドが蓄積しすぎて接続エラーが発生し、雪崩現象が発生します。

システムへの負担を軽減するために、メッセージキューを使用してリクエストを非同期に処理します。メッセージキューは、非同期処理、トラフィックのピークカット、アプリケーションの切り離し、メッセージ通信などのシナリオでよく使用されます。

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

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

(1) デカップリング

同じインターフェイス制約に従っている限り、両側のプロセスを独立して拡張または変更できます。

(2) 復元性

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

(3) バッファリング

これは、システム内のデータフローの速度を制御および最適化し、プロダクションメッセージとコンシューマメッセージの処理速度が一貫していない問題を解決するのに役立ちます。

(4) 柔軟性とピーク処理能力

トラフィックが急増してもアプリケーションは機能し続ける必要がありますが、このようなトラフィックの急増はまれです。このようなピーク時の訪問に対応できるという基準に基づいて待機することにリソースを投資するのは、非常に無駄です。メッセージキューを使用すると、主要なコンポーネントが突然の過負荷リクエストによって完全に崩壊することなく、突然のアクセス圧力に耐えることができます。

(5) 非同期通信

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

3. メッセージキューの 2 つのモード

(1) ポイントツーポイントモード (1 対 1、コンシューマーが積極的にデータをプルし、メッセージは受信後にクリアされます)

メッセージプロデューサはメッセージを作成してメッセージキューに送信し、メッセージコンシューマはそれをメッセージキューから取り出して消費します。メッセージが消費されると、メッセージキューにストレージがなくなるため、メッセージコンシューマが消費されたメッセージを消費することはできなくなります。メッセージキューは複数のコンシューマの存在をサポートしますが、メッセージの場合、メッセージを消費できるのは 1 つのコンシューマのみです。

(2) パブリッシュ/サブスクライブモード (1 対多、オブザーバーモードとも呼ばれ、コンシューマはデータを消費した後にメッセージをクリアしません)

メッセージプロデューサー (パブリッシャー) がトピックにメッセージをパブリッシュし、複数のメッセージコンシューマー (サブスクリプション) が同時にメッセージを消費します。ポイントツーポイント方式とは異なり、トピックにパブリッシュされたメッセージはすべてのサブスクライバーによって消費されます。

パブリッシュ/サブスクライブパターンは、オブジェクト間の 1 対多の依存関係を定義するため、オブジェクト (ターゲットオブジェクト) の状態が変化するたびに、それに依存するすべてのオブジェクト (オブザーバーオブジェクト) が通知され、自動的に更新されます。

4. カフカの定義

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

5. カフカの紹介

Kafka はもともと Linkedin 社によって開発され、パーティション、複数のレプリカをサポートし、Zookeeper によって調整される分散メッセージミドルウェアシステムです。その最大の特徴は、大量のデータをリアルタイムに処理できることです。さまざまな需要シナリオに対応するために、 Hadoop ベースのバッチ処理システム、低遅延リアルタイムシステム、Spark/Flink ストリーミングエンジン、nginx アクセスログ、メッセージサービスなど、Scala 言語で記述され、

Linkedin は 2010 年に Apache Foundation に寄付され、トップのオープンソースプロジェクトになりました。

6. Kafkaの特徴

●高スループット、低遅延

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

●拡張性

Kafka クラスターはホット拡張をサポートします

●耐久性と信頼性

メッセージはローカルディスクに保存され、データ損失を防ぐためにデータバックアップがサポートされています。

●耐障害性

クラスター内のノード障害を許可します (複数のコピーの場合、コピー数が n の場合、n-1 ノードの障害が許可されます)

●高い同時実行性

数千のクライアントの同時読み取りと書き込みをサポート

7. Kafka システムアーキテクチャ

（1）ブローカー

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

（2）トピックス

これはキューとして理解でき、プロデューサーとコンシューマーの両方が同じトピックを指向します。

データベースのテーブル名やESのインデックスに似ています

物理的に異なるトピックからのメッセージは個別に保存されます。

（3）パーティション

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

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

パーティションデータルーティングルール:

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

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

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

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

●ブローカーはトピックデータを保管します。トピックに N 個のパーティションがあり、クラスターに N 個のブローカーがある場合、各ブローカーはトピックの 1 つのパーティションを保存します。
●トピックに 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) オフセットオフセット

メッセージを一意に識別できます。

オフセットは読み取りデータの位置を決定し、スレッドの安全性の問題は発生しません。コンシューマーはオフセットを使用して、次に読み取るメッセージ (つまり、消費位置) を決定します。

メッセージは消費された後、すぐには削除されないため、複数の企業が Kafka メッセージを再利用できます。

特定の企業は、ユーザーが制御するオフセットを変更することでメッセージを再読み取りすることもできます。

メッセージは最終的に削除され、デフォルトのライフサイクルは 1 週間 (7*24 時間) です。

（11）飼育員

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

消費者は消費過程で停電やその他の障害が発生する可能性があるため、回復後は障害発生前の位置から消費を継続する必要があるため、需要家は消費した電力をリアルタイムに記録し、消費量を相殺する必要がある。障害が復旧した後も消費を続けることができます。

Kafka バージョン 0.9 より前では、コンシューマはデフォルトで Zookeeper にオフセットを保存しますが、バージョン 0.9 以降では、コンシューマはデフォルトで Kafka の組み込みトピック (__consumer_offsets) にオフセットを保存します。

4. Zookeeper + Kafka クラスターをデプロイする

1. Zookeeper + Kafka クラスターをデプロイする

1.1 インストールパッケージをダウンロードする

公式ダウンロードアドレス: Apache Kafka

cd /opt
wget https://mirrors.tuna.tsinghua.edu.cn/apache/kafka/2.7.1/kafka_2.13-2.7.1.tgz

1.2. Kafka のインストール

cd /opt/
tar zxvf kafka_2.13-2.7.1.tgz
mv kafka_2.13-2.7.1 /usr/local/kafka

1.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.2.33: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.2.33:2181,192.168.2.77:2181,192.168.2.99:2181                                   #123行，配置连接Zookeeper集群地址

1.4 環境変数を変更する

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

1.5 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

1.6 起動時の自動起動を設定する

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

1.7 Kafkaを個別に起動する

service kafka start

1.8 Kafka コマンドライン操作

//トピックを作成する

kafka-topics.sh --create --zookeeper 192.168.2.33:2181,192.168.23.77:2181,192.168.2.99:2181 --replication-factor 2 --partitions 3 --topic test
 
-------------------------------------------------------------------------------------
--zookeeper：定义 zookeeper 集群服务器地址，如果有多个 IP 地址使用逗号分割，一般使用一个 IP 即可
--replication-factor：定义分区副本数，1 代表单副本，建议为 2
--partitions：定义分区数
--topic：定义 topic 名称
------------------------------------

// 現在のサーバー内のすべてのトピックを表示します

kafka-topics.sh --list --zookeeper 192.168.2.33:2181,192.168.2.77:2181,192.168.2.99:2181

//トピックの詳細を表示する

kafka-topics.sh --describe --zookeeper 192.168.2.33:2181,192.168.2.77:2181,192.168.2.99:2181

// アナウンスをする

kafka-console-producer.sh --broker-list 192.168.2.33:9092,192.168.2.77:9092,192.168.2.99:9092 --topic test

//メッセージを消費する

kafka-console-consumer.sh --bootstrap-server 192.168.2.33:9092,192.168.2.77:9092,192.168.2.99:9092 --topic test --from-beginning
 
-------------------------------------------------------------------------------------
--from-beginning：会把主题中以往所有的数据都读取出来
-------------------------------------------------------------------------------------

// パーティション数を変更する

kafka-topics.sh --zookeeper 192.168.2.33:2181,192.168.2.77:2181,192.168.2.99:2181 --alter --topic test  --partitions 6

//トピックを削除

kafka-topics.sh --delete --zookeeper 192.168.2.33:2181,192.168.2.77:2181,192.168.2.99:2181 --topic  test

2. インスタンス操作: Zookeeper + Kafka クラスターのデプロイ

1.1 Zookeeper クラスターのインストール

詳細については、このブログの上記の記事を参照して、上記の実験を続行してください (すべてのクラスターサーバーで動作)

1.2 インストールパッケージをダウンロードしてkafkaをインストールする

1.3 設定ファイルの変更

1.4 環境変数を変更する

1.5 Kafka 起動スクリプトを構成し、起動時に自動起動を設定して Kafka を起動する

1.6 Kafka コマンドライン操作

トピックを作成して表示する

メッセージを投稿して読む

パーティションの数を変更する

トピックの削除

5. Filebeat+Kafka+ELK をデプロイする

1. Filebeat+Kafka+ELKを導入する操作手順

1.1. Zookeeper+Kafka クラスターのデプロイ

上記を参照し、続いて上記の実験を行ってください。

1.2. Filebeat のデプロイ

ELK を構築するには、詳細については前のブログを参照してください

cd /usr/local/filebeat
 
vim filebeat.yml
filebeat.prospectors:
- type: log
enabled: true
paths:
- /var/log/messages
- /var/log/*.log
......
#添加输出到 Kafka 的配置
output.kafka:
enabled: true
hosts: ["192.168.2。33:9092","192.168.2.77:9092","192.168.2.99:9092"] #指定 Kafka 集群配置
topic: "filebeat_test" #指定 Kafka 的 topic
 
#启动 filebeat
./filebeat -e -c filebeat.yml

1.3. ELK をデプロイし、Logstash コンポーネントが配置されているノードに新しい Logstash 構成ファイルを作成します。

cd /etc/logstash/conf.d/
 
vim filebeat.conf
input {
kafka {
bootstrap_servers => "192.168.229.60:9092,192.168.229.50:9092,192.168.229.40:9092"
topics => "filebeat_test"
group_id => "test123"
auto_offset_reset => "earliest"
}
}
 
output {
elasticsearch {
hosts => ["192.168.229.70:9200"]
index => "filebeat_test-%{+YYYY.MM.dd}"
}
stdout {
codec => rubydebug
}
}

1.4 ログスタッシュを起動する

logstash -f filebeat.conf

1.5 ブラウザアクセステスト

ブラウザで http://192.168.2.22:5601 にアクセスして Kibana にログインし、「インデックスパターンの作成」ボタンをクリックしてインデックス「filebeat_test-*」を追加し、「作成」ボタンをクリックして作成し、「「Discover」ボタンをクリックすると、チャート情報とログ情報が表示されます。