三种常见mq的优缺点比较

这篇具有很好参考价值的文章主要介绍了三种常见mq的优缺点比较。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

共同的优缺点:
    优点:解耦系统,异步化,削峰
    缺点:系统可用性降低,复杂度增高,维护成本增高
    MQ,保证最终一致性
同时保证消息的处理的幂等性,保证broker的高可用
优点:
1.实现简单,改造成本低
2.性能高,没有全局锁
缺点
1.弱一致性,需要保证强一致性不适用
2.消费者消费失败,需要额外接口写生产者回滚逻辑

1.Rabbitmq

a.安装和启动
docker pull rabbitmq:3.8.15-management
docker run -d --name xd_rabbit -e
RABBITMQ_DEFAULT_USER=admin -e
RABBITMQ_DEFAULT_PASS=password -p 15672:15672 -p
5672:5672 rabbitmq:3.8.15-management
概念:一个开源的amqp实现,服务端使用erlang语言开发,支持多种客户端,主要用于消息的存储转发,具有较高的易用性,扩展性,高可用性
优点:RabbitMq自带延迟队列,更符合这块业务,比如定时任务,分布式事务处理
消息发送完整流程:
    生产者将消息发送到exchange,交换器将消息路由到一个或多个队列中,交换机有多个类型,交换机和队列通过路由键进行绑定,如果消息拥有的路由键和交换机匹配,消息就会被路由到队列中
基本概念:
    交换器:常见的交换机主要有Direct exchange、Fanout exchange、Topic exchange
    Direct exchange:将一个队列绑定到交换机上,要求该消息与一个特定的路由键完全匹配
    Fanout Exchange:只需要简单的将队列绑定到交换机上,一个发送到与该交换机绑定的所有队列都会收到消息
    不处理路由键
    Topic Exchange通配符:主题交换机是一种发布订阅模式.将路由键和某模式进行匹配,此时队列需要绑定到一个模式上, #匹配一个或多个词,* 匹配不多不少一个词
    使用场景:商家和客户订单数据冗余双写问题
    ACK机制:消费者从rabbitmq接收到消息,并处理完成后,反馈给rabbitmq,rabbitmq接收到反馈才将消息从队列中删除

mq对比,java-rabbitmq,rabbitmq,java

 mq对比,java-rabbitmq,rabbitmq,java

 常见面试题

Rabbitmq为什么需要信道,为什么不TCP直接通信:
    1.TCP的创建和销毁开销特别大,创建需要三次握手,销毁需要四次挥手
    2.如果不用信道,那么应用程序会以TCP连接rabbitmq,高峰时每秒上千万的链接造成资源浪费,并且操作系统每秒处理的tcp连接数也是有限的,必将造成性能瓶颈.
    3.信道的原理是一个线程一条通道,多个线程多个通道同用一个tcp链接,一条tcp链接可以容纳无限的信道.
    
死信队列:
    死信交换机:消息成为死信消息后,会被放到新的交换机,这个交换机就是死信交换机
    几种情况会成为死信?
    1.消费者拒收消息,并且没有重新入队
    2.超时未被消费
    3.消息队列超过极限

2.Kafka

1.概念:apache软件基金会开发的一个开源流处理平台,kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理大规模的网站中的所有动作流数据(网页浏览.搜索和其他用户行为),副本集机制,实现数据冗余,保障数据尽量不丢失
支持多个生产者和消费者,不支持批量和广播消息
特点:高吞吐量,低延迟,每秒可以处理几十万消息
     高并发:支持几千万客户端同时读写
     容错性:多副本,多分区,允许集群中节点失败
     扩展性强:支持热扩展
最大优点:单机写入tps约在百万条/s,吞吐量高     

