关于RabbitMQ的一些问题总结
消息中间件在工作中一般都不会采用单机模式的，该篇其实是对mq的高可用等等常见问题做一些归纳。
消息队列的高可用
普通集群与镜像集群模式，此处不做深究，另开一篇专门讲述此处
如何保证消息不被重复消费
保证消息队列幂等性，为什么会造成重复消费，正常消费时消费者在消费消息时候，消费完毕会发送一个确认信息给消息队列，消息队列知道该消息被消费，将其删除，RabbitMQ发送一个ACK确认消息，重复消费的原因，因为网络传输等故障，ack并没有传送到消息队列，消息队列不知道该消息已经消费过了，再次分发该消息
- 用该消息做数据库insert操作，负责对该消息做一个唯一主键，重复消费时，数据库中主键冲突，就不会产生脏数据
- 用该消息做redis set 操作，无论set 本来具备幂等性
- 准备第三方介质做消费记录。redis 给消息分配全局id，消费过该消息将其写入，以k-v 形式写入redis，消费者在开始消费前，应该先去redis中查询有无消费记录
如何保证消费的可靠性传输
- 生产者丢数据 rabbitmq提供transaction 以及 confirm模式确保生产者不丢消息，tralnsaction机制，在发送消息前，开启事务channel.txSe，然后发送消息，发送过程中出现异常，事务回滚，缺点是吞吐量下降；confirm模式，一旦channel进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID，消息被投递到所匹配队列后，rabbitmq就会发送一个Ack给生产者，生产者知道消息以及正确到达目标队列，若rabbitMQ没能处理该消息，则会发送一个Nack消息，可进行重试操作
- 消息队列丢数据 开启持久化磁盘配置，持久化配置可与confirm机制配合使用，消息持久化磁盘后，再给生产者ACK消息，则在持久化磁盘之前，RabbitMQ挂了，生产者就收不到Ack信号，就会自动重发；持久化设置，queue 持久化标识durable设置为true，代表为持久队列，发送消息时deliveryModel =2
- 消费者丢数据 自动确认消息模式，消费者会自动确认收到消息，RabbitMQ会立即将消息删除，消费者出现异常没有处理该消息，则丢失该消息，改为手动确认即可
如何保证消息的顺序性
- 通过算法将需要保持先后顺序的消息放到同一个消息队列中，只用一个消费者去消费
- 为了吞吐量，多个消费者去消费的情况，例如在发微博，写评论三个异步操作，一个消费者先执行写评论的操作，微博未发，则写评论是失败的，等另一个消费者，先执行写微博的操作，再执行就可以成功，保持入队的有序性，出队以后顺序交给消费者自己去保证
