消息队列

1.如何保证消息队列的高可用性

RabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式

2.如何保证消息消费时的幂等性（重复消费）

其实消息重复消费的主要原因在于回馈机制（RabbitMQ是ack，Kafka是offset)，在某些场景中我们采用的回馈机制不同，原因也不同，例如消费者消费完消息后回复ack, 但是刚消费完还没来得及提交系统就重启了，这时候上来就pull消息的时候由于没有提交ack或者offset，消费的还是上条消息。

那么如何怎么来保证消息消费的幂等性呢？实际上我们只要保证多条相同的数据过来的时候只处理一条或者说多条处理和处理一条造成的结果相同即可，但是具体怎么做要根据业务需求来定，例如入库消息，先查一下消息是否已经入库啊或者说搞个唯一约束啊什么的，还有一些是天生保证幂等性就根本不用去管，例如redis就是天然幂等性。

3.如何保证消息的可靠性传输

（1）生产者弄丢了数据
一般来说，如果你要确保说写RabbitMQ的消息别丢，可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了RabbitMQ中，RabbitMQ会给你回传一个ack消息，告诉你说这个消息ok了。如果RabbitMQ没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。

（2）RabbitMQ弄丢了数据
就是RabbitMQ自己弄丢了数据，这个你必须开启RabbitMQ的持久化，就是消息写入之后会持久化到磁盘。

（3）消费端弄丢了数据

RabbitMQ如果丢失了数据，主要是因为你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，那么就尴尬了，RabbitMQ认为你都消费了，这数据就丢了。

这个时候得用RabbitMQ提供的ack机制，简单来说，就是你关闭RabbitMQ自动ack，可以通过一个api来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。这样的话，如果你还没处理完，不就没有ack？那RabbitMQ就认为你还没处理完，这个时候RabbitMQ会把这个消费分配给别的consumer去处理，消息是不会丢的。

4.如何保证消息的顺序性

（1）rabbitmq
①拆分成多个queue，每个queue一个consumer，要求顺序的消息都发送到同一个queue，就是多一些queue而已，确实是麻烦点

5.大量消息在mq里积压了几个小时了还没解决

临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据。

6 rabbit消息队列模型

①基本消息模型：生产者->队列->消费者
②工作队列模型：生产者->队列->多个消费者（让多个消费者绑定到一个队列，共同消费队列中的消息。队列中的消息一旦消
费，就会消失，因此任务是不会被重复执行的）
③订阅模型：

解读：

1、1个生产者，多个消费者

2、每一个消费者都有自己的一个队列

3、生产者没有将消息直接发送到队列，而是发送到了交换机

4、每个队列都要绑定到交换机

5、生产者发送的消息，经过交换机到达队列，实现一个消息被多个消费者获取的目的

X（Exchanges）：交换机一方面：接收生产者发送的消息。另一方面：知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。

Exchange类型有以下几种：

 Fanout：广播，将消息交给所有绑定到交换机的队列

 Direct：定向，把消息交给符合指定routing key 的队列

 Topic：通配符，把消息交给符合routing pattern（路由模式）的队列

Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！