面试系列之-rocketmq组件及关系
组件
broker
理解成rocketmq本身，broker主要用于producer和consumer接收和发送消息；broker会定时向nameserver提交自己的信息；是消息中间件的消息存储、转发服务器；每个Broker节点，在启动时，都会遍历NameServer列表，与每个NameServer建立长连接，注册自己的信息，之后定时上报；
broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave；Master也可以部署多个，每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server；
nameserver
理解成zookeeper的效果，只是他没用zk，而是自己写了个nameserver来替代zk；底层由netty实现，提供了路由管理、服务注册、服务发现的功能，是一个无状态节点；nameserver是服务发现者，集群中各个角色（producer、broker、consumer等）都需要定时向nameserver上报自己的状态，以便互相发现彼此，超时不上报的话，nameserver会把它从列表中剔除；nameserver可以部署多个，当多个nameserver存在的时候，其他角色同时向他们上报信息，以保证高可用，；NameServer集群间互不通信，没有主备的概念；nameserver内存式存储，nameserver中的broker、topic等信息默认不会持久化，所以他是无状态节点；
NameServer路由注册、删除机制
- Broker每30秒向NameServer发送心跳包，心跳包中包含topic的路由信息；
- NarneServer收到Broker心跳包后，更新brokerLiveTable中的信息， 特别记录心跳时间lastUpdateTime；
- NarneServer每隔10s扫描brokerLiveTable， 检 测表中上次收到心跳包的时间，比较当前时间与上一次时间，如果超过120s，则认为broker不可用，移除路由表中与该broker相关的所有信息；
- 消息生产者拉取主题的路由信息，即消息生产者并不会立即感知Broker服务器的新增与删除；
producer
消息的生产者随机选择其中一个NameServer节点建立长连接，获得Topic路由信息（包括topic下的queue，这些queue分布在哪些broker上等等）；接下来向提供topic服务的master建立长连接（因为rocketmq只有master才能写消息），且定时向master发送心跳；
Producer Group
- 标识一类Producer；
- 可以通过运维工具查询返个収送消息应用下有多个Producer实例；
- 发送分布式事务消息时，如果Producer中途意外宕机，Broker会主动回调Producer Group内的任意一台机器来确认事务状态；
consumer
消息的消费者通过NameServer集群获得Topic的路由信息，连接到对应的Broker上消费消息；由于Master和Slave都可以读取消息，因此Consumer会与Master和Slave都建立连接进行消费消息；
Consumer Group
一个Consumer Group下的多个Consumer以均摊方式消费消息，如果设置为广播方式，那么这个Consumer Group下的每个实例都消费全量数据；
组件交互的核心流程
- Broker都注册到Nameserver上；
- Producer发消息的时候会从Nameserver上获取发消息的topic信息；
- Producer向提供服务的所有master建立长连接，且定时向master发送心跳；
- Consumer通过NameServer集群获得Topic的路由信息；
- Consumer会与所有的Master和所有的Slave都建立连接进行监听新消息；
核心概念
queue
每个主题可设置队列个数，自动创建主题时默认4个，需要顺序消费的消息发往同一队列，队列会平均分散在多个Broker上，Producer的发送机制保证消息尽量平均分布到所有队列中，最终效果就是所有消息都平均落在每个Broker上队列可以动态伸缩，扩大该topic的队列数；
1个Topic会被分为N个Queue，数量是可配置的；message本身其实是存储到queue上的，消费者消费的也是queue上的消息；比如1个topic4个queue，有5个Consumer都在消费这个topic，那么会有一个consumer浪费掉了，因为负载均衡策略，每个consumer消费1个queue，5>4，溢出1个，这个会不工作；
tag
Topic的进一步细分标，每个发送的时候消息都能打tag，消费的时候可以根据tag进行过滤，选择性消费；
消费模式
集群模式（Clustering）
- 每条消息只需要被处理一次，broker只会把消息发送给消费集群中的一个消费者；
- 在消息重投时，不能保证路由到同一台机器上；
- 消费状态由broker维护；
一个Consumer Group中的Consumer实例平均分摊消费消息；例如某个Topic有 9 条消息，其中一个Consumer Group有3个实例（可能是3个进程，或者3台机器），那举每个实例只消费其中的3消息；
广播模式（Broadcasting）
- 消费进度由consumer维护；
- 保证每个消费者都消费一次消息；
- 消费失败的消息不会重投；
一条消息被多个Consumer消费，即使返些Consumer属亍同一个Consumer Group，消息也会被 Consumer Group中的每个Consumer都消费一次，广播消费中的Consumer Group概念可以讣为在消息划分方面无意义；
顺序消息
消费消息的顺序要同収送消息的顺序一致，在RocketMQ中，主要指的是头部顺序，即一类消息为满足顺序性，必须Producer单线程顺序发送，且发送到同一个队列，这样Consumer就可以按照Producer发送的顺序去消费消息；
普通顺序消息
顺序消息的一种，正常情况下可以保证完全的顺序消息，但是一旦发生通信异常，Broker重启，由于队列总数发生发化，哈希取模后定位的队列会发化，产生短暂的消息顺序不一致；如果业务能容忍在集群异常情况（如某个Broker宕机或者重启）下，消息短暂的乱序，使用普通顺序方式比较合适；
严格顺序消息
顺序消息的一种，无论正常异常情况都能保证顺序，但是牺牲了分布式Failover特性，即Broker集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大降低；如果服务器部署为同步双写模式，此缺陷可通过备机自切切换为主避免，不过仍然会存在几分钟的服务不可用。（依赖同步双写，主备自动切换，自动切换功能目前还未实现）目前已知的应用只有数据库binlog同步强依赖严格顺序消息，其他应用绝大部分都可以容忍短暂乱序，推荐使用普通的顺序消息；