消息队列

Kafka是目前非常流行的消息队列中间件，常用于做普通的消息队列、网站的活性数据分析（PV、流量、点击量等）、日志的搜集（对接大数据存储引擎做离线分析）。 全部内容来自网络，可信度有待考证！如有问题，还请及时指正。 概念介绍 在Kafka中消息队列分为三种角色: producer ，即生产者，负责产生日志数据。 broker ，存储节点，负责按照 topic 中的 partition 分区，均匀分布式的存储分区。 consumer ，即消费者，负责读取使用 broker 中的分区。 producer Kafka系统中的生产者，用于产生数据并发送给broker进行存储。由于需要与broker中的分区保持socket连接，因此需要在zk中维护生产者与分区broker的对应关系。同一个topic下的数据，会以某种负载均衡的方式发送到不同的分区中。 broker Broker可以当做Kafka中的存储节点，数据按照topic组织，按照某种负载均衡方式分配到不同的分区中。一个Topic由多个分区组成，每个分区可以设置备份数量。分区由一个leader+多个followers组成，生产者直接与leader进行沟通，leader接收消息后，其他的followers会同步这个消息。所有的follwers同步消息后，该消息才会成为可消费的状态。 Broker中Topic与分区，分区与生产者

消息从生产者出发，发送到消费队列，最终被消费者消费。 在这个过程中有哪些场景会发生消息丢失呢？ 消息路径 发生消息丢失的场景，如上图所示： 消息由生产者发送到队列中，当消息发出去没有收到消息队列的ack，会导致消息的丢失 消息已经到了队列，但是在消息还未持久化、消息队列挂掉重启，导致消息丢失 消息已经被消费者持有，但是消费端发生了异常，消息消费失败，导致消息丢失 同步的方式，捕获消息发送异常的，异常了在发送消息； rabbitMq,采用confirm的方式，采用回调的方式，来异步的处理消息发送失败的情况； queue设置为持久化、deliveryMode=2； 消费端，设置为手动应答，配置死信队列； 来源： CSDN 作者： syrlyz 链接： https://blog.csdn.net/syrlyz/article/details/103704025

最近做一个需求需要用SpringBoot整合Kafka的多播机制，所以就顺便写篇文章介绍一下自己的对Kafka多播机制的应用吧。 先说明一下我的需求，一个分布式系统内每个节点需要处理存在该节点本地的文件，但是处理的任务必须放到队列中排队避免高并发引起的系统崩溃。当时由于需要处理的文件都是在发出消息的节点上的，所以考虑之后决定使用Kafka的多播机制来实现。 首先简单讲解一下Kafka的多播机制。Kafka的消息是由消费组Group来消费的，Kafka会把消息复制多份发给每个注册的消费组一份。每个消费组内只消费该消息一次，也就是说只要这个消费组中有人消费了这个消息，这个消息就认为被消费了，但是不影响其他消费组内的这个消息。 所以我的流程是这样的：每个节点都用自己的IP作为GroupId来注册一个消费组，当消费消息的时候判断消息中包含的ip地址是否与该节点的IP地址匹配，如果匹配就处理文件，如果不匹配就直接消费消息不做任何操作。 1.SpringBoot整合Kafka SpringBoot整合Kafka是非常简单的，引入kafka的依赖再在application.properties文件上配置Kafka的配置参数就可以直接使用了。如下图所示： 2. kafka生产者发送消息 如上图所示，只需要调用kafkaTemplate对象就可以直接发送消息了。 3.kafka注册动态消费组

