共计 2981 个字符，预计需要花费 8 分钟才能阅读完成。
@TOC
MQ 笔记
MQ 之支流 MQkafaka+RocketMQ+RabbitMQ 比照：https://blog.csdn.net/weixin_…
MQ 之 RocketMQ 常见谬误：https://blog.csdn.net/weixin_…
MQ 之 RocketMQ 专业术语：https://blog.csdn.net/weixin_…
MQ 之 RocketMQ 环境具体配置：https://blog.csdn.net/weixin_…
？RocketMQ 是什么
RocketMQ 是阿里巴巴在 2012 年开源的分布式消息中间件，目前曾经捐献给 Apache 基金会，并于 2016 年 11 月成为 Apache 孵化我的项目。
中间件是一类连贯软件组件和利用的计算机软件，它包含一组服务。以便于运行在一台或多台机器上的多个软件通过网络进行交互。中间件技术所提供的互操作性，推动了分布式体系架构的演进，该架构通常用于反对并简化那些简单的分布式应用程序，它包含 web 服务器、事务监控器和音讯队列软件。中间件 (middleware) 是根底软件的一大类，属于可复用软件的领域。顾名思义，中间件处于操作系统软件与用户的应用软件的两头。中间件在操作系统、网络和数据库之上，应用软件的上层，总的作用是为处于本人下层的应用软件提供运行与开发的环境，帮忙用户灵便、高效地开发和集成简单的应用软件。
中间件是位于平台（硬件和操作系统）和利用之间的通用服务，这些服务具备规范的程序接口和协定。针对不同的操作系统和硬件平台，中间件能够有合乎接口和协定标准的多种实现。
RcoketMQ 是一款低提早、高牢靠、可伸缩、易于应用的消息中间件。具备以下个性：
- 反对公布 / 订阅（Pub/Sub）和点对点（P2P）音讯模型
- 在一个队列中牢靠的先进先出（FIFO）和严格的程序传递
- 反对拉（pull）和推（push）两种音讯模式
- 繁多队列百万音讯的沉积能力
- 反对多种音讯协定，如 JMS、MQTT 等
- 分布式高可用的部署架构, 满足至多一次消息传递语义
- 提供 docker 镜像用于隔离测试和星散群部署
- 提供配置、指标和监控等功能丰富的 Dashboard
RocketMQ 主体
主体分为四个角色
生产者 Producer
音讯生产者，生产者的作用就是将音讯发送到 MQ，生产者自身既能够产生音讯，如读取文本信息等。也能够对外提供接口，由内部利用来调用接口，再由生产者将收到的音讯发送到 MQ。
衍生概念：Producer Group
生产者组，多个发送同一类音讯的生产者称之为一个生产者组。
消费者 Consumer
音讯消费者，生产 MQ 上的音讯的应用程序就是消费者
衍生概念：Consumer Group
消费者组，生产同一类音讯的多个 consumer 实例组成一个消费者组
音讯 Message
Message 是音讯的载体。一个 Message 必须指定 topic，相当于寄信的地址。Message 还有一个可选的 tag 设置，以便生产端能够基于 tag 进行过滤音讯。也能够增加额定的键值对，例如你须要一个业务 key 来查找 broker 上的音讯，不便在开发过程中诊断问题。
衍生概念：Topic Tag
Topic
Topic 是一种音讯的逻辑分类，比如说你有订单类的音讯，也有库存类的音讯，那么就须要进行分类，一个是订单 Topic 寄存订单相干的音讯，一个是库存 Topic 存储库存相干的音讯。
Tag
标签能够被认为是对 Topic 进一步细化。个别在雷同业务模块中通过引入标签来标记不同用处的音讯。
兼顾者
注册核心 Name Server
Name Server 为 producer 和 consumer 提供路由信息
经纪人 Broker
Broker 是 RocketMQ 零碎的次要角色，其实就是后面始终说的 MQ。Broker 接管来自生产者的音讯，贮存以及为消费者拉取音讯的申请做好筹备
RocketMQ 架构
RocketMQ 架构
由这张图能够看到有四个集群，别离是 NameServer 集群、Broker 集群、Producer 集群和 Consumer 集群：
- NameServer: 提供轻量级的服务发现和路由。每个 NameServer 记录残缺的路由信息，提供等效的读写服务，并反对疾速存储扩大。
- Broker: 通过提供轻量级的 Topic 和 Queue 机制来解决音讯存储, 同时反对推（push）和拉（pull）模式以及主从构造的容错机制。
- Producer：生产者，产生音讯的实例，领有雷同 Producer Group 的 Producer 组成一个集群。
- Consumer：消费者，接管音讯进行生产的实例，领有雷同 Consumer Group 的 Consumer 组成一个集群
简略阐明一下图中箭头含意，从 Broker 开始，Broker Master1 和 Broker Slave1 是主从构造，它们之间会进行数据同步，即 Date Sync。同时每个 Broker 与 NameServer 集群中的所有节点建设长连贯，定时注册 Topic 信息到所有 NameServer 中。
Producer 与 NameServer 集群中的其中一个节点（随机抉择）建设长连贯，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建设长连贯，且定时向 Broker 发送心跳。Producer 只能将音讯发送到 Broker master，然而 Consumer 则不一样，它同时和提供 Topic 服务的 Master 和 Slave
建设长连贯，既能够从 Broker Master 订阅音讯，也能够从 Broker Slave 订阅音讯。
RocketMQ 部署模式
单 master 模式
也就是只有一个 master 节点，称不上是集群，一旦这个 master 节点宕机，那么整个服务就不可用，适宜集体学习应用。
多 master 模式
多个 master 节点组成集群，单个 master 节点宕机或者重启对利用没有影响。
长处：所有模式中性能最高
毛病：单个 master 节点宕机期间，未被生产的音讯在节点复原之前不可用，音讯的实时性就受到影响。
留神：应用同步刷盘能够保障音讯不失落，同时 Topic 绝对应的 queue 应该散布在集群中各个节点，而不是只在某各节点上，否则，该节点宕机会对订阅该 topic 的利用造成影响。
多 master 多 slave 异步复制模式
在多 master 模式的根底上，每个 master 节点都有至多一个对应的 slave。master
节点可读可写，然而 slave 只能读不能写，相似于 mysql 的主备模式。
长处：在 master 宕机时，消费者能够从 slave 读取音讯，音讯的实时性不会受影响，性能简直和多 master 一样。
毛病：应用异步复制的同步形式有可能会有音讯失落的问题。
- 多 master 多 slave 同步双写模式
同多 master 多 slave 异步复制模式相似，区别在于 master 和 slave 之间的数据同步形式。
长处：同步双写的同步模式能保证数据不失落。
毛病：发送单个音讯 RT 会略长，性能相比异步复制低 10% 左右。
刷盘策略：同步刷盘和异步刷盘（指的是节点本身数据是同步还是异步存储）
同步形式：同步双写和异步复制（指的一组 master 和 slave 之间数据的同步）
留神：要保证数据牢靠，需采纳同步刷盘和同步双写的形式，但性能会较其余形式低。
继续更新中。。。
参考链接：
https://www.jianshu.com/p/824…
