MQ的优点和缺点?
优点:解耦 异步,削峰
解耦:
所以需要用来解耦:
异步:
解决方法:
削峰:
解决方法是:
缺点:降低高可用性.增加系统的复杂程度.一致性问题
降低高可用的原因:系统引入的外部依赖越多,越容易挂掉,本来你就是A系统调用BCD三个系统的接口就好了,现在又加入一个mq,万一mq挂掉了,整个系统也就崩溃了.
增加系统的复杂程度:硬生生的增加一个MQ进来怎么保证不被重复消费?怎么保证不会出现消息丢失的情况?怎么保证消息传递的顺序性?
一致性问题:系统A处理完以后直接返回成功了,人家都认为你这个请求成功了,但问题是,要是BCD三个系统成功了,结果C系统写库失败了,咋整?数据就不一致了.
如果发生丢消息的时候怎么解决?
同时还可以采用mq手动签到的方式,client真的接收到了消息,才签到,否则就不能签到,直接接收再签到.
怎么保证MQ不会重复发送消息?
采用的是一张表来记录消息处理的状态,在处理MQ发送的消息的时候,我先查看一下这张表,是不是处理过相同的消息.如果发送过,就不在发送.
MQ重复消费的问题
1.首先产生mq重复消费的问题的原因
2.如何解决mq的重复消费问题
mq消息的顺序是怎么进行保证的?
消息被发送的时候保持顺序
消息被存储的时候保持和发送的顺序的一致
消息被消费的时候保持和存储的消息顺序一致.
1. 引入消息队列之后如何保证其高可用性?
（1）RabbitMQ的高可用性
RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解第一种MQ的高可用性怎么实现。
rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
（1.2）普通集群模式
意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。