这是我参与「第五届青训营 」笔记创作活动的第9天。
一、本堂课重点内容：
学习消息队列的原理及应用场景。了解常用的消息队列，如kafka，BMQ，RocketMQ。
二、详细知识点介绍：
（1）前世今生
Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。
RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广。
Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。
BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
（2）消息队列Kafka
如何使用：首先需要创建一个Kafka集群，然后需要在这个集群中创建一个Topic，并设置好分片数量，编写生产者逻辑，编写消费者逻辑。
Kafka架构：Zookeeper负责存储集群元信息，包括分区配置信息等。
Producer：批量发送可以减少IO次数，从而加强发送能力；通过数据压缩，减少消息大小。
Broker：移动磁头找到对应磁道，磁盘转动，找到对应扇区，最后写入。寻道成本比较高，因此顺序写可以减少寻道所带来的时间成本。
Consumer：Rebalance方式可以自动分配partition。
存在的问题：运维成本高；对于负载不均衡的场景，解决方案复杂。
（3）消息队列BMQ
架构：兼容Kafka协议，存算分离，云原生消息队列。
运维操作：实际上对于所有节点变更的操作，都仅仅只是集群元数据的变化，通常情况下都能秒级完成，而真正的数据已经移到下层分布式文件存储去了，所以运维操作不需要额外关心数据复制所带来的时间成本。
（4）消息队列RocketMQ
使用场景：针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等；同时，也会涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等。
RocketMQ架构：数据流是通过Producer发送给Broker集群，再由Consumer进行消费，Broker节点有Master和Slaver的概念，NameServer为集群提供轻量级服务发现与路由。
存储模型：对于一个Broker来说，所有的消息都会append到一个CommitLog上面，然后按照不同的Queue，重新Dispatch到不同的Consumer中，这样Consumer就可以按照Queue进行拉取消费，但需要注意的是，这里的ConsumerQueue所存储的并不是真实的数据，真实的数据其实只存在CommitLog中，这里存的仅仅是这个Queue所有消息在CommitLog上面的位置，相当于是这个Queue的一个密集索引。
四、课后个人总结：
消息队列有三大优势：异步，解耦，削峰。
消息队列的缺点为：系统可用性降低，系统复杂度提高，一致性问题。
