ToB企服应用市场:ToB评测及商务社交产业平台

标题: 【大数据技能基础 | 实验十四】Kafka实验：订阅推送示例 [打印本页]
作者: 欢乐狗    时间: 2024-12-4 14:39
标题: 【大数据技能基础 | 实验十四】Kafka实验：订阅推送示例


  
一、实验目标

二、实验要求

在两台机器上(以slave1，slave2为例)，分别部署一个broker，Zookeeper利用的是单独的集群，然后创建一个topic，启动模仿的生产者和消费者脚本，在生产者端向topic里写数据，在消费者端观察读取到的数据。
三、实验原理

（一）Kafka简介

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。它提供了类似于JMS的特性，但是在设计实现上完全不同，别的它并不是JMS规范的实现。kafka对消息保存时根据Topic进行归类，发送消息者成为Producer，消息接受者成为Consumer，别的kafka集群有多个kafka实例构成，每个实例(server)成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。如图下所示：

一个Topic的多个partitions，被分布在kafka集群中的多个server上；每个server(kafka实例)负责partitions中消息的读写操作；别的kafka还可以配置partitions必要备份的个数(replicas)，每个partition将会被备份到多台机器上，以提高可用性。
基于replicated方案，那么就意味着必要对多个备份进行调度；每个partition都有一个server为“leader”；leader负责所有的读写操作，假如leader失效，那么将会有其他follower来接管(成为新的leader)；follower只是单调的和leader跟进，同步消息即可……由此可见作为leader的server承载了全部的哀求压力，因此从集群的团体考虑，有多少个partitions就意味着有多少个“leader”，kafka会将“leader”均衡的分散在每个实例上，来确保团体的性能稳固。
生产者：Producer将消息发布到指定的Topic中，同时Producer也能决定将此消息归属于哪个partition；好比基于“round-robin”方式或者通过其他的一些算法等。
消费者：本质上kafka只支持Topic，每个consumer属于一个consumer group；反过来说，每个group中可以有多个consumer。发送到Topic的消息，只会被订阅此Topic的每个group中的一个consumer消费。
假如所有的consumer都具有相同的group，这种情况和queue模式很像；消息将会在consumers之间负载均衡。
假如所有的consumer都具有不同的group，那这就是“发布-订阅”；消息将会广播给所有的消费者。
在kafka中，一个partition中的消息只会被group中的一个consumer消费；每个group中consumer消息消费相互独立；我们可以以为一个group是一个“订阅”者，一个Topic中的每个partions，只会被一个“订阅者”中的一个consumer消费，不外一个consumer可以消费多个partitions中的消息。kafka只能保证一个partition中的消息被某个consumer消费时，消息是次序的。究竟上，从Topic角度来说，消息仍不是有序的。
kafka的设计原理决定，对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。
Guarantees
（1）发送到partitions中的消息将会按照它接收的次序追加到日记中。
（2）对于消费者而言，它们消费消息的次序和日记中消息次序同等。
（3）假如Topic的“replicationfactor”为N，那么允许N-1个kafka实例失效。
（二）Kafka利用场景

1. Messaging
对于一些通例的消息系统，kafka是个不错的选择；partitons/replication和容错，可以使kafka具有良好的扩展性和性能优势。不外到目前为止，我们应该很清楚认识到，kafka并没有提供JMS中的“事件性”、“消息传输包管(消息确认机制)”、“消息分组”等企业级特性；kafka只能利用作为“通例”的消息系统，在肯定程度上，尚未确保消息的发送与接收绝对可靠(好比：消息重发，消息发送丢失等)。
2. Websit activity tracking
kafka可以作为“网站活性跟踪”的最佳工具；可以将网页/用户操作等信息发送到kafka中。并实时监控,或者离线统计分析等。
3. Log Aggregation
kafka的特性决定它非常适相助为“日记收会合心”，application可以将操作日记“批量”“异步”的发送到kafka集群中，而不是保存在当地或者DB中；kafka可以批量提交消息/压缩消息等，这对producer端而言，险些感觉不到性能的开支。此时consumer端可以使hadoop等其他系统化的存储和分析系统。
四、实验情况


五、实验内容和步骤

（一）配置各服务器之间的免密登录

首先配置master，slave1和slave2之间的免密登录和各虚拟机的/etc/hosts文件，具体步骤参考：【大数据技能基础 | 实验一】配置SSH免密登录
（二）安装ZooKeeper集群

配置完免密登录之后我们还必要安装Zookeeper集群，具体步骤参考：【大数据技能基础 | 实验五】ZooKeeper实验：部署ZooKeeper
（三）安装Kafka集群

首先我们将Kafka安装包解压到slave1的/usr/cstor目次：
  1. tar -zxvf kafka_2.10-0.9.0.1.tar.gz -c /usr/cstor
