RocketMQ系列(一)简介

一 .RocketMQ简介

MQ简介

消息中间件有两种模型

  • 队列模型 (RocketMQ)
  • 主题模型(也叫发布订阅模型)(RabbitMQ)

RocketMQ

MQ(Message Queue)消息队列,是一种用来保存消息数据的队列
◆ 队列:数据结构的一种,特征为 “先进先出”
在这里插入图片描述

何为消息

  • 服务器间的业务请求
    • 原始架构:
      • 服务器中的A功能需要调用B、C模块才能完成
    • 微服务架构
      • 服务器A向服务器B发送要执行的操作(视为消息)
      • 服务器A向服务器C发送要执行的操作(视为消息)

MQ作用

  • 应用解耦(异步消息发送)
  • 快速应用变更维护(异步消息发送)
  • 流量削锋(异步消息发送)

MQ基本工作模式

在这里插入图片描述

MQ优缺点分析

  • 优点(作用)
    • 应用解耦
    • 快速应用变更维护
    • 流量削锋
  • 缺点
    • 系统可用性降低
    • 系统复杂度提高
    • 异步消息机制
      • 消息顺序性
      • 消息丢失
      • 消息一致性
      • 消息重复使用

MQ产品介绍

  • ActiveMQ:java语言实现,万级数据吞吐量,处理速度ms级,主从架构,成熟度高

  • RabbitMQ :erlang语言实现,万级数据吞吐量,处理速度us级,主从架构,

  • RocketMQ :java语言实现,十万级数据吞吐量,处理速度ms级,分布式架构,功能强大,扩展性强

  • kafka :scala语言实现,十万级数据吞吐量,处理速度ms级,分布式架构,功能较少,应用于大数据较多

  • RocketMQ是阿里开源的一款非常优秀中间件产品,脱胎于阿里的另一款队列技术MetaQ,后捐赠给Apache基金会作为一款孵化技术,仅仅经历了一年多的时间就成为Apache基金会的顶级项目。并且它现在已经在阿里内部被广泛的应用,并且经受住了多次双十一的这种极致场景的压力(2017年的双十一,RocketMQ流转的消息量达到了万亿级,峰值TPS达到5600万)

  • 解决所有缺点

二.MQ概念

RockMQ组成

RocketMQ主要由

  • NameServer(命名服务)
  • Broker(经纪人–消息服务)
  • Producer (消息生产者)
  • Consumer (消息服务者)四部分构成。

NameServer(命名服务)的功能

  • 管理brokers:broker服务器启动时会注册到NameServer上,并且两者之间保持心跳监测机制,以此来保证NameServer知道broker的存活状态;
  • 路由信息管理:每一台NameServer都存有全部的broker集群信息和生产者/消费者客户端的请求信息;
NameServer用于存储Topic、Broker关系信息, 功能简单,稳定性高。
多个NameService之间没有通信, 单台NameService宕机不影响其他
NameServer与集群; 即使整个Namesrv集群宕机,已经正常工作的
Producer, Consumer,Broker仍然能正常工作,但新起的Producer,
 Consumer,Broker就无法工作。

注意: nameServer压力不会太大, 平时主要的开销是在维持心跳提供brock-topic的关系数据.但有一点需要注意,Broker向Namesr发心跳时,会带上当前自己所负责的所有Topic信息,如果Topic个数太多(万级别),会导致一次心跳中,就Topic的数据就几十M,网络情况差的话,网络传输失败,心跳失败,导致Namesrv误认为Broker心跳失败。

Broker(消息服务)

消息中转角色,负责存储消息,转发消息。

  • Broker是具体提供业务的服务器,单个Broker节点与所有的NameServer节点保持长连接及心跳,并会定时将Topic信息注册到NameServer,顺带一提底层的通信和连接都是基于Netty实现的。
  • Broker负责消息存储,以Topic为纬度支持轻量级的队列,单机可以支撑上万队列规模,支持消息推拉模型
  • 官网上有数据显示:具有上亿级消息堆积能力,同时可严格保证消息的有序性。

Broker(消息服务)作用

  • 负载均衡: Broker上存Topic信息,Topic由多个队列组成,队列会平均分散在多个Broker上,而Producer的发送机制保证消息尽量平均分布到所有队列中,最终效果就是所有消息都平均落在每个Broker上。
  • 动态伸缩能力(非顺序消息): Broker的伸缩性体现在两个维度:Topic, Broker。

Producer (消息生产者)

Producer启动时,

  • 需要指定Namesrv的地址(通常会配置NameServer集群的域名),从Namesrv集群中选一台建立长连接。
  • 如果该Namesrv宕机,会自动连其他Namesrv。直到有可用的Namesrv为止。生产者每30秒从Namesrv获取Topic跟Broker的映射关系,更新到本地内存中。再跟Topic涉及的所有Broker建立长连接,每隔30秒发一次心跳。

RocketMQ提供三种发送方式:

  • 同步:在广泛的场景中使用可靠的同步传输,如重要的通知信息、短信通知、短信营销系统等。
  • 异步:异步发送通常用于响应时间敏感的业务场景,发送出去即刻返回,利用回调做后续处理。
  • 一次性:一次性发送用于需要中等可靠性的情况,如日志收集,发送出去即完成,不用等待发送结果,回调等等

生产者端的负载均衡
生产者发送时,会自动轮询当前所有可发送的broker,一条消息发送成功,下次换另外一个broker发送,以达到消息平均落到所有的broker上。

Consumer(消息消费者)

消费客户端的连接方式和生产者类似。

消费者端的负载均衡

  • 广播消费:每个消费者消费Topic下的所有队列。
  • 集群消费 :一个topic可以由同一个ID下所有消费者分担消费。
    具体例子:假如TopicA有6个队列,某个消费者ID起了2个消费者实例,那么每个消费者负责消费3个队列。如果再增加一个消费者ID相同消费者实例,即当前共有3个消费者同时消费6个队列,那每个消费者负责2个队列的消费。

消费者端的负载均衡,就是集群消费模式下,同一个ID的所有消费者实例平均消费该Topic的所有队列。

消息收发模型

在这里插入图片描述

在这里插入图片描述

  • 生产者
  • 消费者
  • 消息服务器
  • 命名服务器
  • 消息
    • 主题
    • 标签
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值