这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天。
消息队列
1、消息队列
当遇到系统崩溃场景的时候使用解耦进行解决。
当遇到服务处理能力有限的场景的时候，使用削峰来进行解决。
当链路耗时长尾的场景的时候，使用异步进行解决。
当遇到日志如何处理场景的时候，使用日志处理来进行解决。
消息队列是指保存消息的一个容器，本质上是一个队列，但这个队列需要支持高吞吐，高并发，并且高可用。
业界消息队列：
Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。
RocketMQ：低延迟，强一致，高性能，高可靠，万亿级容量和灵活的可扩展性，在一些实时场景中运用较广。
Pulsar：使下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用存算分离的架构设计。
BMQ:和Pulsar架构类似，存算分离，初期定位使承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
2、Kafka：
Kafka是基于zookeeper协调的分布式消息系统，它最大的特性是可以实时的处理大量数据以满足各种需求场景。
应用场景：日志收集，消息系统，用户活动跟踪，运营指标，流式处理，事件源。
Kafka的一些重要设计思想：消息的状态被保存在consumer中，broker只记录一个offset值、消息持久化、消息有效期、以消息集合为单位进行批量发送、Kafka集群中broker之间的关系不是主从关系，地位相同、提供了一个metadataAPI来管理broker之间的负载、采用异步Push方式提高系统吞吐率、broker支持消息分区、对可拓展的数据持久化的支持，适合向Hadoop或者数据仓库中进行数据装载、Producer支持批量发送和数据压缩，Broker支持顺序写、消息索引以及零拷贝，Consumer支持Rebalance等帮助Kafka提高吞吐或者稳定性。
如何使用：
创建集群、新增Topic，编写生产者逻辑，编写消费者逻辑。
Offset:消息在partition内的相对位置信息，可以理解为唯一ID,在partition内部严格递增。
Kafka问题：运维成本高、对于负载不均衡的场景、解决方案复杂、没有自己的缓存、完全依赖Page Cache、Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降。
引用参考文章：
Kafka基本原理详解（超详细！）_<一蓑烟雨任平生>的博客-CSDN博客_kafka工作原理
总结
本文是青训营学习中关于消息队列的学习笔记，并参考了文章Kafka基本原理详解（超详细！）_<一蓑烟雨任平生>的博客-CSDN博客_kafka工作原理。