kafka2.4之后,kafka提供了有限的读写分离,也就是说follower副本能够提供读服务,为啥没有?
1.场景不适用,读写分离适用于读负载很大,而写操作相对不频繁的场景.可kafka不属于这样的场景
2.数据同步机制,kafka采用pull 方式实现follwer的同步,因此Follwer与leader存在不一致性窗口,如果允许读follwer副本,就势必要处理消息滞后的问题
基本概念:
    ConsumerGroup消费者组:一个消费者组只有一个comsumer可以消费topic下的消息
    Topic:
    Partition分区:kafka数据存储的基本单元,每个topic下至少一个partion,是有序的,以文件夹的形式存储在具体broker本机上.消费者数量小于等于partition数量
    Replication副本:同个partition会有多个副本replication,多个副本的数据是一样的,当broker挂掉以后,系统可以主动用副本提供服务
        ReplicationLeader:该partition扶着和生产者消费者交互
        ReplicationFollower:提供数据备份,同步leader数据
        ReplicationManager:负责broker所有分区副本信息,副本状态切换
    offset:每个comsumer实例需要为消费的partition维护自己消费的偏移offset
    LEO:表示每个partition的log最后一条message的位置
    HW:每个partition各个replicas数据同步且一致的offset位置。HW之前的数据才是commit后的对消费者可见
    ISR:leader会维持一个与其保持同步的replica集合
    Segment:每个partition由多个segment file组成,分为index file 和data file也称log file,分别表示索引文件和数据文件
    Kafka高效文件存储设计特点:
        1.kafka把topic中的一个partition大文件分成多个小文件段,通过多个小文件段,容易定期清楚或删除已经消费完的文件,减少磁盘占用
        2.通过索引文件可以快速定位message
        3.写数据通过顺序写


生产者发送消息到broker的分区策略:
    1.如果指定partitionId 则PR被发送到指定partition
    2.未指定id,但指定了key,PR会按照hash发送到对应partition
    3.两者均未指定.PR会按照round-robin轮训模式发送到每个partition
生产者发送消息到broker的流程:
    kafka的客户端发送数据到服务器,先经过内存缓冲区默认16KB,通过kafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲区中,然后把很多消息收集到batch里面,再一次性发送到broker上去的,这样性能才可能提高,提高效率,减少请求
生产者两个关键配置:
batch.size
linger.ms

Kafka的消费者机制(模式):
    消费者采用pull模式.而不是broker主动push
    pull模式可以根据comsumer的消费能力进行调整,不能的消费者性能不一样,如果broker没有数据,comsumer可以配置timeout时间,阻塞等待一段时间之后再返回
    如果采用broker主动push,优点是可以快速处理消息,但是容易造成消费者处理不过来,造成消息堆积和延迟
消费者分区策略:
    1.顶级接口:org.apache.kafka.clients.comsumer.internals.AbstractPartitionAssignor
    2.RoundRobinAssignor轮训,
    按照消费者组进行轮训分配,把所有的partition和所有的consumer都列出来,主题不一样则会出现分配不均的问题,实例如下

RangeAssignor默认策略:
  按照主题进行分配,将该topic的所有可用的partition和订阅该topic的所有comsumer展开,如果分配不均,会导致消费者分配过多分区,消费的分区过多会导致性能有所下降

mq对比,java-rabbitmq,rabbitmq,java文章来源地址https://www.toymoban.com/news/detail-516507.html

Kafka消费者重新分配策略:
Rebalance操作:
  平衡:Kafka怎么均匀的分配某个topic下的所有partition给消费者,从而使消息的消费速度达到最快。具体策略主要才去Range范围分区和RoundRobin轮训分区,也支持自定义分区策略
  重平衡(Rebalance):重新进行partition的分配,从而使得partition的分配重新达到平衡状态
该知识点常见面试题:
    1.例如70个分区,10个消费者,但是先启动一个消费者,后续再启动一个消费者,这个时候如何分配?
    kafka会进行一次分区分配操作,即Kafka消费者端的重平衡操作
    2.触发重平衡的条件:
        a.当消费者组内的消费者数量发生变化,就会产生重新分配partition
        b.分区数量发生变化时
    3.当消费者早消费过程中突然宕机了,重新恢复后是从哪里消费,会有什么问题?
    消费者会记录offset,故障恢复后从这里开始消费,旧版offset记录在zk喝本地,新版默认offset保存在kafka的内置topic中,名称是_comsumer_offsets    
    假设topic默认的partition数量是50个,每个partition有3个副本,分区的数量由offset.topic.num.partition配置
    首先通过groupid的哈希值和该参数取模来确定消费者组已经消费的offset保存到_comsumer_offsets主题的哪个分区中
    再由消费者组名+主题+分区,来确定唯一的offset的key,从而获取对应的值


