消息队列概要总结-快速了解消息队列

消息队列
   -优点和缺点
    优点：解耦合，异步，销峰
    缺点：可用性降低，复杂性提高，难以保证一致性
    
   -几种常见的消息队列
     ActiveMQ：吞吐量万级，较低概率丢数据，成熟但是社区不活跃了
     RabbitMQ：吞吐量万级，erlang语言开发，主从架构，管理界面非常好，社区活跃
     RocketMQ：吞吐量十万级，零丢失数据，阿里开源，分布式好拓展
     Kafka：吞吐量十万级，主要用于实时计算和日志采集，易拓展
     
   -如何保证高可用
     RabbitMQ
     1. RabbitMQ普通集群模式 实际上不能保证高可用 
     queue元数据存在于所有RabbitMQ结点,实际数据在其中一个RabbitMQ节点上
     不含有实际数据的RabbitMQ节点在收到请求时，先从有实际数据的节点上获取数据，再给客户端
     2. RabbitMQ镜像集群模式
      queue元数据和实际数据存在于所有节点，生产者在修改某个节点上的数据时，之后会同步到其它节点
      缺点：需要在所有节点上都有数据 很耗费空间 非分布式
     Kafka
     每个机器上都有broker进程,创建topic之后，默认分成3个partition，每个partition包含topic
     的一部分数据，partition存在于不同机器
     可能存在的问题：某个partition丢失，topic就不完整了
     改进：每个partition都备份到不同机器上，一个leader，一个follower，只有leader可以对外提供读写
          leader崩掉了之后，follower成为leader
          
   -如何保证消息不被重复消费(消息消费的幂等性
     每个消息都有一个偏移量，消费数据时检查这个偏移量，消费者消费消息之后通过zookeeper告诉
     生产者，但是并不是消费一个就告诉一个，而是累积等一段时间统一通知
     可能存在的问题：消费者没来得及通知，就宕机了...重启之后，生产者没收到通知，重
                  发送消息
     解决：消费者自己检查是否收到重复的消息，比如用set判断，数据库唯一性约束
     
   -如何保证消息不丢失
     问题：生产者发送消息异常，RabbitMQ收到消息之后挂了，消费者收到消息还没来得及处理，但是已经通知消费成功了
     生产者方面：事务，confirm机制(RabbitMQ成功或失败发送消息会告诉生产者
     RabbitMQ方面：持久化机制
     消费者方面：把autoACK关闭，确定消费完，处理完才发送ACK
     
   -如何解决顺序不一致
     问题：多个消费者连接一个队列，消息到达消费者之后，不同的消费者以错乱的顺序插入数据库
     解决：一个消费者连接一个队列，需要保证顺序的消息放到其中一个队列里，只被一个消费者消费
     
   -如何解决消息大量积压
     问题：消费者挂了 不消费了 大量消息积压在队列里
     解决：设置更多消费者