189 8069 5689
RocketMQ简单介绍指的是什么，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
创新互联建站成立于2013年，我们提供高端成都网站建设、网站制作公司、成都网站设计、网站定制、网络营销推广、微信小程序、微信公众号开发、营销推广服务，提供专业营销思路、内容策划、视觉设计、程序开发来完成项目落地，为混凝土搅拌罐车企业提供源源不断的流量和订单咨询。
RocketMQ是阿里开源的一款分布式消息中间件，满足线上海量消息堆积的需求， 在2016年底捐赠给Apache开源基金会成为孵化项目，2017年正式成为了Apache顶级项目。是一款纯Java的消息中间件，可靠性、低延迟、可扩展、易于使用的特性而著称。
阿里早期也是基于ActiveMQ 5.x的分布式消息中间件来构建其消息中间件，但是随着主题和队列的增加慢慢的发现ActiveMQ IO模块遇到了瓶颈。我们尽力通过节流，断路器或降级解决这个问题，但效果不佳。因此，我们开始关注当时流行的消息传递解决方案Kafka。不幸的是，Kafka无法满足我们的要求，特别是在低延迟和高可靠性方面。Kafka是一个分布式流媒体平台，它源于日志聚合案例。它不需要太高的并发性。在阿里巴巴的一些大型案例中，我们发现原始模型无法满足我们的实际需求。
RocketMQ起源于最开始阿里的Metaq（ Metamorphosis） 经历过Metaq 1.x、Metaq 2.x、RocketMQ3.x在其3.0版本的时候更名为RocketMQ,目前最新版本为RocketMQ4.5.x。
与其说是RocketMQ的使用场景，不如说是MQ（消息队列）的使用场景，MQ的产品比较多目前比较流行的有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等
MQ 可应用在多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等。
下面列举了一些常用的场景：
一对多，多对多异步解耦，基于发布订阅模型，对分布式应用进行异步解耦，增加应用的水平扩展能力。
削峰填谷，大促等流量洪流突然来袭时，MQ 可以缓冲突发流量，避免下游订阅系统因突发流量崩溃。
日志监控，作为重要日志的监控通信管道，将应用日志监控对系统性能影响降到最低。
消息推送，为社交应用和物联网应用提供点对点推送，一对多广播式推送的能力。
金融报文，发送金融报文，实现金融准实时的报文传输，可靠安全。
电信信令，将电信信令封装成消息，传递到各个控制终端，实现准实时控制和信息传递
主流的MQ的对比RocketMQ 、 ActiveMQ 、 Kafka
| 消息产品 | 客户端SDK | 协议和规范 | 消息存储 | 服务器触发重新传递 | 广播消息 | 高可用性和故障转移 | 消息跟踪 |
|---|---|---|---|---|---|---|---|
| ActiveMQ | Java，.NET，C ++等 | 推模型，支持OpenWire，STOMP，AMQP，MQTT，JMS | 使用JDBC和高性能日志（如levelDB，kahaDB）支持非常快速的持久性 | 不支持 | 支持 | 支持，根据存储，如果使用kahadb，则需要ZooKeeper服务器 | 不支持 |
| Kafka | Java，Scala等 | 拉模型，支持TCP | 高性能文件存储 | 不支持 | 不支持 | 支持，需要ZooKeeper服务器 | 不支持 |
| RocketMQ | Java，C ++，Go | 拉模型，支持TCP，JMS，OpenMessaging | 高性能和低延迟的文件存储 | 支持 | 支持 | 支持的Master-Slave模型，没有其他套件 | 支持 |
Name Server
Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
Broker
Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的Broker Name，不同的Broker Id来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。
每个Broker与Name Server集群中的所有节点建立长连接，定时(每隔30s)注册Topic信息到所有Name Server。Name Server定时(每隔10s)扫描所有存活broker的连接，如果Name Server超过2分钟没有收到心跳，则Name Server断开与Broker的连接。
Producer
Producer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
Producer每隔30s（由ClientConfig的pollNameServerInterval）从Name server获取所有topic队列的最新情况，这意味着如果Broker不可用，Producer最多30s能够感知，在此期间内发往Broker的所有消息都会失败。
Producer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s中扫描所有存活的连接，如果Broker在2分钟内没有收到心跳数据，则关闭与Producer的连接。
Consumer
Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
Consumer每隔30s从Name server获取topic的最新队列情况，这意味着Broker不可用时，Consumer最多最需要30s才能感知。
Consumer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；并向该Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。
当Consumer得到master宕机通知后，转向slave消费，slave不能保证master的消息100%都同步过来了，因此会有少量的消息丢失。但是一旦master恢复，未同步过去的消息会被最终消费掉。
同步发送，线程阻塞，投递completes阻塞结束
如果发送失败，会在默认的超时时间3秒内进行重试，最多重试2次
投递completes不代表投递成功，要check SendResult.sendStatus来判断是否投递成功
发送异步消息需要指定消息发送成功后的回调函数，调用发送消息的API会立刻返回，消息发送者的线程不阻 塞，直到运行结束，消息发送成功或者失败的回调任务在新的线程中执行。
消息不可靠，性能高，只负责往服务器发送一条消息，不会重试也不关心是否发送成功
此方式发送消息的过程耗时非常短，一般在微秒级别
RocketMQ物理部署图：
术语解释
消息主题（Topic）
Topic是生产者在发送消息和消费者在拉取消息的类别。Topic与生产者和消费者之间的关系非常松散。具体来说，一个Topic可能有0个，一个或多个生产者向它发送消息；相反，一个生产者可以发送不同类型Topic的消息。类似的，消费者组可以订阅一个或多个主题，只要该组的实例保持其订阅一致即可。
一个主题对应多个队列（默认4个）
消息是存储在不同的队列中
消费组（ConsumerGroup）
一类 Consumer 的集合名称，组内的 Consumer 通常消费一类消息，消费消息逻辑一致。
一个consumerGroup只对应一个topic
同一个ConsumerGroup中的消费者订阅的主题(Topic)和标签(Tag)必须一致(集群模式下消费会有问题)
一个消息队列只会对应一个消费者
生产组（ProducerGroup）
一类 Producer 的集合名称，组内的 Producer 通常发送一类消息，发送消息逻辑一致
一条消息被多个consumer消费，即使这些consumer属于同一个ConsumerGroup,消息也会被ConsumerGroup中的每个Consumer都消费一次，广播消费中ConsumerGroup概念可以认为在消息划分方面无意义。
一个ConsumerGroup中的Consumer实例平均分摊消费消息。例如某个Topic有9条消息，其中一个ConsumerGroup有3个实例（可能是3个进程，或者3台机器），那么每个实例只消费其中部分，消费完的消息不能被其他实例消费。
看完上述内容，你们掌握RocketMQ简单介绍指的是什么的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！