RocketMQ

RocketMQ做为一款纯java、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。

专业术语
Producer
消息生产者，生产者的作用就是将消息发送到MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到MQ。
Producer Group
生产者组，简单来说就是多个发送同一类消息的生产者称为一个生产者组。
Consumer
消息消费者，简单来说，消费MQ上的消息的应用程序就是消费者，至于消息是否进行逻辑处理，还是直接存储到数据库等取决于业务需要。
Consumer Group
消费者组，和生产者类似，消费同一类消息的多个consumer实例组成一个消费者组。
Topic
Topic是一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单Topic存放订单相关的消息，一个是库存Topic存储库存有关的消息。
Message
Message是消息的载体。一个Message必须指定topic，相当于寄信的地址。Message还有一个可选的tag设置，以遍消费端可以基于tag进行过滤消息。也可以添加额外的监支队，例如你需要一个业务key来查找broker上的消息，方便在开发过程中诊断问题。
Tag
标签可以被人为是对Topic进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。
Broker
Broker是RocketMQ系统的主要角色，其实就是前面一直说的MQ。Broker接受来自生产者的消息，储存以及为消费者拉去消息的请求做好准备。
Name Server
Name Server为prodecer和consumer提供路由信息。
RocketMQ以Topic来管理不同应用的消息，对于生产者而言，发送消息时需要指定消息的Topic，对于消费者而言，在启动后需要订阅相应的Topic，而后可以消费相应的消息。Topic是逻辑上的概念，在物理实现上，一个Topic有多个Queue组成，采用多个Queue的好处是可以将Broker存储分布化，提高系统性能。
NameServer的功能，在RocketMQ的前身是使用ZooKeeper。NameServer用于管理所有Broker结点信息，接收Broker的注册、注销请求，此外还记录了Topic与Broker、Queue的对应关系，Broker主背信息。BrokerId为0代表是MasterBroker，否者BrokerId大于0的表示为SlaveBorker，Master和Slave组成一个Broker，具有相同的brokerName。Broker在启动的时候回去NameServer进行注册，会维护Broker的存活状态，Broker每次发送心跳过来的时候都会把Topic信息带上。NamesrvStartUp为启动类、NamesrvController为控制类、RouteInfoManager存放了Topic队列信息以及地址列表等一些列重要数据结构并提供了对应的数据变更接口、DefaultRequestProcessor负责处理所有borker发过来的所有网络消息。各NameServer之间的相互独立且没有通信的，通过给Broker的namesrvAddr配置多个NameServer地址，同时向多个NameServer注册信息来实现NameServer集群。因为NameServer读写压力比较小，所以稳定性高。相应的生产者、消费者中的namesrvAddr也是配置多个。
Broker，每个Broker都会和NameServer建立一个长连接保持心跳。一个Topic分布在多个Broker上，一个Broker可以配置多个Topic。由与消息分布在各个Broker上，一旦某个Broker宕机，则该Broker上的消息读取都受到影响。所以需要HA机制，R哦创可贴MQ的实现 方式是master/slave，slave定时从master同步数据，如果master宕机，则slave提供消费服务，但是不能写入消息。一旦某个borker master宕机，生产者和消费者多久才能发现？受限于rocketmq的网络连接机制，默认情况下，最多需要30秒，但这个时间可由应用设定参数来缩短时间。这个时间段内，发往该broker的消息都是失败的，而且该broker的消息无法消费，因为此时消费者不知道该broker已经挂掉。消费者得到master宕机 通知后，转向slave消费，但是slave不能保证master的消息100%都他on改不过来了，因此会有少量的消息丢失。但是消息最后不会丢的，一旦master恢复，未同步过去的消息会被消费掉。
一台Broker上所有的消息都是记录在一个CommitLog上，CommitLog里面记录了每条消息的消费情况，是否被消费，由谁消费，该消息是否持久化等消息，每个消息的长度是不一样的。每个Slave是有一个单独的线程顺序同步CommitLog，所谓的等待同步Slave成功后才返回，市值是等待同步线程下标到了指定下标而已，所以Master和Slave的CommitLog文件内容及顺序都是一直的。CommitLog中存储的消息格式已经制定到该消息对应的topic及存到consumerQueue中对应的topic的那个队列，究竟写入那个consumerqueue的那个queueid，这是由客户端投递消息的时候指定的，客户端做的负载均衡，选择不同的queueid投递。一般来说客户端是轮巡queue投递消息，但如果要保证消息顺序，原来就是客户端把相关消息投递到同一个queueid，这样消费者消费的时候就是顺序读取了。只要消息到了CommitLog，发送的消息也就不会丢，有后台线程一步的同步到ConsumerQueue，再有Consumer进行消费。ConsumerQueue是消息的逻辑队列，相当于字典的目录，用来指定消息在物理文件CommitLog上的位置。也就是说CommitLog只是一个顺序写，但是ConsumerQueue确有多个随机读，ConsumerQueue与Topic对应