学前小故事
有一天，产品跑来说：“我们要做一个用户注册功能，需要在用户注册成功后给用户发一封成功邮件。”
小明（攻城狮）：“好，需求很明确了。” 不就提供一个注册接口，保存用户信息，同时发起邮件调用，待邮件发送成功后，返回用户操作成功。没一会功夫，代码就写完了。验证功能没问题后，就发布上线了。
线上正常运行了一段时间，产品匆匆地跑来说：“你做的功能不行啊，运营反馈注册操作响应太慢，已经有好多用户流失了。”
小明听得一身冷汗，赶紧回去改。他发现，原先的以单线程同步阻塞的方式进行邮件发送，确实存在问题。
这次，他利用了 JAVA 多线程的特性，另起线程进行邮件发送，主线程直接返回保存结果。测试通过后，赶紧发布上线。小明心想，这下总没问题了吧。
没过多久，产品又跑来了，他说：“现在，注册操作响应是快多了。但是又有新的问题了，有用户反应，邮件收不到。能否在发送邮件时，保存一下发送的结果，对于发送失败的，进行补发。”
小明一听，哎，又得熬夜加班了。产品看他一脸苦逼的样子，忙说：“邮件服务这块，别的团队都已经做好了，你不用再自己搞了，直接用他们的服务。”
小明赶紧去和邮件团队沟通，谁知他们的服务根本就不对外开放。这下小明可开始犯愁了，明知道有这么一个服务，可是偏偏又调用不了。
邮件团队的人说，“看你愁的，我给你提供了一个类似邮局信箱的东西，你往这信箱里写上你要发送的消息，以及我们约定的地址。之后你就不用再操心了，我们自然能从约定的地址中取得消息，进行邮件的相应操作。”
后来，小明才知道，这就是外界广为流传的消息队列。你不用知道具体的服务在哪，如何调用。你要做的只是将该发送的消息，向你们约定好的地址进行发送，你的任务就完成了。
对应的服务自然能监听到你发送的消息，进行后续的操作。这就是消息队列最大的特点，将同步操作转为异步处理，将多服务共同操作转为职责单一的单服务操作，做到了服务间的解耦。
哈哈，这下能高枕无忧了。太年轻，哪有万无一失的技术啊~
不久的一天，你会发现所有业务都替换了邮件发送的方式，统一使用了消息队列来进行发送。这下仅仅一个邮件服务模块，难以承受业务方源源不断的消息，大量的消息堆积在了队列中。这就需要更多的消费者（邮件服务）来共同处理队列中的消息，即所谓的分布式消息处理。
消息中间件
-
定义
由于系统的耦合性越高导致容错性就降低，故使用消息队列解耦，若出故障，将要处理的数据被缓存到消息队列中即可
目前在生产环境，使用较多的消息队列有
• ActiveMQ
• RabbitMQ
• ZeroMQ
• Kafka
• MetaMQ
• RocketMQ -
产品对比
产品 开发语言 单机吞吐量 时效性 可用性 特性 ActiveMQ java 万级 ms级 高(主从架构) ActiveMQ 成熟的产品，在很多公司得到应用;有较多的文档;各种协议支持较好 RabbitMQ erlang 万级 us级 高(主从架构) RabbitMQ 基于erlang开发，所以并发能力强，性能极其好，延时很低，管理界面较丰富 RocketMQ java 10万级 ms级 非常高(分布式架构) RocketMQ MQ功能比较完备，扩展性佳 Kafka scala 10万级 ms级以内 非常高(分布式架构) Kafka 只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广 -
优缺点
解耦、削峰、数据分发的同时也存在着系统可用性降低、系统复杂度提高、一致性问题 这三个方面缺点。
• 系统可用性降低：系统引入的外部依赖越多，系统稳定性越差。一旦MQ宕机，就会对业务造成影响
• 系统复杂度提高: 以前系统间是同步的远程调用，现在是通过MQ进行异步调用。如何保证消息没有被重复消费、怎么处理消息丢失情况、如何保证消息传递的顺序性。
• 一致性问题: A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统、C系统处理完成、D处理失败、如何保证消息数据处理的一致性。
rocketmq架构
RocketMQ 整体架构设计主要分为四大部分，分别是：
• Producer：消息生产者，它会先和 NameServer 集群中的随机一台建立长连接，得知当前要发送的 Topic 存在哪台 Broker Master上，然后再与其建立长连接，支持多种负载平衡模式发送消息
• Consumer：消息消费者，它会先和 NameServer 集群中的随机一台建立长连接，得知当前要消息的 Topic 存在哪台 Broker Master、Slave上，然后它们建立长连接，支持集群消费和广播消费消息
• NameServer： Topic 路由注册中心，支持 Broker 的动态注册和发现，保存 Topic 和 Borker 之间的关系，而各 NameServer 之间不会互相通信， 各 NameServer 都有完整的路由信息，即无状态
• Broker：负责存储消息、查询消费，一个 Master 可以对应多个 Slave，Master 支持读写，Slave 只支持读。Broker 会向集群中的每一台 NameServer 注册自己的路由信息。
工作流程：
先启动 NameServer 集群，各 NameServer 之间无任何数据交互。
Broker 启动之后会向所有 NameServer 定期（每 30s）发送心跳包，包括：IP、Port、TopicInfo，NameServer 会定期扫描 Broker 存活列表，如果超过 120s 没有心跳则移除此 Broker 相关信息，代表下线。
这样每个 NameServer 就知道集群所有 Broker 的相关信息，此时 Producer 上线从 NameServer 就可以得知它要发送的某 Topic 消息在哪个 Broker 上，和对应的 Broker （Master 角色的）建立长连接，发送消息。
Consumer 上线也可以从 NameServer 得知它所要接收的 Topic 是哪个 Broker ，和对应的 Master、Slave 建立连接，接收消息。
消息生产者
-
定义
负责创建消息发送给Broker，一般由业务系统负责产生消息
RocketMQ默认提供了DefaultMQProducer、TransactionMQProducer用于发送消息
内含 a.Producer Group: 是一组Producer的名称。通常来说一个业务系统可能会奉陪一个Producer Group。 Producer Group后续可以用于消息发送相关的各项管理监控功能。 b.Message: RocketMQ中的消息。Message必须设置Topic以及消息体，除此之外还可以配 置一些自定义属性。只要不超过预定义的消息大小，自定义属性可以任意添加。 c.Message Model: 消息投递存在两种不同类别， d.Tag: Message可以设置Tag，Tag是系统预定义的属性。Message设置了Tag之后，在消费的时候 可以根据Tag进行过滤。RocketMQ提供了几种过滤方式。可以认为Tag是Message的二级类别 -
消息发送方式
• 同步发送：消息发送方发出数据后，会在接收响应之后才发下一个数据包
• 异步发送：异步发送是指发送方发出数据后，无需等待响应，接着发送下个数据包
• 单向发送：发送方只负责发送消息，不等待回应且没有回调函数触发
消息消费者
-
Consumer
含义 消息消费者，用于从消息队列获取消息。常用的Consumer类 内含 a.DefaultMQPushConsumer， 收到消息自动调用传入的处理方法来处理，实时性高。 b.DefaultMQPullConsumer 用户自主控制，灵活度更高。 c.Push Consumer: 服务端向消费端推送消息 d.Pull Consumer: 消费端向服务端定时拉取消息 e.Consumer Group : 是一组Consumer的名称.相同Group下的Consumer需要有同样的订阅关系，且消费逻辑一致 否则消息投递的时候可能会出现一些难以排查的问题。 Consumer Group同样用于分配给不同的业务系统。通过管理工具可以控制Group的消费范围
NameServer
-
NameServer
含义 解释一:RocketMQ没有引入第三方服务依赖，消息队列内部的服务发现以及配置更新等，都 借由Name Server来完成。从功能上来说，Name Server相当于一个轻量级简化版 的Zookeeper，或者说提供了类似ZK的功能。 Name Server的定位是维护RocketMQ全局相关配置，提供消息路由信息，除此之外 并不包含过多复杂逻辑。因为其相对轻量级，一般一组Name Server集群可以服务多 组Broker集群。 Name Server Cluster是多个Name Server实例的统称，Name Server之间并无关 联，互相也不同步信息。多个Name Server的存在是为了提供高可用服务，不同实例之 间的数据信息同步则实际是在数据写入的时候保证的。一份配置或消息路由信息会写入 所有Name Server实例中。 解释二:相当于配置中心，维护Broker集群、Broker信息、Broker存活信息、主题与 队列信息等。NameServer彼此之间不通信，每个Broker与集群内所有NameServer 保持长连接 通信机制 1.Broker启动后需要完成一次将自己注册到NameServer的操作；随后每隔30秒时间定时向 NameServer更新Topic路由信息 2.Producer发送消息时，需要根据消息的Topic从本地缓存的获取路由信息。如果没有则 更新路由信息，会从NameServer重新拉取，同时Producer会默认每隔30秒向NameServer 拉取一次路由信息 3.Consumer消费消息时，从NameServer获取的路由信息，并再完成客户端的负载均衡后，监听 指定消息队列获取消息并进行消费
Broker
-
Broker
含义 Broker是具体提供业务的服务器， 解释一:RocketMQ的核心逻辑是Broker。Broker是实际用于手法消息的功能单元。从RocketMQ 使用者的角度来看，生产者通过接口将消息投递到Broker，消费者从Broker获取消息进行消费。 RocketMQ提供了推拉结合的方式用于获取消息。 解释二:单个Broker节点与所有的NameServer节点保持长连接及心跳， 并会定时将Topic信息注册到NameServer，顺带一提底层的通信和连接都是基于Netty实现的。 Broker中分master和slave两种角色，每个master可以对应多个slave， 但一个slave只能对应一个master，master和slave通过指定相同的Brokername， 不同的BrokerId （master为0）成为一个组。 master和slave之间的同步方式分为同步双写和异步复制， 异步复制方式master和slave之间虽然会存在少量的延迟， 但性能较同步双写方式要高出10%左右 举例：邮局 。它是RocketMQ的核心，用于接收Producer发过来的 消息、以及处理Consumer的消费消息请求、消息的持久化存储、服务端过滤功能等 另外，Broker中还存在一些非常重要的名词需要说明： 内含 a.Topic: 区分消息的种类，一个发送者可以发送消息给一个或者多个Topic，一个消息的接受者可以 订阅一个或者多个Topic消息。对于RokectMQ而言，Topic只是一个逻辑上的概念， 真正的消息存储其实是在Topic中的Queue中。这要设计是为了消息的顺序消费， b.Message Queue: 相当于是Topic的分区，用于并发发送和接受消息
集群
-
集群模式
单Master模式 这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上 环境使用，可以用于本地测试 多Master模式 一个集群无Slave，全是Master，例如2个Master或者3个Master，这种模式的优缺点是 优点：配置简单，单个Master宕机或重启维护对应无影响，在磁盘配置为PAID10时，即时 机器宕机不可恢复情况下，由于PAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量 消息，同步刷盘一条不丢），性能最高。 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实
最低0.47元/天 解锁文章
947
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
