RocketMQ自学（对比kafka）---旧文章搬运
source link: https://kairbon.github.io/2021/02/08/RocketMQ%E8%87%AA%E5%AD%A6/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
这是一篇发布于 446 天前的文章，部分信息可能已发生改变，请注意甄别。
RocketMQ自学（对比kafka）—旧文章搬运
消息队列是解耦高并发系统所需要的一种组件（通常为分布式）。分布式保证自身的可用性，从而使得维护的时候可以专心，编写代码可以各司其职，提高整个系统的可靠性和吞吐量。
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也可以做对有序性要求比较高的场景，只要控制好使用同步的主从同步策略，就可以从理论上保证消息的有序性。
MQ作为一种中间件，本身就是为了解耦和突破吞吐瓶颈出现的存在的，因为配置不得当，可能会引入新的问题，所以还是要在合适的场景下选用合适的MQ用合适的架构方案去做这件事。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK