消息中间件kafka+zookeeper集群部署、测试与应用

本文涉及的产品
云原生网关 MSE Higress,422元/月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 业务系统中,通常会遇到这些场景:A系统向B系统主动推送一个处理请求;A系统向B系统发送一个业务处理请求,因为某些原因(断电、宕机。。),B业务系统挂机了,A系统发起的请求处理失败;前端应用并发量过大,部分请求丢失或后端业务系统卡死。

业务系统中,通常会遇到这些场景:A系统向B系统主动推送一个处理请求;A系统向B系统发送一个业务处理请求,因为某些原因(断电、宕机。。),B业务系统挂机了,A系统发起的请求处理失败;前端应用并发量过大,部分请求丢失或后端业务系统卡死。。。。这个时候,消息中间件就派上用场了--提升系统稳定性、可用性、可扩展性。

一、消息中间件
消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列,应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。

总体来说,消息中间件有以下作用:降低耦合、流量消峰(防浪涌)、可靠性传输、事件驱动

1.降低耦合:通过发布订阅的方式松耦合
我们以注册业务为例,注册成功会发送短信、邮件给用户来确认,传统架构模型是这样:

邮件业务和短信业务的代码是写在用户注册的流程里,无论是通过接口的方式来实现,还是远程调用的方式来实现,耦合度都很高,现在,新增一个需求,用户注册完成以后不发送邮件了,而是给用户“增加积分”,我们来分析这几种情况:

第一、都在一个业务系统内通过代码堆积、接口调用的方式来实现注册成功后的业务处理,我们需要改动注册代码,上线时需要启停应用,这种方式耦合度最高。

第二、通过远程调用的方式,代码类似如下

当我们要新增业务处理时,如下

还是要改动主流程代码,避免不了启停应用。
如果我们引入消息中间件,如下:

通过发布订阅的方式,用户注册成功后,给消息中间件发送一个消息,各个业务端订阅同一个频道的消息,接收到注册成功的消息后就执行相应业务。新增“增加积分”,就让积分系统相关处理订阅这个消息就够了,不用改动用户业务代码,不用启停应用,就可以实现业务的平滑扩展。

CRM中,这种应用场景有很多,再比如,用户回访业务,回访成功后发短信追评、记录历史工单等等,都可以使用消息中间件来送耦合,实现业务的平滑扩展。

3.流量消峰、防浪涌:消息中间件可以在峰值时堆积消息,而在峰值过去后下游系统慢慢消费消息解决流量洪峰的问题
并发量达到高峰时,后端系统压力通常会很大,无论是应用服务器还是数据库服务器,这个时候可以将类似请求放到消息中间件的消息队列中堆积起来慢慢处理,也可以设置消息队列的大小达到控制并发量的目的,商品秒杀的业务场景比较典型,在实际工作中遇到的业务场景也有很多,不一一列举。

4.可靠性传输:基于消息的通信是可靠的,消息不会丢失。大多数消息中间件都提供将消息持久化到磁盘的功能。开篇的第一个场景中,消息中间件可以将生产者生产的消息持久化到磁盘,后端应用宕机,但消息不会丢失,应用重启继续处理。

你可能会有这样的疑问,那消息中间件宕机了,接收不到消息怎么持久化?没关系,消息中间件提供了多种消息复制策略、持久化策略,集群部署策略等都可以保证消息的可靠性传输。那如果你是个爱钻牛角尖的人,你也许会问,集群中所有的节点都挂了怎么办。。。那如果世界末日了你还在care消息不消息的事情的话只能说明你足够敬业。

5.事件驱动:系统与系统之间可以通过消息传递的形式驱动业务
可以将复杂的应用系统重构成为事件驱动的系统。事件溯源(Event Sourcing),表示一个对象从创建到消亡,会经过的多种状态。如果把对象的状态变化都存储下来,不但可以根据状态变化记录获取对象的当前状态,也可以回溯对象的变化过程。消息中间件能很好地支持这样的系统设计方式,将触发对象状态变化的事件放入消息队列。

