消息队列学习记录

因为项目中使用了消息队列，面试中可能会问到ActiveMQ的相关问题

1. 应用场景
   1.异步处理：例如短信通知、终端状态推送、App推送、用户注册等

   1. 数据同步：业务数据推送同步
      3.重试补偿：记账失败重试
   2. 系统解耦：通讯上下行、终端异常监控、分布式事件中心
      5.流量消峰：秒杀场景下的下单处理
      6.发布订阅：HSF的服务状态变化通知、分布式事件中心
      7.高并发缓冲：日志服务、监控上报

2. 概念

   1. Broker
      Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。
3. 消息的生产者、消费者
   消息生产者Producer：发送消息到消息队列。
   消息消费者Consumer：从消息队列接收消息。

4. 消息的层次
   (1)Topic 一类主题
   (2)每个消息包含多个partition, partition存储到不同的broker上，且每个partition有多个Replica(副本)【Partition 默认每个消息有2个分区，创建Topic可以指定分区数，1天有 1亿行可以分8个分区，如果每天几十 万行就一个分区吧（这里指的是kafka）】
   (3)Message 是每个消息

5. 消息队列模式
   1）点到点模式
   消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

   2）发布-订阅模式
   消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

   Note : 支持订阅组的发布订阅模式

6. 如果消息队列宕机
   持久化（保存到文件、保存到数据库）， 多个节点来备份

5、kafka 如何实现load balance &HA
1）producer 根据用户指定的算法，将消息发送到指定的partition
2）存在多个partition，每个partition存在多个副本replica，每个replica分布在不同的broker节点上
3）每个partition需要选取lead partition，leader partition负责读写，并由zookeeper负责fail over 快速失败
4）通过zookeeper管理broker与consumer的动态加入与离开

6、kafka扩容
当需要增加broker节点时，新增的broker会向zookeeper注册，而producer及consumer会根据zookeeper上的watcher感知这些变化，并及时作出调整

7、ActiveMq 保证高可用
zookeeper + levelDB

参考：
1. http://blog.csdn.net/heyutao007/article/details/50131089
2. https://www.cnblogs.com/tianqing/p/7110468.html
3. https://www.cnblogs.com/oftenlin/p/4045924.html