Kafka日志清理
1.内部有个定时任务检测删除日志,默认是5分钟
 根据配置策略对数据清理
 根据segment单位进行定期清理
2.基于时间删除日志说明
3.基于大小超过阈值删除日志说明,超过阈值的部分必须要大于一个日志段的大小

Kafka数据存储流程和log日志
数据存储主要采取分片和索引机制,将每个partition分为多个segment,每个segment对应2个文件,index和log
index文件并没有为每一条message建立索引,采用了稀疏存储的方式,每隔一定字节的数据建立一条索引,避免索引文件占用过多的空间和资源,从而可以将索引文件保留在内存中
缺点:没有建立索引的数据在查询过程中需要小范围的顺序扫描操作

常见面试题

Kafka高性能:
1.存储模型,topic下分多分区,每个分区多segment段
2.index索引文件查找,利用分片和稀疏索引
3.磁盘顺序写入
4.异步操作少阻塞main线程和sender线程,批量操作
5.页缓存,Page cache,没利用JVM内存
6.零拷贝 sendFile

RocketMQ:

 1.消息中间件,纯java开发,具有高吞吐量,高可用性,适合大规模分布式系统应用的特点,性能强劲(零拷贝技术),支持海量堆积,支持指定次数和时间间隔的失败消息重发,支持comsumer端tag过滤,延迟消息等
 2.缺点.成熟资料相对另外几种不多,社区处于新生状态但是热度高


消息队列的发送方式:
1.SYNC:同步发送,应用场景,重要邮件发送,报名短信通知等
2.ASYNC:异步发送,应用场景,对RT时间敏感,可以支持更高的并发,回调成功触发相应的业务,应用场景:注册成功通知积分系统发放优惠券
3.ONEWAY:无需要等待响应,应用场景:适用于某些耗时非常短,但是对可靠性要求不高的场景,例如日志服务

如何保证消息队列的消息生成和消费的顺序性
1.顺序消息的概念:
    消息的生产和消费顺序一致
2.分类:
    全局顺序:topic下⾯全部消息都要有序(少⽤),性能要求不⾼,所有的消息严格按照 FIFO原则进⾏消息发布和消费的 场景,并⾏度成为消息系统的瓶颈, 吞吐量不够
    局部顺序:只要保证⼀组消息被顺序消费即可,性能要求⾼
    
3.举例:Rocketmq
    顺序发布:对于指定的一个topic,客户端将按照一定的先后顺序发送消息
    根据messageQueueSelector里面的自定义策略select方法里,根据同个业务id放置到相同queue里面
    顺序消费:对于指定的一个topic,按照一定的先后顺序接收消息
    消费端要在保证同个topic里面的同个队列,不应该使用MessageListenerConcurrently,而应该使用
    MessageListenerOrderly,自带单线程消费,不能在comsuer端多线程消费,消费端分配到的queue数量是固定的,集群消费会锁住当前正在消费的队列集合的消息,所以保证顺序消费

如何保证消息的可靠性传输吗?
消息的可靠性传输主要从三个方面答:
    1.producer端:不采用oneway发送,使用异步或者同步发送,并做好重试,投递的日志需要保存,关键字段,投递时间,投递状态,重试次数,请求体和响应体等
    2.broker端:多主多从架构,多机房部署,同步双写,异步刷盘,同步刷盘消息不丢失具体根据业务选择
    3.comsumer端:消息队列一般提供ack机制,发送者为了保证消息肯定消费成功,只有消费者明确表示消费成功,队列才会认为消息消费成功,中途断电,抛异常等不会认为成功
    消息消费务必保留日志,即消息的元数据和消息体

