kafka消息队列

摘要：为什么使用消息队列消息队列的优缺优点解耦异步消峰缺点系统的可用性降低，系统引入的外部依赖越多，越容易挂掉系统复杂性提高数据一致性问题常用消息队列的优缺点技术非常成熟，但是偶尔会出现较低概率的丢失消息，而且现在社区以及国内应用都越来越少社区相

为什么使用消息队列
消息队列的优缺
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) 保证数据的完整性，以及数据丢失的方案
     

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