Springboot 集成 RabbitMQ 后的消息确认机制 上一篇文章介绍了 Springboot 如何集成 RabbitMQ，同时也形成了最基本的实现，不过这个实现好像有一点点问题，记得还在菊厂培训的时候，有一篇培训 PPT 讲过，极其健壮的服务需要达到一年下来，平均只有一到两个小时不能提供服务，反过来就是说，程序可能会在这一两个小时中宕机，宕机意味着数据丢失。就例如我们讲到的 RabbitMQ，假如我们在处理某一条数据的过程中宕机了，程序没有完成处理过程不会正常返回，同时 RabbitMQ 上这条消息因为已经发送给消费者，所以不会保留，那么这条未处理完的数据是不是就丢失了。RabbitMQ 给了我们一个保护机制，手动回复 ack，上一篇文章使用了默认的自动 ack 就无法避免这个问题。 注：后面代码都是对上一篇文章的程序小小改动后测试的 修改手动回复 ack 配置文件 增加开启手动回复的配置 修改的配置信息如下 #rabbitmq相关配置 spring.rabbitmq.host=127.0.0.1 spring.rabbitmq.port=5672 spring.rabbitmq.username=guest spring.rabbitmq.password=guest # 开启发送失败退回 spring.rabbitmq.publisher-returns=true #

本章目标 消费端限流 消息的ACK与重回队列 TTL消息 死信队列 消费端限流 什么是消费端的限流？ 假设一个场景，首先，我们RabbitMQ服务器有上万条未处理的消息，我们随便打开一个消费者客户端，会出现下面情况： 巨量的消息瞬间全部推送过来，但是我们 单个客户端无法同时处理这么多数据！ 消费端限流RabbitMQ提供的解决方案 RabbitMQ提供了一种qos（服务质量保证）功能，即在 非自动确认消息 的前提下，如果一定数目的消息（通过基于Consumer或者Channel设置Qos的值）未被确认前，不进行消费新的消息 Void BasicQos(uint prefetchSize, ushort prefetchCount, bool global); prefetchSize ： 0 不限制消息大小 prefetchSize ：会告诉RabbitMQ不要同时给一个消费者推送多于N个消息，即一旦有N个消息还没有ack，则该Consumer将block（阻塞）掉，直到有消息ack Global ：true\false是否将上面设置应用于Channel；简单来说，就是上面限制是 Channel 级别的还是Consumer级别 【 注意 】 prefetchSize和global这两项，RabbitMQ没有实现，暂且不研究； prefetch_count在no_ask

什么是 Kafka Kafka 是由 Linkedin 公司开发的，它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。 Kafka 的基本术语 消息：Kafka 中的数据单元被称为消息，也被称为记录，可以把它看作数据库表中某一行的记录。 批次：为了提高效率， 消息会分批次写入 Kafka，批次就代指的是一组消息。 主题：消息的种类称为 主题（Topic）,可以说一个主题代表了一类消息。相当于是对消息进行分类。主题就像是数据库中的表。 分区：主题可以被分为若干个分区（partition），同一个主题中的分区可以不在一个机器上，有可能会部署在多个机器上，由此来实现 kafka 的伸缩性，单一主题中的分区有序，但是无法保证主题中所有的分区有序 生产者： 向主题发布消息的客户端应用程序称为生产者（Producer），生产者用于持续不断的向某个主题发送消息。 消费者：订阅主题消息的客户端程序称为消费者（Consumer），消费者用于处理生产者产生的消息。 消费者群组：生产者与消费者的关系就如同餐厅中的厨师和顾客之间的关系一样，一个厨师对应多个顾客，也就是一个生产者对应多个消费者，消费者群组（Consumer Group）指的就是由一个或多个消费者组成的群体。 偏移量：偏移量（Consumer Offset

