RocketMQ —— 优点及基础理论
更深入的了解RocketMQ一些优点，以及队列的基础知识。
设计优点
| 优点 | 描述 |
|---|---|
| 支持分布式 |
原生支持分布式,ActiveMQ原生存在单点 |
| 严格的消息顺序 | 保证严格的消息顺序，ActiveMQ无法保证 |
| 海量消息低延迟 | RocketMQ支持亿级消息堆积能力，并可以保证亿级消息写入时打到低延迟
|
| 消息拉取模式 | 1. PUSH：消费者端设置Listener2. PULL：应用可主动从Broker获取消息，主动拉取会存在消费记录位置问题（如果不记录位置，会出现重复消费）
|
| 分布式协调 | Metaq1.x/2.x版本，分布式协调采用Zookeeper，RocketMQ通过自己实现NameServer达到分布式协调，更轻量，由于自主实现，更贴近框架，性能更好
|
| 其它 | 消费重试机制、高效订阅者水平扩展功能、API（多语言）、分布式事务机制等！ |
[Producer / Consumer] GROUP
RocketMQ中有一个“组”机制，此机制很重要，如下图：通过组机制(Group)，RocketMQ可以天然支持分布式。如下所示：如上图所示，某个Topic有9条消息，Consumer Group有三个实例（3个进程或3台机器），9条消息就会均摊到每个实例上（3条/个）!
【RocketMQ只有一个模式 ———— 发布订阅模式！】
RocketMQ 集群部署模式
| 描述 | |
|---|---|
| 单Master模式 |
单点，Broker重启或宕机，队列就失效了，生产一定要避免单点，所以不考虑
|
| 多Master模式 | 由于是复数Master，当某台Broker宕机，新到消息是不会受影响，但由于没有Slave，会出现只有将宕机Master重启之后，才可以消费掉宕机Master上的消息，如果生产消息队列较少，并且对时间要求不严苛，可以考虑。
|
多Master多Slave(异步复制) |
高可用模式！ 采用异步复制方式，主备之间短暂延迟。Master宕机可以在Slave消费，但是Master宕机，会导致少量消息丢失。常用投产解决方案之一
|
多Master多Slave(同步双写) |
和异步复制方式的区别在于，采用的是同步方式。在Master/Slave都写成功后向应用返回成功，无论是数据还是服务都不存在单点，可靠性强！不过同步性能比异步较低！
|