初探消息队列

Posted chenchaochao034

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了初探消息队列相关的知识,希望对你有一定的参考价值。

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

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

       概述

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

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

  应用场景

  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消息队列的使用。

 

以上是关于初探消息队列的主要内容,如果未能解决你的问题,请参考以下文章

SpringBoot:初探 RabbitMQ 消息队列

NoSQL初探之人人都爱Redis:使用Redis作为消息队列服务场景应用案例

RABBITMQ初探——消息分发

Rabbitmq学习 Rabbitmq初探

初探篇初识消息队列 & RocketMQ

初探Apache ActiveMQ