市面上MQ的简单对比
| 指标 | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|
| 单机吞吐量 | 1w量级 | 10w量级 | 10w量级 |
| 开发语言 | Erlang | Java | Java和Scala |
| 消息延迟 | 微秒 | 毫秒 | 毫秒 |
| 消息丢失 | 可能性很低 | 参数优化后可以0丢失 | 参数优化后可以0丢失 |
| 消费模式 | 推拉 | 推拉 | 拉 |
| 主题数量对吞吐量的影响 | \ | 上千的主题会有一点影响 | 上百之后会对MQ的吞吐量有很大影响 |
| 可用性 | 高(主从) | 很高(主从) | 很高(分布式) |
选择MQ中间件的标准应该从以下三个指标去衡量：
- 消息传输的可靠性，保证消息不会丢失
- 支持集群，包括横向扩展，单点故障都可以解决
- 性能要好，要能够满足业务的性能需求
RocketMQ消息模型
点对点，一对一
producer --> topic --> consumer
pub/sub，一对多
producer --> topic --> consumer1
--> consumer2
.
.
提高MQ的写入能力
producer --> topic --> MsgQueue1 --> consumer
--> MsgQueue2
.
.
一个topic对应这个queue，这样写入时就可以往多个队列中写，以提高写入的能力，否则如果多个producer同时往一个topic中写，必然会存在竞争的问题。其实就是减小锁的粒度，这个思想其实很常见，比如：ConcurrentHashMap vs HashTable，行锁 vs 表锁
提高消费的能力
producer --> topic --> MsgQueue --> [consumerGroup1] consumer1
[consumerGroup1] consumer2
[consumerGroup2] consumer1
[consumerGroup2] consumer2
定义一个消费组（负载均衡和广播两种）的概念，比如同一个group中的两个不同的consumer跑在不同的线程中，这样可以将一个topic中的消息负载均衡到不同的consumer中，来提高消费的能力。广播就是一个消费组内所有的consumer都能收到该topic的消息
RocketMQ部署模型
- Producer Cluster：生产者集群
- Consumer Cluster：消费者集群
- Broker Cluster：代理服务器
- NameServer Cluster：名字服务器
producer发送消息和consumer接受消息的过程：
- 启动NameServer，默认端口为9876，等待Broker、Producer、Consumer的链接
- 启动Broker，与所有的NameServer（NameServer必须是一个集群，因为开始时Producer和Consumer向Topic写数据或者读数据时，都需要从NameServer中获取Topic与Broker的关系，因此NameServer一定要保证高可用性，而RocketMQ中的做法也比较简单粗暴，一个个NameServer相当于多个副本，这样某一个或者某些挂了服务还可用）保持长连接，定时（默认30s）发送心跳包，包中包含了当前Broker的信息以及存储所有Topic的信息
- 创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic
- 生产者发送消息。启动时先跟NameServer集群中的其中一台（这里只需要一台建立长连接就可以了）建立长连接，并从NameServer中获取当前发送的Topic存在于哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息
- 消费者接受消息。跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，然后开始消费消息。
windows启动RocketMQ
- 启动NameServer
mqbroker.cmd -n localhost:9876 autoCreateTopicEnable=true- 可以通过简单的可视化工具
具体通信过程，待补充（Netty）【2】
说明
===================================
仅作为校招时的《个人笔记》，详细内容请看【参考】部分
===================================