rocketMQ的基本认识

MQ：message queue 是一种提供消息队列服务的中间件，是一套提供了消息生产、存储、消费全过程API的软件系统。也就是事件驱动中的broker消息即数据。

MQ用途： 限流削峰：mq可以将系统的超量请求暂存其中，以便系统后期可以慢慢进行处理，从而避免了请求的丢失或系统被压垮。

                 异步解藕：上游系统对下游系统的调用若为同步调用，则会大大降低系统的吞吐量和并发度，且系统耦合度太高。而异步调用会解决这些问题。所以俩层之间要实现由同步到异步的转化，一般性做法就是，在这俩层添加一个MQ层。

                 数据收集：分布式系统会产生海量级数据流，如：日志，监控等。针对这些数据流进行大数据分析，这是当前互联网平台的必备技术。通过MQ完成此类数据收集是最好的选择。

MQ常见协议：JMS（Java Messaging Service）：Java消息服务、STOMP（Streaming Text Orientated Message Protocol）：面向流文本的消息协议、AMQP（Advanced Message Queuing Protocol）：高级消息队列协议、MQTT（Message Queuing Telemetry Transport）：消息队列遥测传输。

  Kafka和rocketMQ都没有遵循以上协议，都是遵循的自主研发的协议。吞吐量：Kafka的单机吞吐量最高，追求极致。消息延迟：rabbitMQ是微秒级。消息可靠：rabbitMQ和rocketMQ都高。

下面是对rocketMQ中基本概念的解释：

    消息：消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个topic主题。

    topic主题：表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是rocketMQ进行消息订阅的基本单位。      

   queue队列：存储消息的物理实体。一个topic中可以包含多个queue，每个queue中存放的是该topic的消息。 就是说一个topic包含若干个queue，一个queue包含若干条消息。

消费者与topic中queue的关系：(下面几条关系只适用于broker集群关系，不适用于广播关系)

    1、在同一个消费者组下的消费者，不能同时消费同一个queue。

    2、一个消费者组下的消费者，可以同时消费同一个topic下的不同队列的消息。

    3、不同消费者组下的消费者，可以同时消费同一个topic下的相同队列的消息。

    4、同消费者组下的消费者，不可以同时消费不同topic下的消息。

  broker事件代理者：异步调用常见实现就是事件驱动模式。服务让broker在事件被触发时通知该服务，这个过程叫做订阅事件。当某个服务实现了特定事件时，broker就会通知与它订阅的哪几个服务。这整个过程所有服务都是异步的。

充当着消息中转角色，负责存储消息，转发消息。broker在rocketMQ系统中负责接收并存储从生产者发来的消息，同时为消费者拉取请求作准备。

  producer消息生产者：负责消息消息。producer通过MQ的负载均衡块选择相应的broker集群列进行消息投递，投递的过程支持快速失败并且低延迟。rocketMQ中的消息生产者都是以生产者组的形式出现的。一个生产者组中的每个生产者都可以发送多种topic类型的消息，且每个生产者能发送的这多种topic完全相同。

  consumer消息消费者：负责消费消息。一个消息消费者会从broker服务器中获取消息，并对消息进行相关业务处理。rocketMQ中的消息消费者都是以消费者组的形式出现的。这类consumer消费的是同一个topic类型的消息。消费者组似的在消息消费方面，实现负载均衡（是queue的负载均衡，不是消息的）和容错（一个消息者在消费一个queue过程中崩了，该消费者组中的另一个消费者会接受这个未消费完的queue继续消费，而不是从头开始消费）的目标变得非常容易。

  

  nameServer：是一个broker与topic路由的注册中心，支持broker的动态注册与发现。本人感觉这个nameServer和 Eureka和nacos很类似。

    nameServer俩个功能：1、broker管理：接收broker集群的注册信息并保存下来作为路由信息的基本数据；提供心跳检测机制，检查broker是否还活着

          2、路由信息管理：每个nameServer中都保存着broker集群的整个路由信息和用于客户端查询的队列消息。producer和consumer通过nameServer可以获取整个broker集群的路由消息，从而进行消息的投递和消费。

nameServer的运行流程：

    路由注册：nameService通常也是以集群的方式部署的，不过，nameService是无状态的，即nameService集群中的各个节点是无差异的，各节点互相不进行信息通讯，不会有数据同步。在broker节点启动时轮询nameService列表，与每个nameService节点建立长连接，发起注册请求。在nameService内部存储着一个broker列表，用来动态存储broker的信息。   缺点：broker必须指明所有nameService地址，否则未指出的将不会注册。

                    broker节点为了证明自己是活着的，为了维护与nameService之间的长连接，会将最新的信息以心脏包的方式上报给nameService，每30秒发送一次心跳。心跳中包括：brokerId、broker地址、broker名称、broker所属集群名等等。

    路由剔除：当broker关机、宕机或网络抖动。nameService没有收到broker心跳，就会被剔除。一般broker剔除是这么运用的：在rocketMQ日常运维时（如，升级），需要停掉broker的工作。OP（运维人员）需要将broker的读写权限禁掉。这时客户端向该broker发送请求，客户端会收到broker的NO_PERMISSION响应，然后客户端会对其他broker的重试。当OP观察到这个broker中没有流量后，才会关闭这个broker。实现剔除。

  路由发现：rocketMQ的路由发现采用的是pull模型。当topic路由出现变化时，nameService不会主动推送给客户端，而是客户端定时拉取主题最新的路由。默认是客户端每30s拉取一次最新路由。

  消息产生过程：

    producer发送消息之前，会先向nameService发送获取消息topic的路由消息请求。

    namService返回该topic的路由表及broker列表。

    producer根据代码中指定的queue选择策略，从queue列表中选出一个队列，用于后续存储消息。producer对消息做一些特殊处理。

    producer向选择的queue所在broker发送RPC请求，将消息发送到选择的queue。

路由表：实际是个map，key为topic名称，value是一个queueData实例列表（涉及该topic的brokerName列表）。queueData并不是一个queue对应一个queueData，而是一个broker中该topic的所有queue对应一个queueData。

broker列表：也是一个map。key为brokerName，value为brokerData。一组brokerName名称相同的小集群对应一个brokerData。brokerData中包含一个map，该map的key为brokerId，value为该broker对应的地址。