最简单的 RocketMQ 设计思路（一）
我们需要消息队列干什么
RPC 覆盖不来的场景
都聊 RocketMQ 了，分布式应用就是标配了，那么为什么这里要提一下 RPC 呢？
因为目前服务间通信最常用的两个手段：一是 RCP，二是 MQ。那既然需要使用 MQ，那就来看看 RPC 有哪些问题：
-
RPC 一般是同步请求：
- 假如有一个很耗时的请求，上游调用方可能会超时，拿不到返回结果
- 假如有许多很耗时的请求，甚至会拖垮整个上游服务
- 上游调用方必须知道结果（其实调用方有可能并不关心）
-
RPC 只能点对点通信
- 上游调用方的一个信息很难同时传递给多个下游
- 下游被调用方没有任何主动性，只能给上游提供服务
MQ 恰好可以弥补这些场景
我们来介绍一下 MQ 的特性：
-
上游，也就是 Producer（生产者）只会发出一个信息，那么：
- 下游即便耗时很久，对上游没有影响
- 上游完全不会知道下游处理结果
-
下游，也就是 Consumer（消费者）订阅信息，那么：
-
下游可以主动选择定于哪些消息
-
多个下游可以选择订阅同一个信息
-
需要哪些组件可以完成这些事情
Producer
其实真正的组件是 Poducer 客户端（不同语言需要不同的客户端），但是 Producer 作为上游是一个很重要的概念，暂且放到这里
Consumer
同上
Broker
这个词的中文意思是「掮客」（阿里人真的会起名字），职责是负责传递消息，它是整个 MQ 的核心，技术含量最高的部分。
为什么专门需要一个组件来传递消息呢？
- 由于 MQ 需要支持「异步」和「多次消费」的功能，那么必然需要一个东西来把消息存下来。
- 存储这个功能是 broker 技术复杂的原因
Broker 高可用
目前为止介绍的三个组件，其实已经可以完成我们的需求了。然后我们来解决一下高可用问题
问：broker 挂了怎么办？
答：broker 用主从架构
问：从也挂了怎么办？
答：认倒霉吧（开玩笑）。多机架、多机房部署，降低这种倒霉事儿的发生概率。
问：行，算你过吧（毕竟这个锅已经甩不到程序员头上了）。那 broker 怎么扩容？
答：好问题！那就需要集群部署了，终于可以说 NameServer 了
Nameserve
由于现在 broker 要动态支持节点增加和摘除，为了让 Producer 和 Consumer 可以实时知道有哪些 broker 节点，那么就肯定要用上注册中心了。
RocketMQ 的注册中心就是 NameServer。
据说 RocketMQ 最早使用 zookeeper 当注册中心的，后来才实现了 NameServer。
不过，用什么中间件当注册中心并不重要，因为一般情况下，注册中心对强一致性没有需求，
