初探消息队列

　　首先我们要知道为什么需要消息队列？它能给我们解决什么问题？

　　答案很简单，消息队列是用来处理系统出现高并发导致消息阻塞的情况，如果你的系统不存在高并发或者不会出现消息阻塞，那你就不需要消息队列。

       概述

       消息队列中间件是分布式系统中的重要组件，可帮助解决应用耦合、消息异步、流量削峰等问题。

       因为其高性能、高可用性及可伸缩性，消息队列已经成为大型分布式系统不可缺少的中间件。目前常用的ActiveMQRabbitMQKafkaeroMQ等。

　　应用场景

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

　　这个地方总结的比较简练，如果不是很理解细节可以看看其他博客，会有图文并茂的解释。

　　

　　消息模型 

　　有两种消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。

　　 P2P模式

　　P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。

　　P2P的特点：
　　　　1、每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
　　　　2、发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
　　　　3、接收者在成功接收消息之后需向队列应答成功
　　如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式。

　　Pub/Sub模式

　　包含三个角色主题（Topic），发布者（Publisher），订阅者（Subscriber） 多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

　　Pub/Sub的特点：
　　　　1、每个消息可以有多个消费者
　　　　2、发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息
　　　　3、为了消费消息，订阅者必须保持运行的状态
　　　　4、为了缓和这样严格的时间相关性，允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。
　　如果希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型。

 　　消息消费

　　消息的产生和消费都是异步的。对于消费来说，消费者可以通过两种方式来消费消息。
（1）同步
订阅者或接收者通过receive方法来接收消息，receive方法在接收到消息之前（或超时之前）将一直阻塞；

（2）异步
订阅者或接收者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的onMessage方法。

 　　主流消息队列对比：

　　后面就以性能很高的Kafka为例进行下介绍。

　　在一套 Kafka 架构中有多个 Producer，多个 Broker，多个 Consumer，每个 Producer 可以对应多个 Topic，每个 Consumer 只能对应一个 Consumer Group。

　　整个 Kafka 架构对应一个 ZK 集群，通过 ZK 管理集群配置，选举 Leader，以及在 Consumer Group 发生变化时进行 Rebalance。

 

　　消息队列的基础就讲解到这里，我已经在腾讯云申请了一个云服务器，也已经安装了kafka消息队列，后面我将用实际操作来给大家演示kafka消息队列的使用。