6.分布式事务支持
这个老生常谈的问题了,如果你不明白什么是分布式事务,请移步www.baidu.com。
kafka提供了对分布式事务的支持。欲知如何支持,且听下回分解。

二、kafka介绍
Kafka是由LinkedIn开发的一个分布式的消息系统,使用Scala编写,它以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark都支持与Kafka集成。淘宝的两款消息中间件,notify 和最近被Apache 加冕为顶级开源项目的RocketMQ都有kafka的影子。
总之,它很牛逼。

Kafka 专用术语
Broker:Kafka 集群包含一个或多个服务器,这种服务器被称为 broker。
Topic:每条发布到 Kafka 集群的消息都有一个类别,这个类别被称为 Topic。(物理上不同 Topic 的消息分开存储,逻辑上一个 Topic 的消息虽然保存于一个或多个 broker 上,但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处)。
Partition:Partition 是物理上的概念,每个 Topic 包含一个或多个 Partition。
Producer:负责发布消息到 Kafka broker。
Consumer:消息消费者,向 Kafka broker 读取消息的客户端。
Consumer Group:每个 Consumer 属于一个特定的 Consumer Group(可为每个 Consumer 指定 group name,若不指定 group name 则属于默认的 group)

kafka的架构图如下(来自网络):

三、集群部署和测试
kafka需要一个服务注册中心,你可以选择kafka自带的zookeeper,也可以单独部署。为了更好的管理,笔者单独部署zookeeper集群--其实是个伪集群,一台liux主机开放了三个端口即可。

zookeeper的运行需要jdk,所以先下载安装jdk,本文使用的jdk1.8
1.)下载安装jdk
jdk的安装步骤不做赘述, 笔者的版本是 jdk-8u144-linux-x64.tar.gz
配置环境变量(不会找度娘)
2.)下载zookeeper
先关闭防火墙,或者开放下文中需要用到的所有端口。

移步阿帕奇官网下载最新版zookeeper,
Zookeeper集群的工作是超过半数才能对外提供服务,3台中超过两台超过半数,允许1台挂掉。
创建目录 zookeeper :
mkdir zookeeper
解压下载后的压缩文件 tar -zxvf zookeeper-3.4.6.tar.gz
拷贝三份:
cp -r zookeeper-3.4.6 zookeeper0
cp -r zookeeper-3.4.6 zookeeper1
cp -r zookeeper-3.4.6 zookeeper2
进入zookeeper目录,其他的两个zookeeper实例同样操作:
创建两个目录zkdata、zkdatalog

进入conf目录,

拷贝zoo_sample.cfg 为zoo.cfg,详细配置如下:

# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just 
# example sakes.
dataDir=/usr/zookeeper/zookeeper0/zkdata
dataLogDir=/usr/zookeeper/zookeeper0/zkdatalog
# the port at which the clients will connect
clientPort=4180
server.0=192.168.217.129:8880:7770    
server.1=192.168.217.129:8881:7771    
server.2=192.168.217.129:8882:7772 
#server.0 这个0是服务器的标识也可以是其他的数字, 表示这个是第几号服务器,用来标识服务器,这个标识要写到快照目录下面myid文件里
#192.168.217.129为集群里的IP地址,第一个端口是master和slave之间的通信端口

以下是配置文件的解释:

#tickTime:

这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个 tickTime 时间就会发送一个心跳。

#initLimit:

这个配置项是用来配置 Zookeeper 接受客户端(这里所说的客户端不是用户连接 Zookeeper 服务器的客户端,而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器)初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5个心跳的时间(也就是 tickTime)长度后 Zookeeper 服务器还没有收到客户端的返回信息,那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒

#syncLimit:

这个配置项标识 Leader 与Follower 之间发送消息,请求和应答时间长度,最长不能超过多少个 tickTime 的时间长度,总的时间长度就是5*2000=10秒

#dataDir:

