怎么做王者荣耀网站,长沙品牌网站制作服务报价,ＰＰＴ做的好的有哪些网站,建行手机app下载文章目录 一、实验目的二、实验要求三、实验原理#xff08;一#xff09;Kafka简介#xff08;二#xff09;Kafka使用场景 四、实验环境五、实验内容和步骤#xff08;一#xff09;配置各服务器之间的免密登录#xff08;二#xff09;安装ZooKeeper集群#xff08… 文章目录 一、实验目的二、实验要求三、实验原理一Kafka简介二Kafka使用场景 四、实验环境五、实验内容和步骤一配置各服务器之间的免密登录二安装ZooKeeper集群三安装Kafka集群四验证消息推送 六、实验结果七、实验心得 一、实验目的
掌握Kafka的安装部署掌握Kafka的topic创建及如何生成消息和消费消息掌握Kafka和Zookeeper之间的关系了解Kafka如何保存数据及加深对Kafka相关概念的理解
二、实验要求
在两台机器上(以slave1slave2为例)分别部署一个brokerZookeeper使用的是单独的集群然后创建一个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等其他系统化的存储和分析系统。
四、实验环境
云创大数据实验平台 Java 版本jdk1.7.0_79Hadoop 版本hadoop-2.7.1ZooKeeper 版本zookeeper-3.4.6Kafka 版本kafka_2.10-0.9.0.1
五、实验内容和步骤
一配置各服务器之间的免密登录
首先配置masterslave1和slave2之间的免密登录和各虚拟机的/etc/hosts文件具体步骤参考【大数据技术基础 | 实验一】配置SSH免密登录
二安装ZooKeeper集群
配置完免密登录之后我们还需要安装Zookeeper集群具体步骤参考【大数据技术基础 | 实验五】ZooKeeper实验部署ZooKeeper
三安装Kafka集群
首先我们将Kafka安装包解压到slave1的/usr/cstor目录
tar -zxvf kafka_2.10-0.9.0.1.tar.gz -c /usr/cstor并将kafka目录所属用户改成root:root
chown -R root:root /usr/cstor/kafka然后将kafka目录传到其他机器上
scp -r /usr/cstor/kafka hadoopslave2:/usr/cstor两台机器上分别进入解压目录下在config目录修改server.properties文件:
cd /usr/cstor/kafka/config/
vim server.properties然后修改其中的内容首先是slave1配置
#broker.id
broker.id1
#broker.port
port9092
#host.name
host.nameslave1
#本地日志文件位置
log.dirs/usr/cstor/kafka/logs
#Zookeeper地址
zookeeper.connectslave1:2181,slave2:2181,master:2181然后修改slave2的配置
#broker.id
broker.id2
#broker.port
port9092
#host.name
host.nameslave2
#本地日志文件位置
log.dirs/usr/cstor/kafka/logs
#Zookeeper地址
zookeeper.connectslave1:2181,slave2:2181,master:2181然后启动Kafka并验证Kafka功能进入安装目录下的bin目录两台机器上分别执行以下命令启动各自的Kafka服务
cd /usr/cstor/kafka/bin
nohup ./kafka-server-start.sh ../config/server.properties 在任意一台机器上执行以下命令(以下三行命令不要换行是一整行)创建topic
./kafka-topics.sh --create \
--zookeeper slave1:2181,slave2:2181,master:2181 \
--replication-factor 2 --partitions 2 --topic test在任意一台机器上这里我选择的是slave1执行以下命令(以下三行命令不要换行是一整行)启动模拟producer
./kafka-console-producer.sh \
--broker-list slave1:9092,slave2:9092,master:9092 \
--topic test在另一台机器上slave2执行以下命令(以下三行命令不要换行是一整行)启动模拟consumer
./kafka-console-consumer.sh \
--zookeeper slave1:2181,slave2:2181,master:2181 \
--topic test --from-beginning四验证消息推送
我们在producer端输入任意信息然后观察consumer端接收到的数据
This is Kafka producer
Hello, Kafka在slave1上输入信息 然后slave2上也收到了信息 六、实验结果
我们在producer端输入任意信息然后观察consumer端接收到的数据
This is Kafka producer
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
