mq

Kafka-Eagle监控Kafka-Eagle框架可以监控 Kafka 集群的整体运行情况，在生产环境中经常使用。 在此之前监控工具需要MySQL作为持久化手段。 一、Kafka环境准备1、关闭 Kafka 集群12# 停止集群kf.sh stop 2、修改/opt/module/kafka/bin/kafka-server-start.sh1vim bin/kafka-server-start.sh 修改如下参数值： 123if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"fi 为 12345if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then export KAFKA_HEAP_OPTS="-server -Xms2G -Xmx2G -XX:PermSize=128m -XX:+U ...

前言环境介绍虚拟机软件：VirtualBox Linux 发行版本：Ubuntu 20.04.4 虚拟机核心数：1 core 虚拟机内存：2 GB JDK 版本：1.8.0_202 ZK 版本：3.8.0 Kafka 版本：3.2.0 Kafka - ZK 模式Kafka 2.8.0 之前，所有元数据信息都存储在 ZK。 ZK 成为 Kafka 瓶颈。从 2.8.0 开始，可以将元数据信息存储在 Kafka，脱离 ZK。 集群规划 node01 node02 node03 zk zk zk kafka kafka kafka ZK 集群部署可以参考 《Hadoop HA 搭建》 中的 ZK 集群搭建 Kafka 集群部署Kafka 环境变量1234567$ vim /etc/profile# 尾部添加以下内容export KAFKA_HOME=/opt/kafka-3.2.0export PATH=$PATH:$KAFKA_HOME/bin$ xsync $KAFKA_HOME$ xsync /etc/profile 配置 server.properties1234 ...

Kafka概述定义 Kafka传统定义：Kafka是一个分布式的基于发布/订阅模式的消息队列（MessageQueue），主要应用于大数据实时处理领域。 发布/订阅：消息的发布者不会将消息直接发送给特定的订阅者，而是将发布的消息分为不同的类别，订阅者只接收感兴趣的消息。 Kafka最新定义：Kafka是一个开源的分布式事件流平台（Event StreamingPlatform），被数千家公司用于高性能数据管道、流分析、数据集成和关键任务应用。 消息队列目前企业中比较常见的消息队列产品主要有 Kafka、ActiveMQ 、RabbitMQ 、RocketMQ 等。 在大数据场景主要采用 Kafka 作为消息队列。在 JavaEE 开发中主要采用 ActiveMQ、RabbitMQ、RocketMQ。 传统消息队列的应用场景传统的消息队列的主要应用场景包括：缓存消峰、解耦和异步通信。 消息队列的两种模式消息队列的两种模式 区别: 点对点消费 -> 消息只能发布到一个主题， 消费完成就删除消息，且只有一个消费者 发布订阅模式 -> 消 ...

一、Kafka 硬件 配置选择1、场景说明 2、服务器台数选择 3、磁盘选择 4、内存选择Kafka 内存组成：堆内存 + 页缓存 1）Kafka 堆内存建议每个节点：10g ~ 15g 在 kafka-server-start.sh 中修改 123if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then export KAFKA_HEAP_OPTS="-Xmx10G -Xms10G"fi 查看 Kafka 进程号: 1234[atguigu@hadoop102 kafka]$ jps2321 Kafka5255 Jps1931 QuorumPeerMain 根据 Kafka 进程号，查看 Kafka 的 GC 情况: 1jstat -gc 2321 1s 10 新生代GC次数 根据 Kafka 进程号，查看 Kafka 的堆内存： 12345678910111213141516171819202122232425262728293031323334353637383940414243444 ...

现象 RabbitMQ的管控台有几万条消息处于ready状态，还有几百条unacked的消息。 队列阻塞-分析原因 consumer消费处理错误消息失败后没有正常进行ack, 正常的消息也不再被消费, 随即导致队里阻塞 但为什么正常消息也没有被正常消费呢? 其实这是RabbitMQ的一种保护机制。防止当消息激增的时候，海量的消息进入consumer而引发consumer宕机。 RabbitMQ提供了一种QOS(服务质量保证)功能，即在非自动确认的消息的前提下，限制信道上的消费者所能保持的最大未确认的数量。可以通过设置PrefetchCount实现。 举例说明:可以理解为在consumer前面加了一个缓冲容器，容器能容纳最大的消息数量就是PrefetchCount。如果容器没有满RabbitMQ就会将消息投递到容器内，如果满了就不投递了。当consumer对消息进行ack以后就会将此消息移除，从而放入新的消息。 12345678910listener: simple: # 消费端最小并发数 concurrency: 1 # 消费端最大并发数 max- ...

