为什么不做网站做公众号,网站面包屑怎么做,明薇通网站建设首选,北京学会网站建设RocketMq和RabbitMq的优缺点
1、RabbitMQ 优点#xff1a;rabbitMq 几万级数据量#xff0c;基于erlang语言开发#xff0c;因此响应速度快些#xff0c;并且社区活跃度比较活跃#xff0c;可视化界面。 缺点#xff1a;数据吞吐量相对与小一些#xff0c;并且是基于er…RocketMq和RabbitMq的优缺点
1、RabbitMQ 优点rabbitMq 几万级数据量基于erlang语言开发因此响应速度快些并且社区活跃度比较活跃可视化界面。 缺点数据吞吐量相对与小一些并且是基于erlang语言开发比较重的问题难以维护。
2、RocketMQ rocketMq几十万级别数据量基于Java开发应对了淘宝双十一考验并且文档十分的完善拥有一些其他消息队列不具备的高级特性。 如定时推送其他消息队列是延迟推送如 rabbitMq 通过设置 expire 字段设置延迟推送时间。又比如rocketmq实现分布式事务比较可靠的。 1、如何保证系统的高可用
就rabbitMq而言有镜像模式概念就是用户在发送数据时候发送到mq机器上并且持久化磁盘然后通过设置镜像的queue把数的持久化地址对应表同步到另外mq机器上。这种就有效防止一台mq挂了以后另外的mq可以直接对外提供消费功能。 就rocketMq而言分为多主集群结构多主多备异步复制结构多主多备同步复制结构。
2、如何保证消息不会丢失 就rabbitmq而言从生产者消费者消息队列角度分析。生产者而言发送消息如果失败则定义重试次数一般设置成五次。 两种解决方式 1、通过设置事务进行事务回滚重试 2、通过发送者确认模式开启 方式一channel.waitForConfirms()普通发送方确认模式 方式二channel.waitForConfirmsOrDie()批量确认模式 方式三channel.addConfirmListener()异步监听发送方确认模式
RocketMq通过producerbroker,consumer端设置 1.Producer端采取send()同步发送消息发送结果是同步感知的。发送失败后可以重试默认3次。 2.Broker端修改刷盘策略为同步刷盘flushDiskType SYNC_FLUSH默认情况下是异步的。 3.Consumer端完全消费后手动ack确认。 以下是RocketMq相关知识 RocketMq架构各个模块的功能
Producer 负责生产消息一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息单向发送不需要。Broker消息中转角色负责存储消息、转发消息。在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。Consumer 负责消费消息一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式拉取式消费、推动式消费。NameServer 担任路由消息的提供者。生产者或消费者能够通过NameServer查找各Topic相应的Broker IP列表分别进行发送消息和消费消息。nameServer由多个无状态的节点构成节点之间无任何信息同步。 RocketMq消费模式
消费模型由Consumer决定消费纬度为Topic 1.集群消费一条消息只会被同Group中的Consumer消费多个group同时消费一个Topic时每个group都会有一个consumer消费到数据。 2.广播消费消息对每一个consumer group下的各个consumer实例都消费一遍 RocketMq的优势
1.吞吐量高单机的吞吐量可达十万级。 2.可用性高 3.消息可靠性高经过参数优化配置消息可以做到0丢失 4.支持10亿级别的消息堆积不会因为堆积导致性能下降 5.稳定性高,经过阿里双十一的验证 RocketMq如何保证消息不丢失
1.Producer端采取send()同步发送消息发送结果是同步感知的。发送失败后可以重试默认3次。 2.Broker端修改刷盘策略为同步刷盘flushDiskType SYNC_FLUSH默认情况下是异步的。 3.Consumer端完全消费后手动ack确认。 RocketMq如何保证消息顺序消费
首先要根据业务确认是否需要保证消息顺序如果不需要则不用管如果需要rocketMq给我们提供了MessageQueueSelector 接口可以自己重写里面的接口实现自己的算法。 RocketMq消息堆积如何处理
首选确认是Producer生产的消息太多消费者consumer消费不过来还是其它情况如果是消费者不够的话可以通过上线更多consumer来临时解决问题。 另外一种方式是新上线一台consumer把原来的Topic中的消息挪到新的Topic中不做业务处理。 RocketMq分布式事务实现原理
rocketMq特点之一就是支持分布式事务分布式事务可以使用TCC(Try, Confirm, Cancel) 2pc来解决分布式系统中消息的原子性。rocketMq实现方式 Half Message预处理当broker收到消息后会存储到 RMQ_SYS_TRANS_HALF_TOPIC的消息消费队列中Broker会开启一个定时任务消费 RMQ_SYS_TRANS_HALF_TOPIC队列中的消息每次执行任务会向Producer发送确认事务执行状态(提交回滚未知),如果是未知Broker会定时回调重新检查。如果超过过查询次数默认会回滚消息。也就是Producer产生的消息并未真正进入Topic的Queue而是用了临时queue来存放所谓的half message等事务提交后才真正的将half message转移到topic下的queue。
详情以及实现方式见 https://blog.csdn.net/qq_42877546/article/details/125404307?spm1001.2014.3001.5502 RocketMq部署方式一般选择后两种
1.单个Master 单机模式即只有一个Broker如果Broker宕机了会导致mq服务不可用。 2.多Master 组成一个集群集群没个节点都是Master节点配置简单性能也是最高的某个节点宕机重启不会影响mq服务。 缺点如果某个节点宕机了会导致该节点存在未被消费的消息在节点恢复之前不能被消费。 3.多Master多Slave模式异步复制 每个Master配置一个Slave多对Master-SlaveMaster与Slave消息采用异步复制 优点Master宕机后消费者可以从Slave节点进行消费采用异步模式复制提升了一定的吞吐量。 缺点如果Master宕机如果磁盘损坏没有及时将消息复制到Slave会导致少量消息丢失。 4.多Master多Slave模式同步双写 Master与Slave采用同步方式复制消息只有master和slave都写入成功后才会向客户端返回成功 优点数据与服务都无单点Master宕机情况下消息无延迟服务可用性和数据可用性非常高 缺点会降低消息写入效率影响吞吐量
