这是我参与「第五届青训营 」笔记创作活动的第12天
为什么需要消息队列
- 案例一：系统崩溃
上述流程中，如果记录存储所在机房被删库跑路，整个流程会被卡住
- 案例二：服务能力有限
面对庞大请求，如何处理？
-
案例三：链路耗时长
如何优化来挽回用户？
- 案例四：日志存储
如果服务器故障，丢失日志怎么办？
解决方案：
- 解耦服务，添加消息队列中间件，先推送到消息队列再进行存储
- 削峰，通过消息队列进行削峰
- 异步，下单成功推到消息队列就返回，如何订单处理异步进行
- 日志收集，日志推到消息队列，用平台处理，分析
什么是消息队列
消息队列(MQ),指保存消息的容器，本质是个队列，但需要高并发、高可用、高吞吐
消息队列的诞生
“消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。
消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。
业界消息队列对比
- kafka： 分布式的、分区的、多副本的日志提交服务，高吞吐场景下较为优秀
- RocketMQ： 低延迟、强一致性、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中应用比较广泛
- Pulsar： 是下一代云原生分布式消息流平台，集消息、存储、轻量化函数计算为一体、采用存算分离的架构设计
- BMQ： 和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换对应kafka集群
