这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
前言
这是小白初接触到消息队列的内容，本课程消息队列原理与实战。主要讲述常见的消息队列 Kafka，BMQ，RocketMQ。
1.什么是消息队列?
消总队列(MQ) 指保存消息的一个容器本质是个队列。需要支持吞吐，高并发，并且高可用。
在互联网的各种业务中发挥着至关重要的作用，本课讲述工业界比较成熟消息队列的底层原理、架构设计、以及它们的一些高级特性
2.四个场景，如何解决?
①系统奔溃：解决方案:解耦
②服务处理能力有限：解决方案:削峰
③链路耗时长尾：解决方案:异步
④日志如何处理：场景四:日志处理
(1)前世今生
1.业界消息队列对比
Kafka:分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色：
RocketMQ:低延迟、强-致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
Pulsar:是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计
BMQ:和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
(2)消息队列-Kafka
1.基本概念
Topic: Kakfa中的逻辑队列， 可以理解成每一个不同的业务场景就是一个不同的topic, 对于这个业务来说，所有的数据都存储在这个topic中
Cluster: Kafka的物理集群，每个集群中可以新建多个不同的topic
Producer:顾名思义，也就是消息的生产端，负责将业务消息发送到Topic当中
Consumer:消息的消费端，负责消费已经发送到topic中的消息
Partition:通常topic会有多个分片，不同分片直接消息是可以并发来处理的，这样提高单个Topic的吞吐。
Offset :消息在partition内的相对位置信息，可以理解为唯一HID. 在partition内部严格递增。
Replica:分片的副本，分布在不同的机器上，可用来容灾，Leader对外服务，Follower异步去拉取leader的数据进行一个同步，如果leader挂掉 了，可以将Follower提升成leader再堆外进行服务
- Kafka-问题总结
1.运维成本高
2.对于负载不均衡的场景，解决方案复杂
3.没有自己的缓存，完全依赖Page Cache
4.Controller 和Coordinator和Broker在同一进程中，大量I0会造成其性能下降
(3)消息队列-BMQ
-
BMQ架构模型(解决Kafka存在的问题)
-
BMQ读写流程(Failover 机制，写入状态机)
-
BMQ高级特性(泳道、Databus、 Mirror、 Index、 Parquet)
(4)消息队列RocketMQ
使用场景：例如，针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等;同时，也会涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等。
-
RocketMQ的基本概念(Queue, Tag)
-
RocketMQ的底层原理(架构模型、存储模型)
-
RocketMQ的高级特性(事务消息、重试和死信队列，延迟队列)
小结
本课程由浅入深的讲述工业界比较成熟消息队列的底层原理、架构设计、以及它们的一些高级特性。
