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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 业务系统中,通常会遇到这些场景: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月前
|
SQL 安全 测试技术
【软件设计师备考 专题 】测试要求说明书的编写和应用
【软件设计师备考 专题 】测试要求说明书的编写和应用
58 0
|
1月前
|
安全 测试技术
现代软件测试中的自动化技术应用及挑战
在当今数字化时代,软件测试的重要性日益凸显。本文探讨了现代软件测试中自动化技术的应用现状和挑战,分析了自动化测试在提高效率、降低成本、增强可靠性等方面的优势,同时也提出了自动化测试所面临的挑战和解决方案。
|
1月前
|
机器学习/深度学习 数据采集 人工智能
探索AI在软件测试中的应用与挑战
【2月更文挑战第25天】 随着人工智能(AI)技术的迅猛发展,其在软件测试领域的应用逐渐深入。AI不仅改变了传统测试流程,提高了测试效率和质量,也引入了新的挑战。本文将详细探讨AI在软件测试中的具体应用,包括智能化测试用例生成、缺陷预测、自动化测试执行等,并分析当前面临的主要挑战,如数据质量、模型泛化能力和工具集成等问题。通过实例分析和研究展望,本文旨在为软件测试专业人士提供一个关于AI技术融合的全面视角。
|
1月前
|
机器学习/深度学习 数据采集 人工智能
探索AI在软件测试中的应用和优势
【2月更文挑战第22天】 随着科技的不断发展,人工智能(AI)在各个领域的应用越来越广泛。本文主要探讨了AI在软件测试领域的应用及其带来的优势。文章首先介绍了AI技术的基本概念,然后详细分析了AI在软件测试中的具体应用,包括自动化测试、智能缺陷检测和预测等方面。最后,文章总结了AI在软件测试领域的优势,如提高测试效率、降低人力成本、提高测试质量等,并展望了AI在软件测试领域的未来发展趋势。
|
2天前
|
人工智能 监控 数据处理
【AI大模型应用开发】【LangSmith: 生产级AI应用维护平台】1. 快速上手数据集与测试评估过程
【AI大模型应用开发】【LangSmith: 生产级AI应用维护平台】1. 快速上手数据集与测试评估过程
12 0
|
2天前
|
测试技术 数据安全/隐私保护
深入理解与应用软件测试中的边界值分析法
【4月更文挑战第23天】在软件测试的诸多技术中,边界值分析法因其简洁性和高效性而备受青睐。本文旨在探讨边界值分析法的核心原理及其在实际测试场景中的应用。通过对边界条件进行系统的识别、分类和测试,该方法能够有效地发现软件缺陷。我们将详细讨论如何确定边界值,设计测试用例,以及如何处理复杂数据类型的边界情况。此外,文章还将展示通过案例研究来验证边界值分析法在提升测试覆盖率和发现潜在错误方面的实际效益。
|
26天前
|
Web App开发 Java 测试技术
深入理解与应用软件自动化测试工具Selenium
随着软件开发的快速发展,软件测试在保证产品质量方面发挥着越来越重要的作用。其中,自动化测试以其效率高、成本低的特点受到了广大开发者的欢迎。本文主要介绍了自动化测试工具Selenium的基本概念、原理以及在实际开发中的应用,旨在帮助读者更好地理解和使用Selenium进行高效的自动化测试。
22 4
|
27天前
|
算法 Java Linux
zookeeper单机伪集群集群部署
zookeeper单机伪集群集群部署
85 0
|
1月前
|
设计模式 敏捷开发 监控
深入理解与应用软件自动化测试框架
在快速迭代的软件开发过程中,自动化测试已成为确保产品质量和加快交付速度的关键因素。本文将详细探讨自动化测试框架的核心原理、设计模式及其在实际项目中的应用。我们将分析几种流行的自动化测试工具,如Selenium、Appium和JUnit,并讨论它们如何集成以形成强大的测试解决方案。文章还将展示通过自定义框架来满足特定测试需求的实例,以及如何通过持续集成和持续部署(CI/CD)流程优化测试实践。
|
1月前
|
缓存 运维 Serverless
应用研发平台EMAS产品常见问题之测试检查更新没有反应如何解决
应用研发平台EMAS(Enterprise Mobile Application Service)是阿里云提供的一个全栈移动应用开发平台,集成了应用开发、测试、部署、监控和运营服务;本合集旨在总结EMAS产品在应用开发和运维过程中的常见问题及解决方案,助力开发者和企业高效解决技术难题,加速移动应用的上线和稳定运行。

相关产品

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