Rocketmq原理&最佳实践
本文主要介绍了RocketMQ的原理和最佳实践，包括MQ背景和选型、RocketMQ的优势特性、RocketMQ、Kafka、RabbitMQ的对比、RocketMQ集群部署等相关内容。
**MQ背景和选型**
消息队列作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。消息队列主要具有以下优势：
1. 削峰填谷：解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题。
2. 系统解耦：解决不同重要程度、不同能力级别系统之间依赖导致一死全死。
3. 提升性能：当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统。
4. 蓄流压测：线上有些链路不好压测，可以通过堆积一定量消息再放开来压测。
**RocketMQ的优势特性**
相比于RabbitMQ、Kafka，RocketMQ具有以下优势特性：
1. 支持事务型消息：消息发送和DB操作保持两方的最终一致性，RabbitMQ和Kafka不支持。
2. 支持结合RocketMQ的多个系统之间数据最终一致性：多方事务，二方事务是前提。
3. 支持18个级别的延迟消息：RabbitMQ和Kafka不支持。
4. 支持指定次数和时间间隔的失败消息重发：Kafka不支持，RabbitMQ需要手动确认。
5. 支持consumer端tag过滤，减少不必要的网络传输：RabbitMQ和Kafka不支持。
6. 支持重复消费：RabbitMQ不支持，Kafka支持。
**RocketMQ、Kafka、RabbitMQ的对比**
| | RocketMQ | Kafka | RabbitMQ |
| --- | --- | --- | --- |
| 事务型消息 | √ | × | × |
| 多方事务 | √ | × | × |
| 延迟消息 | 18个级别 | × | × |
| 失败消息重发 | √ | × | 手动确认 |
| consumer端tag过滤 | √ | × | × |
| 重复消费 | √ | √ | × |
**RocketMQ集群部署**
RocketMQ集群部署结构主要包括NameServer、Broker两个组件。
1. **NameServer**：NameServer是一个几乎无状态节点，可以集群部署，节点之间无任何信息同步。
2. **Broker**：Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。
每个Broker与NameServer集群中的所有节点建立长连接，定时（每隔30s）注册Topic信息到所有NameServer。NameServer定时（每隔10s）扫描所有存活broker的连接，如果NameServer超过2分钟没有收到心跳，则NameServer断开与Broker的连接。
我的内容管理
展开
