关于消息队列使用过程中的问题

1. 为什么使用消息队列？

   解耦，异步，削峰

2. 消息队列有什么缺点？

   • 系统可用性降低

     • RabbitMQ如何保证高可用，基于主从模式。RabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式 （高可用）

       镜像集群模式高可用：创建的queue无论是数据还是queue里的消息都会存在于多个实例上，就是说，每个RabbitMQ节点都有这个queue的一个完整镜像。包含queue的全部数据的意思。然后你每次写消息到queue的时候，都会自动把消息同步到多个实例的queue上。

       如何开启这个镜像集群模式呢？其实很简单，RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略

       缺点：数据量大会导致机器崩溃

     • Kafka的高可用

       天然的分布式消息队列 ：kafka由多个broker组成，每个broker是一个节点；创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就存放一部分数据。（HA机制）就是：每个patition会复制多个replica副本到其它机器上。所有的replica会选举一个leader出来。读写都直接跟leader打交道。高可用性体现在如果某个broker宕机了，如果该broker上存在某个patition的leader，那么此时会从follower中重新选举一个leader即可

       写操作：生产者写leader，leader将数据写本地磁盘，接着其他的follower从leader上pull数据形成replica副本，一旦所有的follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者，即只有当一个消息已经被所有的follower都同步成功了消费者才能读到

   • 系统复杂读提高

     • 如何保证消息没有重复消费？

       kafka有offset的概念，消费者会在消费了数据之后每隔一段时间来提交自己消费过的offset，表示我已经提交过了。下次要重启从提交消费到的offset来消费。如果在提交offset过程中导致宕机，会导致消息重发，此时解决思路如下：

       1. 数据库：先查后update
       2. redis: 直接set
       3. 主键约束

     • 怎么处理消息丢失的情况？

       怎么处理消息丢失的情况

     • 怎么保证消息传递的顺序性？

   • 一致性问题