RocketMQ自学（对比kafka）—旧文章搬运
1. MQ
消息队列是解耦高并发系统所需要的一种组件（通常为分布式）。分布式保证自身的可用性，从而使得维护的时候可以专心，编写代码可以各司其职，提高整个系统的可靠性和吞吐量。
2. RocketMQ
简介
RocketMQ是阿里巴巴开源，apache旗下的一个MQ，他的可选模式多种多样，适合各种场景去使用。
分布式架构
RocketMQ分布式架构
RocketMQ的分布式架构挺有特点的，抛开nameserver，最关键的就是在broker的配置上,主要分为以下几种模式：
- 单master，只有一个broker节点，可用性最低，且容易导致整个系统宕机。
- 多master，一个集群全为master，问题：当一台master挂掉时，在其上的信息队列会不可用。注意：写入磁盘的时候宕机可能会有丢失数据的风险。
- 多master多salve模式，每个master配置一个salve，做主从同步。但主从同步也有异步同步和同步同步的区别，要根据不同的场景去选择，有着不同的优缺点。注意，如果m-s对中，master挂掉时候生产者无法向该topic提交，但消费者可以消费。
因为大部分MQ我们在使用的时候要注意的东西其实偏顶层，但分析一下分布式架构就可以在使用的时候更清楚。
这里我们用kafka的分布式架构来进行对比：
kafka分布式架构对比
kafka在broker和topic之间引入了一个partition的概念，这个partition有点RAID1的味道，但完全不一样，因为这个使用网络进行同步，所以会有延迟，因此为了追求数据的线性一致性，就舍弃了topic粒度下的负载均衡，让对同一个topic生产和消费都从leader partition中获取。
当然如果每个topic的内容差不多，这种是没问题的，但如果为了追求可用性，当单一topic会非常热门的话，就有可能成为性能瓶颈。
当然这种情况最适合的场景就是实时通信软件，message的生产和消费每一个topic都比较均衡。并且这种的有序的保证是最高的。
但RocketMQ也可以做对有序性要求比较高的场景，只要控制好使用同步的主从同步策略，就可以从理论上保证消息的有序性。
3. 总结
MQ作为一种中间件，本身就是为了解耦和突破吞吐瓶颈出现的存在的，因为配置不得当，可能会引入新的问题，所以还是要在合适的场景下选用合适的MQ用合适的架构方案去做这件事。