服务器A的IP 服务器B的IP 192.168.56.110 192.168.56.111 创建持久化文件夹1234#在192.168.56.110上执行命令mkdir -p /home/rabbitmq/cluster/rabbitmq01#在192.168.56.111上执行命令mkdir -p /home/rabbitmq/cluster/rabbitmq02 启动RabbitMQ1234#在192.168.56.110上执行docker run -d --hostname rabbitmq01 --name rabbitmq01 --add-host=rabbitmq01:192.168.56.110 --add-host=rabbitmq02:192.168.56.111 -v /home/rabbitmq/cluster/rabbitmq01:/var/lib/rabbitmq --privileged=true -p 15672:15672 -p 5672:5672 -p 5671:5671 -p 4369:4369 -p 25672:25672 -e ...

消息队列在使用过程中，面临着很多实际问题需要思考： 消息可靠性消息从发送，到消费者接收，会经理多个过程： 其中的每一步都可能导致消息丢失，常见的丢失原因包括： 发送时丢失： 生产者发送的消息未送达exchange 消息到达exchange后未到达queue MQ宕机，queue将消息丢失 consumer接收到消息后未消费就宕机 针对这些问题，RabbitMQ分别给出了解决方案： 生产者确认机制 mq持久化 消费者确认机制 失败重试机制 1.生产者消息确认RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。这种机制必须给每个消息指定一个唯一ID。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。 返回结果有两种方式： publisher-confirm，发送者确认 消息成功投递到交换机，返回ack 消息未投递到交换机，返回nack publisher-return，发送者回执 消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因。 注意： 1.1.修改配置首 ...

单机部署我们在Centos7虚拟机中使用Docker来安装。 下载镜像1docker pull rabbitmq:3-management 安装MQ执行下面的命令来运行MQ容器： 123456789docker run \ -e RABBITMQ_DEFAULT_USER=itcast \ -e RABBITMQ_DEFAULT_PASS=123321 \ --name mq \ --hostname mq1 \ -p 15672:15672 \ -p 5672:5672 \ -d \ rabbitmq:3-management MQ集群集群分类RabbitMQ的是基于Erlang语言编写，而Erlang又是一个面向并发的语言，天然支持集群模式。RabbitMQ的集群有两种模式： •普通集群：是一种分布式集群，将队列分散到集群的各个节点，从而提高整个集群的并发能力。 •镜像集群：是一种主从集群，普通集群的基础上，添加了主从备份功能，提高集群的数据可用性。 镜像集群虽然支持主从，但主从同步并不是强一致的，某些情况下可能有数据丢失的风险。因此在RabbitMQ的3.8版本以后， ...

1.初识MQ1.1.同步和异步通讯微服务间通讯有同步和异步两种方式： 同步通讯：就像打电话，需要实时响应。 异步通讯：就像发邮件，不需要马上回复。 两种方式各有优劣，打电话可以立即得到响应，但是你却不能跟多个人同时通话。发送邮件可以同时与多个人收发邮件，但是往往响应会有延迟。 1.1.1.同步通讯我们之前学习的Feign调用就属于同步方式，虽然调用可以实时得到结果，但存在下面的问题： 总结： 同步调用的优点： 时效性较强，可以立即得到结果 同步调用的问题： 耦合度高 性能和吞吐能力下降 有额外的资源消耗 有级联失败问题 1.1.2.异步通讯异步调用则可以避免上述问题： 我们以购买商品为例，用户支付后需要调用订单服务完成订单状态修改，调用物流服务，从仓库分配响应的库存并准备发货。 在事件模式中，支付服务是事件发布者（publisher），在支付完成后只需要发布一个支付成功的事件（event），事件中带上订单id。 订单服务和物流服务是事件订阅者（Consumer），订阅支付成功的事件，监听到事件后完成自己业务即可。 为了解除事件发布者与订阅者之间的耦合，两者并不是直接 ...

惰性队列消息堆积问题当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。 解决消息堆积有两种思路： 增加更多消费者，提高消费速度。也就是我们之前说的work queue模式 扩大队列容积，提高堆积上限 要提升队列容积，把消息保存在内存中显然是不行的。 惰性队列从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下： 接收到消息后直接存入磁盘而非内存 消费者要消费消息时才会从磁盘中读取并加载到内存 支持数百万条的消息存储 基于命令行设置lazy-queue而要设置一个队列为惰性队列，只需要在声明队列时，指定x-queue-mode属性为lazy即可。可以通过命令行将一个运行中的队列修改为惰性队列： 1rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"lazy&quo ...