rabbitMq-kafka消息高可用，一致性

本文部分的理解参考和转载自:https://www.jianshu.com/p/7a6deaba34d2

1：rabbitmq

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

单机模式：自己本地搭着玩玩就好了

普通集群模式：就是部署多态机器，启动多个rabbitMq实例，治标不治本，就是通过服务器的数量来提高某个queue读写操作

每个节点上都会同步数据，节点上数据太大，只能再次增加机器去扩展，陷入死循环。。。

镜像集群模式：这个才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

缺点性能开销太大，每次都需要去同步所有节点的信息(如何开启：控制台可以自行开启镜像策略)

---

2：kafka(天然的分布式消息队列)

1、主题（Topic）：一个主题类似新闻中的体育、娱乐、教育等分类概念，在实际工程中通常一个业务一个主题。

2、分区（Partition）：一个Topic中的消息数据按照多个分区组织，分区是kafka消息队列组织的最小单位，一个分区可以看作是一个FIFO（ First Input First Output的缩写，先入先出队列）的队列。

kafka分区是提高kafka性能的关键所在，当你发现你的集群性能不高时，常用手段就是增加Topic的分区，分区里面的消息是按照从新到老的顺序进行组织，消费者从队列头订阅消息，生产者从队列尾添加消息

---

3：如何保证消息的一致性(一般来说是重复消费的问题)

不管 rabbitmq、rocketmq、kafka这些消息中间件如何怎么样，在实际的业务场景中都逃脱不了一个问题，就是如何保证消息的一致性？

kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，可以理解成一个自增持的序号，一个个排下来

然后消费者consumer，每隔一段时间，就把自己消费过的消息提交一下，如果说出现宕机或者重启，则会继续从上次消费的序号接着往下排，继续消费

但是有的时候，消费者consumer消费的消息，由于各种原因，比如网络、宕机、停电。。。都没来得及写offset
这个时候就悲剧了，就会发生重复消费的问题

这个时候，我们可以用一个唯一的id标识来区分，比如简单点的说，你消费一个就往数据库插入一条记录，然后下次再去消费的时候，你去查一下，看看这个消息是否被消费了，消费了那就不要重复消费了。

（补充一下：确认一条数据在百万级别海量数据里是否存在？--可以用布隆过滤器）

所以说一般的这种消息一致性，不是这种消息中间件去做的，而是业务模块自己去保证消息的一致性，自己结合自己的业务场景去设计一套逻辑，来保证不要重复的消费消息。

---

4消息的丢失

分为几种情况：

      4.1：生产者自己丢失了消息(网络故障啊，发送失败啊)

      解决方案：

rabbitmq：一般这种都是采用回调接口的方案，就是说你扔一个消息过去了，对方给你一个回调接口，告诉你成功了或者失败了，失败了你可以选择继续扔消息， (重试机制等)，来保证消息一定送达
kafka：主要靠一些配置来保证选角leader的时候不会丢下数据

     4.2：消息中间件弄丢了消息

    解决方案：以rabbitmq来说，你只要开启持久化就好了，当发生宕机的时候，queue会自动从磁盘恢复数据

       如果说你的数据还没来得及写入磁盘就挂了，那就惨了。。。这个时候 ack

---

5：MQ由于某种原因积压了大量的数据        

   5.1比如消费者挂掉了，没有去消费消息，生产者还不停的往队列里扔消息

      这个时候，简单粗暴的就是赶紧去把consumer给修理好，让他去慢慢消费，这种比较慢（如果积压的数据量太大的话）

     可以临时写个脚本或者想其他方法去快速的把这批消息给消费掉

-------------有的时候，mq里可能有消息失效的机制就是消息过期了，长时间没人用了，这个时候你倒霉了，只能自己再去找消息，然后临时写个代码，自己再手动的去把这些消息重新推送到队里 去吧。