初识RocketMQ

RocketMQ(MessageQueue)本质上就是一个Queue，FIFO，传递消息。

1. 实现一个最简单的"MQ"
2. 已经有一个Queue了，如果突然发送一个新类型的消息，一定要有对应的接收者，有以下处理方式 相比而言，将不同Message放在不同Queue中更容易管理，不会因为实例B停止读取消息而导致实例A无法读取消息
3. 虽然有多种处理方式，最终还是发现直接添加一整套可以降低消息之间的影响，此时面临一个新问题：处理消息的高并发 如果接收者处理消息较慢，考虑添加几个实例，以上两种方案区别在于负载均衡的实现，保证Queue的职责单一，所以选择在发送方实现负载均衡，最常见的就是轮询，依次往Queue中放入消息。当然，一个实例可以对应多个Queue，主要取决于实例的性能
4. 此时消费同一个消息的多个实例，就是一个消费者组，对于消息消费来说，"消费者组"这个概念是不可或缺的，因为实例可能下线，比如实例C下线后，只需要把原来C负责的队列交给B，这个调节消费者实例与队列对应关系的过程就是消费者端的负载均衡
5. A消费者组拿到消息后用来实现A功能，如果该消息还有其他场景需要使用，则添加一个消费者组即可 此时两个小组都消费这个消息，并且互不影响
6. 到现在为止，一直是同一个JVM中，如果想要跨JVM就需要RPC 用RPC隔开Queue之后，将分散的Queue放在一起管理，就是RocketMQ中Broker的原型
7. 按照这个思路，再次添加一个新类型的消息，也可以一并放在Broker中管理，目前为止已经有一个MQ的基本模型了
8. 可以发现Broker是MQ最重要的部分，集群实现高可用与高并发：
   1. 高可用：Master-Slave,Slave完全复制Master中的消息，Master挂了之后自动替换Slave
   2. 高并发：多Master，把Queue分到不同Master中，最好根据Topic平均分，以避免不同Topic数据量不同影响Master性能
9. 现在已经对一个消息队列有了初步设计，接下来就是如何实现。