[カフカ]カフカエントリー決意

A、カフカの概要

[1]カフカプロフィール

カフカは、に基づいて发布/订阅模式主に適用される分散メッセージキュー(Message Queueの)
大きなデータフィールドのリアルタイム処理

メッセージキュー[2]

1)メッセージキューのシナリオ

ここに画像を挿入説明

2)メッセージキューモード

1)点对点模式(一方、アクティブプルデータコンシューマ、明確なメッセージは、メッセージを受信した)
メッセージプロデューサ農産物メッセージにキューに、キューは、メッセージコンシューマと消費者メッセージから除去されます。メッセージが消費された後、消費者が消費されたメッセージへのメッセージを消費することはできませんので、キューストレージは、もはやありません。キューは、複数の消費者をサポートしていますが、メッセージのために、それだけで消費者が消費することができるだろう
ここに画像を挿入説明
2)发布/订阅模式(すべての加入者にプッシュされ、データ作成後、多くの1つ)を
トピックにメッセージをパブリッシュしますニュースプロデューサー(リリース)複数のメッセージを消費者が消費者の(サブスクリプション)の消費がありますが
興味。ポイントやニューストピックを公開するさまざまな方法は、すべての加入者を消費されます
ここに画像を挿入説明

3)メッセージキューアクション

1)デカップリングは、
ちょうど彼らが同じインタフェースの制約に準拠していることを確認してください、あなたが独立して両側にプロセスを拡張または変更することができます

2)リカバリ
システム障害の構成要素の一部は、システム全体に影響を与えません。メッセージキューは、プロセス間の結合低減
ハングメッセージ処理は、メッセージがまだ回収システムの後に処理することができるキューイングされても、処理の順序を

3)バッファ
制御に助けをし、高速処理メッセージメッセージの解決矛盾の生産と消費のために、システムを介したデータの流れの速度を最適化する
場合を

4)柔軟性&ピーク容量
トラフィックの急激な増加の場合、アプリケーションは、役割を果たし続ける必要があるが、これは一般的なバーストトラフィックではありません。
ピークはスタンバイ上のリソースをコミットするために、標準のようなアクセスに対処できるようにする場合には、膨大な無駄になります。メッセージキューは、重要なコンポーネントへのアクセスは、破裂圧力に耐えることができますが、要求のバーストをオーバーロードし、完全に崩壊しないだろう

5)非同期通信
多くの場合、ユーザーが望んでいないにもすぐにメッセージを処理する必要があります。これは、ユーザーができるように、非同期メッセージキューの処理機構を提供して
キューにメッセージを置くが、すぐにそれに対処しません。その後、必要な時にそれらを処理するために行く、ずっと入れてキューに配置されているどのように多くのメッセージだと思います

[3]カフカアーキテクチャ

ここに画像を挿入説明

1)プロデューサー:ニュースのプロデューサー、それはカフカブローカーメッセージングクライアントにあります
2)消費:消費者ニュース、カフカブローカーのクライアントにメッセージを取ります
3)消費者グループ(CG):消費者の複数からなるコンシューマ・グループ、。各グループ内の消費者の異なるパーティションに対する消費者の消費データを担当して、パーティションのみ消費者のグループによって消費することができ、同時に、および消費者グループ。すべての消費者が消費者のグループに属している、すなわち消費者のグループは、論理的な加入者があります
4)ブローカー:カフカサーバーがブローカーです。ブローカーの複数からなるクラスタ。ブローカーはトピックの複数を受け取ることができます
5)トピック:生産者と消費者のための待ち行列がトピックであるとして理解することができます
6)パーティション:スケーラビリティを達成するために、非常に大きなトピックは複数のブローカー(すなわち、サーバ)に分配されてもよい、トピックはパーティションに分割することができ、各パーティションは、順序付けられたキューであります
7)レプリカは:コピー、クラスタノードが保証を失敗した場合、ノード上のパーティションのデータが失われた、と今でも、カフカは、仕組みのコピーをカフカ提供作業を継続することはできませんされ、それぞれのパーティションは、トピックの数を持っていますリーダーとフォロワーの数のコピー
8)リーダー:各「マスター」、生産者がデータオブジェクトだけでなく、消費者支出のデータを送信するパーティション複数のコピーが対象のリーダーです
9)フォロア:データを維持し、同期化のリーダーは、リーダーからのデータのリアルタイムの同期「から」内の各パーティションの複数のコピー。リーダーが失敗すると、フォロワーは新しいフォロワーになります

二、カフカのインストール

[1]のjarパッケージダウンロード

http://kafka.apache.org/downloads.html

[2]インストールパッケージを抽出

tar -zxf kafka_2.11-0.11.0.0.tgz -C /opt/modules/
mv kafka_2.11-0.11.0.0/ kafka

[3]は、ログを作成し、データディレクトリ

mkdir /opt/modules/kafka/logs
mkdir /opt/modules/kafka/logs

[4]構成ファイルを変更します

vim /opt/modules/kafka/config/server.properties

#broker的全局唯一编号,不能重复
broker.id=0
#删除topic功能使能
delete.topic.enable=true
#处理网络请求的线程数量
num.network.threads=3
#用来处理磁盘IO的现成数量
num.io.threads=8
#发送套接字的缓冲区大小
socket.send.buffer.bytes=102400
#接收套接字的缓冲区大小
socket.receive.buffer.bytes=102400
#请求套接字的缓冲区大小
socket.request.max.bytes=104857600
#kafka运行日志存放的路径	
log.dirs=/opt/modules/kafka/data
#topic在当前broker上的分区个数
num.partitions=1
#用来恢复和清理data下数据的线程数量
num.recovery.threads.per.data.dir=1
#segment文件保留的最长时间,超时将被删除
log.retention.hours=168
#配置连接Zookeeper集群地址
zookeeper.connect=node01:2181,node01:2181,node01:2181

[5]分布プロファイル

scp -r /opt/modules/kafka 用户名@主机名:/opt/modules

三、カフカの基本操作

1)查看当前服务器中的所有topic
bin/kafka-topics.sh --zookeeper node01:2181 --list

2)创建topic
bin/kafka-topics.sh --zookeeper node01:2181 --create --replication-factor 3 --partitions 1 --topic first
选项说明:
--topic 定义topic名
--replication-factor  定义副本数
--partitions  定义分区数

3)删除topic
bin/kafka-topics.sh --zookeeper node01:2181 --delete --topic first
注:需要server.properties中设置delete.topic.enable=true否则只是标记删除或者直接重启

4)发送消息
bin/kafka-console-producer.sh --broker-list node01:9092 --topic first

5)消费消息
bin/kafka-console-consumer.sh --bootstrap-server node01:9092 --from-beginning --topic first
选项说明:
--from-beginning:会把first主题中以往所有的数据都读取出来。根据业务场景选择是否增加该配置

6)查看某个Topic的详情
bin/kafka-topics.sh --zookeeper node01:2181 --describe --topic first

四、カフカ生産プロセス分析

継続するには...

公開された70元の記事 ウォンの賞賛305 ビュー210 000 +

おすすめ

転載: blog.csdn.net/qq_43733123/article/details/104906413