为什么使用消息队列
消息队列的优缺
1优点

（1） 解耦

（2） 异步

（3） 消峰

2 缺点

（1）系统的可用性降低，系统引入的外部依赖越多，越容易挂掉

（2）系统复杂性提高

（3）数据一致性问题

常用消息队列的优缺点

（1）activeMq 技术非常成熟，但是偶尔会出现较低概率的丢失消息，而且现在社区以及国内应用都越来越少

（2）rabbitMQ 社区相对活跃，吞吐量是万级别，而且开元，性能极好，但是erlang语言阻止了大量的Java程序员深入研究和掌握他，对公司而言几乎是不可控的

（3）rocketMq 10万级别的，rockectMq 也是可以支持高吞吐的一个MQ，topic可以达到几百，几千的级别，可用性非常的高，分布式架构，但是社区有黄的风险。

（4）kafka 特点就是仅仅提供较少的核心功能，但是提供较高的吞吐量，极高的可用性能，而且分布式可以随意的扩展，但是没有重复消费，会对大数据产生一点点影响，特别适合大数据领域的实时计算，日志采集等场景，社区活跃度很高

消息队列的高可用

（1）kafka是天然的分布式消息队列，就是说一个topic的数据，是分散在多个机器上的，每一个机器就放其中的一部分数据，kafka0.8以后，提供了HA机制，就是replica的副本机制，，每一个partition的数据都会同步到其他的机器上，形成自己的多个replica副本，然后所有的replica就会选举一个leader出来，那么生产者和消费者都跟这个leader打交道，然后其他的replica就是flower，leader会负责将数据同步到follower中去，读的时候直接读leader上的数据就行了。这么搞，就有所谓的高可用性了，因为如果摸一个broke砚机了，那么其他的机器上有他的副本，如果时某个partition的leader出现了问题，那么follower就会选举为新的leader，大家就可以继续读写那个新的leader即可，这就是所谓的高可用性。

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

kafka有个offset的概念，就是每次每个消息写进去，都有一个offset，代表他的序号，然后，consumer 消费了数据之后，每隔一段时间，就会把自己消费了的offset提交一下，代表我已经消费过了，下一次要是重启啥的，就会继续从上一次的消费的offset来继续消费，但是假如，有时候 重启系统，就会导致有些还没有来的及处理的消息没有offset，就会导致有些消息会在消费一次。其实重复消费并没有什么，最重要的是保证幂等性，如何消除幂等性的问题

（1）比如，你拿数据库里面的数据，你先跟住主键进行查询一下，如果数据都有了，你就不需要插入了，直接update一下就好了

（2）比如你是写Redis，那就没有问题了，反正每次都是set，天然幂等性

（3）可以使用唯一键进行约束

如何保证数据的可靠性传输

（1）消费端能丢了数据

    就是说消费者消费了消费到消息，然后消费者那边自动提交了offset，让kafka以为你已经消费了数据，但是其实你这边还没有处理，就已经挂了，那么只需要关闭自动提交offset，在处理完成以后自己手动的提交offset，就可以保证数据不会丢失了，但是此时会存在重复消费的问题，这时，只需要保证幂等问题就好了。
    

（2）kafka弄丢了数据

    这是一个比较常见的问题，就是kafka某个broke岩机，然后重新选举某一个partition的leader时，假如此时其他的follower还有一些数据还没有同步，结果leader就已经挂了，然后选举某一个follower成leader后，就会少了一批数据。此时，我们要给topic设置4个参数就好了，
    
    *1 给topic设置replication.factor参数，这个值必须大于1，要求每一个partition必须至少2个副本  ？？
    
    *2 在producer端设置ACKs=all：这是要求每条数据，都必须是写入replica之后，才能认为是写入成功了
    
    *3 在producer端设置retries=max，这就要求一旦写入失败，就无限重试，卡在这里了。
    
    *4 在kafka服务器设置min.insync.replicas参数，这个值必须大于1，这是要求一个leader至少感知到有至少一个follower还和自己进行联系，没有掉队，这样才能保证leader挂了，还有一个follower
    

如何保证数据的有序性

  一个topic，一个partition，一个consumer，内部线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可
  

如何解决消息队列中的时效性问题，消息对列中消息满了怎么办

   扩容
   
    （0）将现有的consumer停掉
   
    （1）新建一个topic，partition是原来的10倍，临时建好原先10倍或20倍的queue数量
    
    （2）写一些临时的分发数据的程序，将程序部署到上面进行消费
    

设计一个MQ系统架构注意点

    （1） 系统可伸缩，就是想要扩容的时候能够扩容，我们可以采用分布式架构
    
    （2） MQ的数据怎样落地到磁盘
    
    （3） MQ的可用性
    
     (4) 保证数据的完整性，以及数据丢失的方案
     

总结 通过以上的学习可以使我们基本了解消息队列的使用。