原文链接:https://juejin.im/post/6844904078862974984
消息队列在互联网技术存储方面使用如此广泛,几乎所有的后端技术面试官都要在消息队列的使用和原理方面对小伙伴们进行360°的刁难。
什么,这么多问题啊!别慌,现在就来找找解决方案。
主流的MQ都有高可用模式可以供我们选择!
RabbitMQ可以使用镜像模式搭建高可用集群,可以配置数据同步到所有节点还是指定数量的节点以满足实际需求。
RocketMQ、Kafka天然的是分布式设计让他们天然具有高可用的技能^^ RocketMQ有多master多slave异步复制模式、多master多slave同步双写模式多种集群部署模式可以选择 多master多slave模式部署架构图:
Producer与NameServer集群中的其中一个节点(随机选择)建立长连接,定期从NameServer获取Topic路由信息,并向提供Topic服务的Broker Master建立长连接,且定时向Master发送心跳。Producer只能将消息发送到Broker master。
Consumer则不一样,它同时与提供Topic服务的Master、Slave建立长连接,既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。
Kafka的架构与RocketMQ十分相似
Zookeeper的的作用与NameServer的作用相似, 用于保存集群配置、选举Leader等。
集群中有许多broker用于堆积消息,Kafka支持水平扩展,一般broker数量越多,集群吞吐率越高。
Producer使用push模式将消息发布到broker。
Consumer使用pull模式从broker订阅并消费消息。
现在消息队列一般都能保证at least once的,也就是消息至少一次投递。 在这种情况为什么会出现重复消费的问题呢? 通常都是由于网络原因造成的,原因如下: 通常消息被成功消费后消费者都会发送一个成功标志给MQ,MQ收到这个标志就表示消息已经成功消费了,就不会再发送给其他消费者了。 但是如果因为网络这个标志没有送到MQ就丢失了,MQ就认为这个消息没有被成功消费,就会再次发送给其他消费者消费,就造成了重复了。
这时我们看这个问题就变成了我们怎么保证消费端的幂等性。
幂等性 是指一个操作其执行任意多次所产生的影响均与一次执行的影响相同 大白话就是你同样的参数调用我这个接口,调用多少次结果都相同
幂等性需要根据业务需求来具体看,但是主要的原理就是去重 一般可分为强校验、弱校验
有些消息怎么跑着跑着就没了呢?
一般来讲消息丢失的途径有三个:
顺序消息的场景可能用的比较少,但是还是有的 比如一个电商的下单操作,下单后先减库存然后生成订单,这个操作就需要顺序执行的 那怎么保证顺序呢?
通过上面的连招基本就能解决顺序消息消费的问题了呢!
原文:https://www.cnblogs.com/fswhq/p/13790655.html