复制代码
并将kafka目次所属用户改成root:root：
  1. chown -R root:root /usr/cstor/kafka
复制代码
然后将kafka目次传到其他机器上：
  1. scp -r /usr/cstor/kafka hadoop@slave2:/usr/cstor
复制代码
两台机器上分别进入解压目次下，在config目次修改server.properties文件:
  1. cd /usr/cstor/kafka/config/
  2. vim server.properties
复制代码
然后修改此中的内容，首先是slave1配置：
  1. #broker.id
  2. broker.id=1
  3. #broker.port
  4. port=9092
  5. #host.name
  6. host.name=slave1
  7. #本地日志文件位置
  8. log.dirs=/usr/cstor/kafka/logs
  9. #Zookeeper地址
  10. zookeeper.connect=slave1:2181,slave2:2181,master:2181
复制代码



然后修改slave2的配置：
  1. #broker.id
  2. broker.id=2
  3. #broker.port
  4. port=9092
  5. #host.name
  6. host.name=slave2
  7. #本地日志文件位置
  8. log.dirs=/usr/cstor/kafka/logs
  9. #Zookeeper地址
  10. zookeeper.connect=slave1:2181,slave2:2181,master:2181
复制代码



然后，启动Kafka，并验证Kafka功能，进入安装目次下的bin目次，两台机器上分别执行以下下令启动各自的Kafka服务：
  1. cd /usr/cstor/kafka/bin
  2. nohup ./kafka-server-start.sh ../config/server.properties &
复制代码
在恣意一台机器上，执行以下下令(以下三行下令不要换行，是一整行)创建topic：
  1. ./kafka-topics.sh --create \
  2. --zookeeper slave1:2181,slave2:2181,master:2181 \
  3. --replication-factor 2 --partitions 2 --topic test
复制代码

在恣意一台机器上（这里我选择的是slave1），执行以下下令(以下三行下令不要换行，是一整行)启动模仿producer：
  1. ./kafka-console-producer.sh \
  2. --broker-list slave1:9092,slave2:9092,master:9092 \
  3. --topic test
复制代码
在另一台机器上（slave2），执行以下下令(以下三行下令不要换行，是一整行)启动模仿consumer：
  1. ./kafka-console-consumer.sh \
  2. --zookeeper slave1:2181,slave2:2181,master:2181 \
  3. --topic test --from-beginning
复制代码
（四）验证消息推送

我们在producer端输入恣意信息，然后观察consumer端接收到的数据：
  1. This is Kafka producer
  2. Hello, Kafka
复制代码
在slave1上输入信息：

然后slave2上也收到了信息：

六、实验结果

我们在producer端输入恣意信息，然后观察consumer端接收到的数据：
  1. This is Kafka producer
  2. Hello, Kafka
复制代码
在slave1上输入信息：

然后slave2上也收到了信息：

七、实验心得

  通过本次Kafka实验，我深入明白了分布式消息队列的核心概念及实在现方式。Kafka作为一种高吞吐量、低耽误的分布式发布订阅消息系统，其设计头脑和实现细节让我受益匪浅。实验从Kafka与Zookeeper的安装部署入手，通过配置两个broker的Kafka集群，资助我掌握了Kafka集群的根本搭建过程。同时，通过配置文件的修改，我更加清楚地认识到Kafka集群中broker.id、zookeeper.connect、log.dirs等配置项的作用，为后续的生产情况部署打下了基础。
  实验中的生产者和消费者模仿验证让我直观地感受到了Kafka的高效数据处理能力。在生产者端输入消息后，消费者端能够实时接收到消息，这充实展示了Kafka在消息传递中的低耽误特点。别的，通过创建带有多个分区和副本的Topic，我明白了Kafka的分区机制及其在分布式情况中保证数据高可用性的策略。分区的Leader和Follower模子也让我领会到Kafka在负载均衡和容错性上的精良设计，尤其是当Leader失效后，Follower能够及时接管，确保服务的稳固运行。
  与此同时，我也意识到Kafka在现实应用中并非完美。例如，Kafka虽然具有肯定的容错能力，但对于数据的绝对可靠性保证（如消息丢失或重复发送）还有肯定的局限性。这让我认识到，在现实项目中，需根据具体场景搭配其他机制来保证消息传递的可靠性和同等性。
  总之，本次实验资助我从理论走向实践，不仅认识了Kafka的根本操作，还加深了对其内部工作原理的明白。在未来的学习和工作中，我希望能够进一步探索Kafka在日记收集、实时数据流处理等场景中的深度应用，为分布式系统的设计与优化积累更多经验。
   附：以上文中的数据文件及相干资源下载地点：
链接：https://pan.quark.cn/s/8f386ae8b871
提取码：EPKB

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4