这是我参与「第五届青训营」笔记创作活动的第9天。
消息队列 (Message Queue)
保存消息的容器，本质上是个队列，需要支持高吞吐，高并发，高可用
分布式原因：
1. 单击吞吐量小，分布式的吞吐量大
2. 分布式好扩容
3. 防止单机节点挂掉，类似HDFS的多副本容错
Kafka
Kafka：（1）创建集群 （2）新增topic （3）生产者逻辑 （4）消费者逻辑
Topic: 逻辑队列
Cluster：物理集群，每个集群中可以建立多个不同的 Topic
Producer：生产者，将业务消息发送到 Topic 中
Consumer：消费者，消费 Topic 中的消息
ConsumerGroup: 消费者组，不同组的的消费者进度互不干涉
总结了可以帮助Kafka提高吞吐或者稳定性的功能：
Producer：批量发送、数据压缩。
Broker：顺序写，消息索引，零拷贝。
Consumer：Rebalance。
数据复制问题、重启操作、替换、扩容、缩容、负载不均衡。
Kafka的问题总结：运维成本高、对于负载不均衡的场景，解决方案复杂，没有自己的缓存，完全依赖Page Cache Controller 和Coordinator 和Broker 在同一进程中。大量IO会造成其性能下降。
RocketMQ
架构
NameServer，作为路由，指出MessageQueue在哪个副本上
存储模型
密集索引，每个消息都有一个索引
高级特性：事务场景、事务消息、延迟发送、延迟消息、消费重试和死信队列。
-
(事务场景)【异步】处理多个业务，通过【事务保证业务之间的关联】
- 如订单发起业务中，库存/订单/通知商家，是在一个业务中的
-
(延迟发送) 提前发送给消息好，并设置可以被消费的时间，定时会被消费处理
- 先发送给ScheduleTopic，ScheduleMessage通过轮询，到达时间点后回写给CommitLog，正常提交进行消费
-
(消费重试和死信队列)
-
- 消费失败，进行重试，没有达到重试次数，延期投递，发送给RetryTopic，再进行消费
-
- 达到重试次数，发送到死信队列，进行记录
-
