- 为什么要使用消息队列
- 解耦,解决频繁的接口修改
- 异步,解决快速返回的问题
- 削峰,解决高峰期系统压力的问题
- 消息队列的优缺点
- 系统可用性降低:mq挂掉,生产者无法放消息进mq,消费者无法消费
- 系统复杂性变高
- 一条消息多次发送
- 消息丢失
- 消费端消费顺序问题
- 积累大量消息后,mq挂掉
- 一致性问题:发送请求后,等后续所有成功才返回,但当后续中某一个系统失败,结果返回成功
- kafka、activemq、rabbitmq、rocketmq区别以及适合场景
-
activemq rabbtimq rocketmq kafka 单机吞吐量 万级,比rocketmq和kafka低 万级,比rocketm和kafka低 十万级 十万级别,一般用于大数据类系统进行实时统计日志采集等场景 时效性 毫秒级 微秒级 毫秒级 毫秒级以内 可用性 高,基于主从框架 高,基于主从框架 非常高,分布式架构 非常高,基于分布式,一个数据多个副本,少数机器宕机,数据不会丢失,不会导致不可用 消息可靠性 有较低的几率丢失数据 经过参数配置可以做到0丢失 经过参数配属可以做到0丢失
-
-
rabbitmq高可用性
-
普通集群模式 多台机器没太机器都有一个rabbitmq实例,某一个是咧中有queue的元数据和实际数据,当请求到实际数据节点时,无实际数据的节点会找到有实际数据的节点,拉取数据并交给消费者。 提高吞吐量:缺点1、内部阐释大量数据传输2、可用性几乎没有什么保障
-
镜像集群模式 每一个节点都会包含queue的完整的所有的数据,写消息到任何一个节点,都会有消息同步到其他节点上去,相当于每个节点都有一个queue的镜像,这个镜像包含queue的元数据以及实际数据,消费者从任何一个节点消费queue的数据都有完整的数据,只有在写消息的时候才会进行同步和传输。
-
-
kafka高可用性
-
部署多台机器,在没太机器谁给你启动一个broker进程,生产者写入多条数据到topic,分配到多个partition中,相当于分配到多个机器中。
-
问题 当某一台机器挂条,是否会丢失一部分数据 :0.8以后有高可用机制,会做一个replica副本,具有相同的数据,一个partition多个副本,会选举一个leader,其他的都叫follower,生产者只能往leader中写数据,消费者也只能从leader中读数据,leader会把写入的数据同步到follower中
-
-
kafka出现消息重发消费的问题
-
按照数据进入kafka的顺序,kafka都会给每天数据发票一个offset,代表这个数据的序号,消费者消费的时候,会按照这个顺序进行消费,消费者会去提交offset就告诉kafka已经消费了offset=某个值的这条数据(基于zookeeper实现,只要提交了这个offset,zookeeper就会进行记录,然后kafka会感知到消费者消费那条数据),消费者定时定期提交offset
-
-
rabbitmq消息丢失问题
-
生产者丢失数据
-
rabbitmq支持事务,打开事务try{发送消息}catch{胡滚重发}同步锁机制导致阻塞卡
-
设置channel信道设置为confrim模式->发送消息->成功,回调生产者通知成功->失败回调生产者通知失败,再次发送,异步不会阻塞,吞吐量会比较高一些
-
-
rabbitmq丢失数据
-
设置queue持久化,设置消息持久化
-
-
消费者丢失数据
-
关闭autoack机制,手动通知是否消费完毕消息
-
-
-
kafka消息丢失
-
生产者丢失
-
kafka丢失
-
设置一个topic至少有俩个副本
-
至少一个flower与leader保持通信
-
必须写入到所有的flower才算成功
-
无限次重试
-
-
消费者关闭
-
消费者关闭自动提交offset,手动提交offset
-
-
-
rabbitmq消费顺序
-
增 改 删->删 改 增 一个queue被多个消费者消费
-
解决 需要抱着顺的数据一个queue被一个消费者消费
-
-
kafka消费顺序问题
-
对需要有顺序的数据设置一个key,然后这个可以的数据会被写入到一个partition中,kafka抱着写到一个partition中的数据有顺序的。
-
问题:当消费者多线程处理消息的时候出现顺序错乱情况,可以功能键key来做一个内存队列来抱着每个消费线程的顺序性
-
各个消息队列对比以及问题
最新推荐文章于 2022-06-08 10:50:32 发布