快照日志的存储路径

#dataLogDir:

事物日志的存储路径,如果不配置这个那么事物日志会默认存储到dataDir制定的目录,这样会严重影响zk的性能,当zk吞吐量较大的时候,产生的事物日志、快照日志太多

#clientPort:

这个端口就是客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。
创建myid

#server0
echo "0" > /usr/zookeeper/zookeeper0/zkdata
#server2
echo "1" > /usr/zookeeper/zookeeper1/zkdata
#server3
echo "2" > /usr/zookeeper/zookeeper2/zkdata

其他两个实例修改端口,同样操作。

启动zookeeper
进入bin目录;执行 ./zkServer.sh ../conf/zoo.cfg命令

检查启动状态:
./zkServer.sh status

mode:leader 表示这是个leader节点
其他两个实例同样操作。至此zookeeper伪集群搭建完毕。
本文地址https://my.oschina.net/u/3112259/blog/1556837

相关文章
|
1月前
|
消息中间件 运维 算法
Kafka 为什么要抛弃 Zookeeper?
本文探讨了Kafka为何逐步淘汰ZooKeeper。长久以来,ZooKeeper作为Kafka的核心组件,负责集群管理和协调任务。然而,随着Kafka的发展,ZooKeeper带来的复杂性增加、性能瓶颈及一致性问题日益凸显。为解决这些问题,Kafka引入了KRaft,这是一种基于Raft算法的内置元数据管理方案,不仅简化了部署流程,还提升了系统的一致性和扩展性。本文详细分析了这一转变背后的原因及其带来的优势,并展望了Kafka未来的发展方向。
104 1
|
1月前
|
消息中间件 监控 Ubuntu
大数据-54 Kafka 安装配置 环境变量配置 启动服务 Ubuntu配置 ZooKeeper
大数据-54 Kafka 安装配置 环境变量配置 启动服务 Ubuntu配置 ZooKeeper
72 3
大数据-54 Kafka 安装配置 环境变量配置 启动服务 Ubuntu配置 ZooKeeper
|
21天前
|
Dubbo 应用服务中间件 Apache
Dubbo 应用切换 ZooKeeper 注册中心实例,流量无损迁移
如果 Dubbo 应用使用 ZooKeeper 作为注册中心,现在需要切换到新的 ZooKeeper 实例,如何做到流量无损?
17 4
|
22天前
|
消息中间件 中间件 Kafka
解锁Kafka等消息队列中间件的测试之道
在这个数字化时代,分布式系统和消息队列中间件(如Kafka、RabbitMQ)已成为日常工作的核心组件。本次公开课由前字节跳动资深专家KK老师主讲,深入解析消息队列的基本原理、架构及测试要点,涵盖功能、性能、可靠性、安全性和兼容性测试,并探讨其主要应用场景,如应用解耦、异步处理和限流削峰。课程最后设有互动答疑环节,助你全面掌握消息队列的测试方法。
|
1月前
|
消息中间件 Java Kafka
ELFK对接zookeeper&kafka
ELFK对接zookeeper&kafka
|
1月前
|
存储 Kubernetes 调度
k8s学习--k8s群集部署zookeeper应用及详细解释
k8s学习--k8s群集部署zookeeper应用及详细解释
|
3月前
|
消息中间件 Kafka 测试技术
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
|
3月前
|
消息中间件 存储 Kafka
ZooKeeper助力Kafka:掌握这四大作用,让你的消息队列系统稳如老狗!
【8月更文挑战第24天】Kafka是一款高性能的分布式消息队列系统,其稳定运行很大程度上依赖于ZooKeeper提供的分布式协调服务。ZooKeeper在Kafka中承担了四大关键职责:集群管理(Broker的注册与选举)、主题与分区管理、领导者选举机制以及消费者组管理。通过具体的代码示例展示了这些功能的具体实现方式。
98 2
|
2月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
2月前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1

相关产品

  • 云消息队列 Kafka 版
  • 微服务引擎