一、RabbitMQ消息确认机制 RabbitMQ的消息确认有两种： 1、对生产端发送消息的确认。这种是用来确认生产者将消息发送给交换器，交换器传递给队列的过程中，消息是否成功投递。发送确认分为两步，一是确认是否到达交换器，二是确认是否到达队列。 2、对消费端消费消息的确认。这种是确认消费者是否成功消费了队列中的消息。 二、RabbitMQ对生产端发送消息的确认 rabbitmq对生产端发送消息的确认分为事务和实现confirm机制。不过一般不使用事务，性能消耗太大。对生产端的confirm机制参见： https://www.cnblogs.com/alan6/p/11483419.html 三、消费端消费消息后对RabbitMQ的确认 为了保证消息能可靠到达消费端，RabbitMQ也提供了消费端的消息确认机制。消费者在声明队列时，可以指定noAck参数，当noAck=false时，RabbitMQ会等待消费者显式发回ack信号后才从内存(和磁盘，如果是持久化消息的话)中移去消息。否则，RabbitMQ会在队列中消息被消费后立即删除它。 采用消息确认机制后，只要令noAck=false，消费者就有足够的时间处理消息(任务)，不用担心处理消息过程中消费者进程挂掉后消息丢失的问题，因为RabbitMQ会一直持有消息直到消费者显式调用basicAck为止。 消费端消息的确认分为：自动确认

笔者所在业务环境 springcloud 1.5.8 jdk1.8 软件安装包百度网盘链接: https://pan.baidu.com/s/1Augp_VYZTfRMSQkchkbx-w 提取码: neqh 也是目前产品中线上用的版本 一、安装编译工具,安装Erlang之前需要进行编译工具安装，通过执行以下命令就可以完成安装。 yum -y install make gcc gcc-c++ kernel-devel m4 ncurses-devel openssl-devel 二、安装和配置Erlang #进入上传安装工具存放目录 cd /root #解压erlang tar xvf otp_src_20.3.tar.gz #进入解压erlang目录 cd otp_src_20.3 #配置 '--prefix'指定的安装目录，必须记住这个目录下面需要修改此目录 ./configure --prefix=/usr/local/erlang --with-ssl -enable-threads -enable-smmp-support -enable-kernel-poll --enable-hipe --without-javac #安装 make && make install #配置环境变量 vi /etc/profile 在你配置jdk等环境变量的地方加入 #使环境变量生效

一、前言 rabbitmq中的交换机类中，topic作为一种很常用的转发模式。 在之前的博文中，除了fanout模式外，其他的有关转发器和消息队列的我们都有指定routingkey的写法，在进行 配置消息转发器和消息队列 时，都是按照具体的routingkey实现关联。 但上述操作限制太死板，如何能够进行 动态匹配 呢？接下来我们引入topic模式。 二、配置项 2.1、代码配置项编写前的准备 上图中就是我们本篇博客需要配置的内容，其中流程为： 1、消息生产者发送消息至指定的转发器上。 2、消息转发器按照配置好的关联规则，推送消息至对应的消息队列上。 我们在配置文件中，需要做如下几件事： 1、bean配置exchange，取名 topicExchange 。 2、消息队列两个，分别是 topicQueue1 、 topicQueue2 。 3、消息转发器和队列一的绑定为： #.xiangjiao.* 4、消息转发器和队列二的绑定为： #.xiangjiao.# 2.2、代码配置项的编写 2.2.1、注入队列和转发器，并进行绑定 import org . springframework . amqp . core . Binding ; import org . springframework . amqp . core . BindingBuilder ; import org .

一、消息中间件的介绍 1、介绍 ​ 消息队列 是指利用 高效可靠 的 消息传递机制 进行与平台无关的 数据交流，并基于 数据通信 来进行分布式系统的集成。 2、特点(作用): 应用解耦 异步通信 流量削峰 (海量)日志处理 消息通讯 3、应用场景 根据消息队列的特点，可以衍生出很多场景，或者说很多场景都能用到。下面举几个例子： 1）异步通信 ​ 注册时的短信、邮件通知，减少响应时间； 2）应用解耦 ​ 信息发送者和消息接受者无需耦合，比如调用第三方； 3）流量削峰 ​ 例如秒杀系统； 借鉴：https://www.cnblogs.com/yanfei1819/p/10615605.html 来源： CSDN 作者： 深拥不弃0924 链接： https://blog.csdn.net/qq_44746074/article/details/103686534