![](https://img-blog.csdnimg.cn/20201014180756919.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
消息队列
文章平均质量分 64
developer@liyong
GISer
展开
-
消息队列-kafka-高性能设计及对比
消息查询:RocketMq “topic+key”、“topic+messageId” 支持,kafka 不支持。3 在发送消息的时候,先是通过send发送到了队列里面,然后sender线程批次发送,这样节省了网络开销。Master宕机有无自动切换:RocketMq普通不支持但是 Dledger 支持,kafka 自动支持。建立了一个通道,不将数据拷贝到用户态,而是直接由用户写这个通道,这样少一次拷贝。消息过滤:RocketMq支持,kafka 不支持。消息轨迹:RocketMq支持,kafka 不支持。转载 2024-03-09 23:40:22 · 67 阅读 · 0 评论 -
消息队列-Kafka-消费方如何分区与分区重平衡
拉取消息:org.apache.kafka.clients.consumer.KafkaConsumer#pollForFetches。协调者会选一个leader一般是先发起JoinGroup的消费者,这个时候协调器会告诉这个消费者去进行分区方案的生成。作用是让组内所有的消费者知道自己应该消费那个分区或者它可以不用消费分区,或者消费多个分区,都是由重平衡机制来保证的。入组成功,自己被选为分配分区的 leader:AbstractCoordinator#onJoinComplete。原创 2024-03-07 23:17:59 · 1096 阅读 · 0 评论 -
消息队列-Kafka-如何进行顺序消费
然后指定partitioner.class为我们的class,这样就可以自定义我们的分区逻辑,这个时候把需要放到同一个分区的数据使用同样的运算逻辑放到同一个分区即可。如果我们还是想同时消费多个分区并且保证有序,这个时候我们需要将需要保证顺序的消息路由到同一个分区。上面的代码定义了消息会被送到哪一个分区,我们发现起作用的是Partitioner。我们在ProducerConfig里面可以找到只有一段,使用了默认的分区。只有 1 个分区,那这个时候就是能够保证消息的顺序消费。原创 2024-03-07 22:22:13 · 535 阅读 · 0 评论 -
消息队列-kafka-服务端处理架构(架构,Topic文件结构,服务端数据的一致性)
2 活过来的时候,发现已经有顶替的 leader 角色(主分片)了,那么就跟随,也就是向 leader 获取 HW 高水位线,与自己的 LEO 比对,大于 LEO 则删除,小于 LEO 则从 leader 这边复制数据过去。1 首先它会从ISR中剔除,当恢复正常的时候,会向主分片获取 HW 高水位线,与自己的 LEO 比对,如果自己的 LEO 超过 HW 则干掉超过的部分,小于的话就从主分片复制数据过来。HW:高水位,消费者消费最高的位置,其实也就是木桶原理,所以只能到下面图中的第四条消息。原创 2024-03-05 22:17:41 · 1077 阅读 · 0 评论 -
消息队列-kafka-消息发送流程(源码跟踪) 与消息可靠性
我们发现里面是用一个MAP存储的一个分区和ProducerBatch 是讲这个消息写到内存里面MemoryRecordsBuilder 通过这个进行写入。6 接着我们就要看返回逻辑了,可以看到在sendRequest里面sendProduceRequest方法是通过传入了一个回调函数处理返回的。主线程:主线程只负责组织消息,如果是同步发送会阻塞,如果是异步发送需要传入一个回调函数。5 接着我们看,我们append了以后,会有一个判断去唤醒sender线程,见下面的注释。Map集合:存储了主线程的消息。原创 2024-03-04 23:44:59 · 984 阅读 · 1 评论 -
消息队列-Kafka-基础架构
上面这张图类比RocketMQ 相当于对一个主题进行了分区(类似于RockeMQ 消息队列),每个分区存储到不同的Broker。在发送消息的时候都是发送到主分区。如果一台Broker由于其它节点备份了挂掉节点的数据,所以可以继续进行消费,从而保证了整个集群的高可用性。原创 2024-03-04 21:57:37 · 754 阅读 · 0 评论 -
消息队列-RockMQ-消息的可靠性
处理,因为消费者有可能会消费多条数据(举一个典型的例子:就是并发消费的时,如果 offset 小的那条消息消费失败了,那即使 offset 大的那些消费成功了,那最后提交 offset 位移的时候,还是会将那个 offset 最小的成功值提交到 Broker 侧。Broker 突然 Crash:可以由刷盘策略来保证(同步刷盘不会丢消息,异步刷盘会丢失一点点消息)Broker 突然断电:其实还是可以由刷盘策略来保证(同步刷盘不会丢消息,异步刷盘会丢失一点点消息)也可以采用新的消费者组来进行重新消费。转载 2024-01-10 20:14:17 · 37 阅读 · 0 评论 -
消息队列-RockMQ-重试参数设置
如果发送失败,是否需要尝试发送到其他的 Broker 节点,就是没有特意的关注,到底是同步发送失败、还是异步发送失败,总之,只要是发送失败了后,看一看该变量,如果是 true 的话,那么就自动尝试将消息发送到其他的 Broker 节点。消费者比如消费消息的过程中发生了异常,希望再次消费。4 setRetryTimesWhenSendAsyncFailed:异步,参数默认值是2。3 setRetryTimesWhenSendFailed:同步,参数默认值是2。2 通过消费状态,设置过一会儿再重新消费。原创 2024-01-09 19:05:39 · 529 阅读 · 0 评论 -
消息队列-RockMQ-Demo案例&&拓展输入输出渠道
新建自定义Sink和Source 继承Sink 和 Source,原来的渠道也会保留。下面为一个Demo 生产者和消费者是一起的。原创 2024-01-09 11:24:21 · 391 阅读 · 0 评论 -
消息队列-RockMQ-定时延时发送消息
消费者订阅tag为test-topic_str的消息。我们看到test-group里面的消息总共有16条。任务需要延迟一段时间再进行处理。原创 2024-01-09 11:22:28 · 675 阅读 · 1 评论 -
消息队列-RockMQ-顺序收发消息实战
这个时候我们可以往一个队列里面写入数据,也只选择一个消费者进行消费,那么这个时候肯定是由序的。可以解决上面我们这个场景,但是这样的解决方案不是最好的,降低了消费效率和吞吐量。通过上面的思考我知道其实保证每个任务内部有序就行了,那么如果我们每个任务的消息都路由到同一个队列岂不是就可以了吗?假如我们有三个任务,任务1ABC,任务2DQ,任务3NQR,ABC这些字母都代表一个业务消息都要按照自己的内部的顺序消费。启动类,这里开启了两个通道一个通道验证全局有序性,一个通道验证局部有序性。原创 2024-01-09 11:20:29 · 462 阅读 · 0 评论 -
消息队列-RockMQ-单生产者多消费者
如果我们启动三个消费者,那么肯定是有一个消费者是要多消费数据的。当然实际生产我们可以和这个队列保持一致4个消费者组成一个消费者组进行消费。启动类,多个消费者的搭建方式可以通过-Dserver.port来启动多个应用。我们可以看到RocketMq默认是一个主题绑定了四个队列,原创 2024-01-09 11:18:42 · 524 阅读 · 0 评论 -
消息队列-RockMQ-事务消息收发实践
事务是一组操作组成,一个原子操作要么都成功,要么都失败。如果任务是在本地,比如操作数据库,可以把一组操作放到事务里面。但是发送消息是网络远程操作,怎么保证事务呢?正常的思路可能是先要用一张表来记录每一步骤的状态,然后监听这个状态来处理。举个常见的例子比如转账业务,我们发送一条消息到MQ,这条消息是远程累加B的余额,在累加B的余额之前我们要扣除A的余额扣除成功后这条消息才能到消费方执行真正的逻辑增加B的余额,这两个操作是一个事务操作。原创 2024-01-09 11:11:04 · 910 阅读 · 0 评论 -
消息队列-RockMQ-批量收发实践
比如网络带宽为可以支持一次性发送8M的数据包,如果数据包确定不会超过8M,那么我们可以除以每条消息的大小(粗略估算),然后会得到一个数值,这个数值再取70%-80%留一定的缓冲空间。发送消息是需要网络连接的如果我们单条发送吞吐量可能没有批量发送好。剖来那个发送可以减少网络IO开销,但是也不能一批次发送太多的数据,需要根据每条消息的大小和网络带宽来确定量的数目。如果我们一次性发送的数据超过了8M,就需要对这些消息进行分组发送,保证每一组的数据大小不超过8M,每一组发送的数量逻辑也是按照前面这样来计算。原创 2024-01-08 21:11:39 · 547 阅读 · 0 评论 -
消息队列-RockMQ-过滤发送消息实践
我们有这样一个需求,我们上面的消费组只想感知A类消息,下面的消费者组只想感知BC类的消息。这个时候就又有一个问题如果我们上面这个消费者组订阅了Tag1和Tag2的消息,下面订阅了Tag1和Tag3的消息。那么这个时候如果上面这个消费组的第二个消费者遇到了Tag1的消息岂不是就直接丢弃掉,同理下面也是,可能无形中丢失了一些消息。我这里测试得到的结果是始终消费不到TAG2的消息,如果你先启动消费者TAG2也就消费不到TAG1的消息,产生了消息丢失。我们可以通过||的方式订阅多个TAG。这种方式是基于我们使用。原创 2024-01-08 21:10:04 · 518 阅读 · 0 评论 -
消息队列-RocketMQ-概览与搭建
MessageQueue:消息队列,存储数据的一个容器(队列索引数据),默认每个 Topic 下有 4 个队列被分配出来存储消息。指定这个参数即可 -e “JAVA_OPT_EXT=-server -Xms1g -Xmx1g -Xmn512m”Subscription:订阅关系,消费者得知道自己需要消费哪个 Topic 下的哪个队列的数据。ConsumerGroup:众多消费者构成的整体或构成的集群,称之为消费者组。Message:消息,真正携带信息的载体概念。Consumer:消费者,负责消费消息。原创 2024-01-07 14:40:30 · 447 阅读 · 0 评论 -
消息队列-什么是MQ?何时使用MQ?怎么选择MQ?
MessageQueue:就是消息 + 队列,任务+队列,指令 + 队列。功能:应用程序之间(生产者与消费者)的通信方式。原创 2024-01-07 11:49:13 · 506 阅读 · 0 评论 -
kafka鹰眼监控
修改kafka启动命令if [ "x$KAFKA_HEAP_OPTS" = "x" ]; thenexport KAFKA_HEAP_OPTS="-server -Xms2G -Xmx2G -XX:PermSize=128m-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=8 -XX:ConcGCThreads=5 -XX:InitiatingHeapOccupancyPercent=70"export JMX_PORT=".原创 2021-02-10 11:12:58 · 396 阅读 · 0 评论 -
Kafka操纵
Kafka命令创建主题bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test查看主题bin/kafka-topics.sh --list --bootstrap-server localhost:9092启动生产端,发送消息bin/kafka-console-producer.sh --bootstrap-se原创 2021-02-10 09:27:55 · 315 阅读 · 0 评论 -
kafka架构
kafka数据读取策略1)顺序写磁盘Kafka 的 producer 生产数据,写的过程是一直追加到文件末端,为顺序写(省去了寻址的时间)。 官网有数据表明,同样的磁盘,顺序写能到 600M/s,而随机写只有 100K/s。2)零复制技术零拷贝,零拷贝技术见知识点/零拷贝kafka选举机制kafka集群中会有一个broker会被选举为 Controller,负责管理集群 broker 的上下线,所有 topic 的分区副本分配和 leader 选举等工作。消费策略一个 consumer原创 2021-02-09 13:50:47 · 116 阅读 · 2 评论 -
rabbitmq学习笔记
1.消息队列定义:RabbitMQ是目前非常热门的一款消息中间件,不管是互联网大厂还是中小企业都在大量使用。作为一名合格的开发者,有必要对RabbitMQ有所了解,本文是RabbitMQ快速入门文章,主要内容包括RabbitMQ是什么、RabbitMQ核心概念、常用交换器类型、用Docker安装RabbitMQ等。2.消息队列类型ActiveMQ,RabbitMQ,Kafka,rocketMQ。3.rabbitmq常用命令rabbitmq-server start # 启动服务rabbitmq-s原创 2020-11-21 20:10:30 · 266 阅读 · 0 评论