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) 保证数据的完整性，以及数据丢失的方案

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