网站建设项目招标书,什么是seo和sem,深圳外贸公司电话,重庆好玩还是成都好玩RabbitMQ
1.为什么使用MQ?优点是什么
因为MQ可以异步处理#xff0c;提高系统吞吐量。 应用解耦#xff0c;系统之间可以通过消息通信#xff0c;不关心其他系统的处理。 流量削峰#xff0c;可以通过消息队列的长度#xff0c;控制请求量。可以缓解短时间内的高并发请…RabbitMQ
1.为什么使用MQ?优点是什么
因为MQ可以异步处理提高系统吞吐量。 应用解耦系统之间可以通过消息通信不关心其他系统的处理。 流量削峰可以通过消息队列的长度控制请求量。可以缓解短时间内的高并发请求。
解耦A-BCD但是如果E也想要这个数据或者C不想要了。A就需要修改。与各种下游系统严重耦合。 如果使用MQA系统产生一条消息到MQ哪个系统要消息就去消息系统里去消费。 异步A接收请求在本地写库在BCD三个系统分别要进行写库本地很快其它系统完成后传过来很慢如果同步方式 A需要BCD都完成之后才能返回给前端用户会觉得好慢。如果使用异步化处理的话A本地写库完成再往消息队列里写一个数据就可以返回了。 削峰大流量来的时候,系统可能承受不住这么大的压力如果用MQ就可以对这些请求不用急着处理转化为MQ里的消息数据然后以恒定的速率吐出。
2.消息队列有什么缺点
系统可用性降低MQ挂了系统就挂了增加环节就是在增加风险。 复杂性提高要考虑的问题多了比如一致性问题A的消息给BCD用BC成功D失败就是不一致了如何保证消息不被重复消费如何保证消息可靠性传输。
3. 不同的MQ的对比
ActiveMQ 老牌消息中间件很多公司运用的很广泛功能强大但是互联网公司的高并发扛不住。一般在传统企业做异步调用系统解耦。RocketMQ 阿里开源的超高并发、高吞吐性能好基于java。rabbitMQ 支持高并发高吞吐性能很高同时有完善的后台管理界面。还支持集群化高可用部署架构功能完善。但是缺点是基于erlang开发不好研究源码。kafka功能少优势在于专为超高吞吐量的实时日志采集实时数据同步实时数据计算等场景来设计。用在日志或者大数据计算方面比较多。
4.为啥使用rabbitMq不用RocketMQ
rocketMQ不够稳定社区活跃度不高rabbitMQ很稳定。
5.MQ有哪些常见问题如何解决
消息的顺序性问题
单线程化。比如一个订单的各种状态下单付款发货如果有多个队列要按照id保证进入一个队列。一个队列对应一个消费者这样就能保证顺序。或者一个队列可以对应多个消费者但是消费者在业务逻辑内部要做判断如果订单还在下单阶段就收到了发货的消息那就只能抛出异常回复nack,让rabbitMQ重发。
消息的重复问题
为了确保每条消息至少成功一次的原则队列里可能一条消息发了多次需要在业务中做幂等性处理。 查询和删除操作天然幂等。增改过程需要特殊处理。 举个例子论坛发帖在打开编辑页面的时候就产生一个token,服务端存在redis,前端也存一份然后发送消息的时候看看redis里有没有这个token有就新增同时把redis的token删掉后面的消息拿着同样的token找不到redis的对应token就是重复消费就丢弃。 再举个例子比如一个订单的各种状态下单付款发货一个字段记录这些状态1-2-3.每次的消息就更改状态消息重复过来了发现状态已经变了那就不再做任何事情。订单新增的时候要在消息里订单里有唯一的id,可以用uuid,用雪花算法redis原子自增等等方式实现。
6. RabbitMQ
一个开源的erlang编写的基于AMQP协议的消息中间件
6.1 RabbitMQ的基本概念 Producer:数据发送方一般一个消息有两个部分有效载荷和标签用标签定位到把消息发送到哪个消费者Broker: 消息队列服务器实体Exchange: 消息交换器从生产者那里收到消息指定一个routing key来指定这个消息的路由规则routing key要和exchange type还有binding key联合使用生效。binding:绑定绑定exchange和queue的同时一般会指定一个binding key。queue 队列 一个message可以被同时拷贝到多个queue中。Connection 一个TCP连接producer和consumer都是通过tcp连接到rabbitMQ server的。channel是建立在上述的tcp连接中的虚拟连接AMPQ连接 如果每一次访问RabbitMQ都建立一个Connection在消息量大的时候建立TCP Connection的开销将是巨大的效率也较低。Channel是在connection内部建立的逻辑连接如果应用程序支持多线程通常每个thread创建单独的channel进行通讯AMQP method包含了channel id帮助客户端和message broker识别channel所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。Consumer 消费方virtual host 虚拟主机多个不同的用户使用一个rabbitmq server 提供的服务时可以划分出多个vhost,每个用户在自己的vhost里面建立exchange/queue.
6.2 RabbitMQ的工作模式
direct 消息的routing key与exchange的某个binding key完全符合则转发到对应的队列中。fanout 如果exchange 收到消息就广播到所有绑定的队列上topic 不需要完全匹配而是符合匹配规则的路由规则即可。#代表任意个单词*代表一个单词
6.3 ack机制
有手动和自动ack的方式一般采用手动。autoAck false服务端在收到ack信号之后才会删除内存或者磁盘中的消息其实是先标记再删除。队列中有两种消息一部分是还没有投递出去的消息一部分已经投递但是还没得到确认的消息。如果没有收到确认消息不会有过期时间所以也就是给消费者充足的处理时间。只有检测到消费者已经断开了才会将消息重新放入队列等待投递给下一个消费者。除了ack,还可以拒绝消息void basicReject(long deliveryTag,boolean requeue);requeue true重新放入队列false直接丢弃
6.4 TTL过期时间
有队列过期时间还有消息过期时间以两者较小为准超过了就过期。DLX Dead-Letter-Exchange,死信交换机当一个消息变成死信就可以发送到另一个交换机就是死信交换机。变成死信三种情况过期被拒绝队列达到最大长度。可以用来分析那些被拒绝的消息转到新的交换机再用新的消费者程序去分析。
6.5 延迟队列
消息放入队列之后并不会立即被消费等待一定时间再消费。场景下单之后十分钟不支付将取消订单订单信息先发送到正常队列里。然后过了时间之后再转到另一个交换机–死信交换机这里再去真正消费。
6.6 生产者确认
如何确认消息成功的发送到了rabbitMQ的Exchange? 可以使用事务机制但是性能太低了。
try{channel.txSelect();channel.basicPublish(xxx);channel.txCommit();
}catch(Exception e){e.printStackTrace();channel.txRollBack();
}生产者确认 生产者将channel设置为confirm模式一旦信道进入comfirm模式所有在该信道上的消息就会有一个从1开始的编号deliveryTag消息到达匹配的队列之后rabbitMQ会发送Basic.ACK给生产者包含那个编号生产者就知道了。 事务机制是阻塞的生产者确认机制是异步的。生产者收到ACK之后可以在回调中处理收到NACK也可以在另一个回调逻辑中处理。
7. 如何保证RabbitMQ消息的可靠传输
不可靠一般的原因就是丢了。丢失可能是生产者丢失消息列表丢失、消费者丢失。生产者丢失就采用事务或者异步confirm机制没收到confirm或者收到nack就重发了。这可能导致消息重复。消息队列丢失数据需要消息持久化配合confirm,持久化磁盘之后再ack,在这之前有问题那么生产者会重发在这之后有问题反正已经持久化了有备份。消费者丢失把ack从自动改为手动处理成功之后ack。造成的消息重复问题一般需要消费者业务上做幂等性处理。
8.如何保证RabbitMQ的高可用
为了确保RabbitMQ的高可用性通常需要考虑以下几个方面 集群部署Clustering 将多个RabbitMQ节点配置成集群可以提供负载均衡和故障转移的能力。在集群模式下消息队列可以分布在多个节点上提高系统的吞吐量。如果一个节点失败其他节点仍然可以继续工作。 镜像队列Mirrored Queues 在RabbitMQ集群中可以设置镜像队列来确保队列中的消息被复制到多个节点。如果一个节点崩溃队列的其他副本可以接管保证消息不丢失。这是通过设置队列的x-ha-policy参数来实现的。 持久化Persistence 对消息和队列进行持久化可以保护数据不会因为服务器崩溃而丢失。将消息标记为持久化通过设置消息的delivery_mode属性为2并确保队列也被声明为持久化可以提高数据的可靠性。 确认和事务机制Acknowledgments and Transactions 使用消息确认机制可以保证消息被正确处理。消费者处理完消息后发送ack确认给RabbitMQ若RabbitMQ没有收到确认它会将消息重新分发给其他消费者。此外RabbitMQ还支持事务性消息处理。 监控和报警Monitoring and Alerting 监控RabbitMQ的运行状况并设置相应的警报机制可以及时发现并解决潜在的问题。可以利用RabbitMQ提供的管理插件来监视队列的长度、消息吞吐量和节点状态。 硬件和基础设施的冗余 在硬件层面确保服务器、存储和网络连接的冗余可以减少单点故障的风险。使用如RAID或SAN等存储方案可以提高存储系统的可靠性。 负载均衡Load Balancing 使用负载均衡器可以分散到集群的连接和流量。这不仅增加了系统的吞吐量也避免了单个节点的过载。 备份和恢复Backup and Recovery 定期备份RabbitMQ的状态包括消息队列的配置和消息数据。在发生灾难性故障时可以用备份快速恢复服务。 升级和补丁管理 定期应用RabbitMQ和操作系统的更新和补丁可以减少因为已知安全问题或软件缺陷导致的服务中断。 故障切换Failover策略 为系统设计故障切换策略以便在节点或组件失败时能够快速恢复服务。
要实现这些策略可能需要对RabbitMQ的高级特性有深入的了解并且在系统设计和运维阶段做出相应的规划和实施。此外持续的性能测试和优化也是确保RabbitMQ高可用的重要环节。