到了这里,关于三种常见mq的优缺点比较的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ChatGPT和文心一言的优缺点比较

    ChatGPT和文心一言都是自然语言生成技术的代表,下面是它们的优缺点比较: ChatGPT的优点: 自由度高:ChatGPT生成的文本与给定的话题没有紧密的关联,可以灵活地生成多种不同的文本。 多样性高:ChatGPT可以生成多样性高的文本,因为其生成文本的过程是依据语言模型和概率

    2024年02月10日
    浏览(50)
  • diffusion 和 gan 的优缺点对比

    train GAN 训练的网络是生成器和判别器,生成器用于生成图像,判别器辅助生成器的训练。 Diffusion 训练的噪声评估网络。 sample GAN 推理快,GAN的生成网络有维度变化。 Diffusion 推理慢,需要迭代更多次,推理过程图像尺寸不变。 训练难度 GAN 的训练可能是不稳定的,容易出现

    2024年01月25日
    浏览(52)
  • python和java的优缺点横向对比

    Python和Java都是非常流行的编程语言,它们各有优缺点,下面是它们的详细介绍: Python的优点: 语法简单易学,比较适合初学者。 开发效率高,因为它具有丰富的库和模块,可以减少代码量。 具有强大的数据分析和科学计算能力,适用于处理大量数据。 可以跨平台运行,同

    2024年02月06日
    浏览(59)
  • 4大主流小程序平台介绍及其优缺点对比

    ✍创作者:全栈弄潮儿 🏡 个人主页: 全栈弄潮儿的个人主页 🏙️ 个人社区,欢迎你的加入:全栈弄潮儿的个人社区 📙 专栏地址:小程序从入门到精通 【分享几个国内免费可用的ChatGPT镜像】 【10几个类ChatGPT国内AI大模型】 【用《文心一言》1分钟写一篇博客简直yyds】

    2024年02月04日
    浏览(102)
  • 横向对比 npm、pnpm、tnpm、yarn 优缺点

    前端工程化 是现代Web开发中不可或缺的一环,它的出现极大地提升了前端开发的效率和质量。 在过去,前端开发依赖于手动管理文件和依赖,这导致了许多问题,如 版本冲突 、 依赖混乱 和 构建繁琐 等。而今,随着众多前端工程化工具的出现,前端开发的效率得到了大大

    2024年02月10日
    浏览(44)
  • 对比体验 ChatGPT,聊聊文心一言的优缺点

    在昨天文心一言发布后,我第一时间拿到了体验的资格,但第一次使用后却不禁有些失望。他的逻辑能力极度缺乏、创造力也差点意思。不过,今天再次高强度使用后,却又让我对这款产品的想法有了些许改变。 将 2023 年称为 AI 纪元在我看来也没什么不合适的:虽说 ChatGP

    2024年02月08日
    浏览(60)
  • 常用Python自动化测试框架有哪些?优缺点对比

    随着技术的进步和自动化技术的出现,市面上出现了一些自动化测试框架。只需要进行一些适用性和效率参数的调整,这些自动化测试框架就能够开箱即用,大大节省了测试时间。而且由于这些框架被广泛使用,他们具有很好的健壮性,并且具有广泛多样的用例集和技术来轻

    2024年02月03日
    浏览(50)
  • 简述Keepalived LVS 原理以及两者的优缺点对比分析

    本文章主要围绕Keepalived,lvs的工作原理以及两者的优缺点进行对比分析。My BLOG:https://blog.itwk.cc 什么是Keepalived? Keepalived是基于VRRP协议(Virtual Router Redundancy Protocol)是Linux下一个轻量级高可用解决方案(HA),其实两种不同的含义,广义来讲,是指整个系统的高可用行,狭

    2023年04月08日
    浏览(51)
  • http和websocket对服务器的优缺点对比

    HTTP的优点: 1. 简单易用:HTTP协议是一种简单易用的协议,可以轻松地实现客户端和服务器之间的通信。 2. 可缓存:HTTP协议支持缓存,可以减少服务器的负载,提高响应速度。 3. 可靠性高:HTTP协议使用TCP协议作为传输层协议,具有可靠性高的特点。 HTTP的缺点: 1. 频繁的连

    2024年02月09日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包