这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记。
这篇文章是课程《走进消息队列》的笔记。
消息队列是我们平常使用去解决问题中一种常用的中间件，比如日志处理过程：
graph TD
Log --> 消息队列 -->LogStash -->ES --> Kibana
“消息队列”是在消息的传输过程中保存消息的容器，当我们需要使用消息的时候可以取出消息供自己使用。 消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。
下面介绍几种常见的消息队列：
kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。
RocketMQ:低延迟、强一致性、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些时事场景中运用较广。
Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。
BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
Kafka：
使用场景：
搜索服务、直播服务、订单服务、支付服务、日志信息、Metrics数据、用户行为。
如何使用：
graph TD
创建集群 --> 新增Topic -->编写生产者逻辑 --> 编写消费者逻辑
消息的视角：
graph TD
Producer --> Broker --> Consumer
提高吞吐的行为：
Producer：批量发送、数据压缩
Broker：顺序写，消息索引，零拷贝
Consumer：Rebalance
Kafka的缺点：
数据复制问题
重启问题
Kafka的替换、扩容、缩容操作
可能会负载不均衡
问题总结：
- 运维成本高
- 对于负载不均衡的场景，解决方案复制
- 没有自己的缓存，完全依赖Page Cache
- Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降
