这是我参与「第三届青训营 -后端场」笔记创作活动的第6篇笔记。 今天的笔记整理课程“走进消息队列”这门课的干货内容。
今天讲师的导入非常特别，从买游戏机搜索抖音直播间开始，模拟了搜索行为记录、点击商品、点击行为记录。 这时如果再记录存储这个环节出现了问题会产生很严重的问题。
第二个案例是服务能力有限。秒杀订单结果被抢没了。 第三个案例是链路耗时长尾：程序一直转圈圈。 第四个案例是日志存储。
四个案例总结一下就是：系统崩溃、服务处理能力有限、链路耗时长尾、日志如何处理。 第一个案例解决方案是解耦：消息队列实现存储服务 第二个案例：削峰，处理订单时每次只获取10个请求进行处理。 第三个案例：异步。异步修改订单的状态，处理完成后再修改。 第四个案例：日志处理：Log 消息队列 LogStash ES Kibana
接下来是消息队列的正式介绍
消息队列MQ 保存消息的一个容器 本质是一个队列，需要支持高吞吐高并发、高可用。
讲师简单介绍了消息队列的发展历程和业界使用的消息队列对比。
接下来是消息队列的具体介绍 Kafka 使用场景：搜索服务、直播服务、订单服务、支付服务。 用户行为：搜索点赞评论收藏
如何使用Kafka 创建集群、新增Topic、编写生产者逻辑、编写消费者逻辑。 消息队列当中基本概念的介绍如Replica 数据复制过程、Kafka架构 ZooKeeper 负责存储集群元信息，包括分区分配信息
接下来是从消息的视角来看 发送一条消息等到其成功后再发一条会有什么问题。 Producer批量发送、Broker消息文件结构、磁盘结构、偏移量索引文件。 二分找到小于目标offset的最大文件。 Broker传统数据拷贝与零拷贝，介绍了应用空间、内核空间、磁盘空间的关系。 Consumer Low level High level Consumer Rebalance
总结一下：可以帮助Kafka提高吞吐或者稳定性的功能： Producer：批量发送、数据压缩。 Broker：顺序写，消息索引，零拷贝 Consumer：Rebalance。 数据复制问题、重启操作。 替换、扩容、缩容、负载不均衡。
关于Kafka的问题总结：运维成本高、对于负载不均衡的场景，解决方案复杂，没有自己的缓存，完全依赖Page Cache Controller 和Coordinator 和Broker 在同一进程中。大量IO会造成其性能下降。
接下来是BMQ的介绍 首先讲师简单介绍了架构图、并将BMQ和Kafka运维操作做了对比，HDFS写文件流程：随机选择一定数量的DataNode进行写入。对比了BMQ和Kafka的文件结构。 Broker-Partition状态机 保证对于任意分片在同一时刻只能在一个Broker上存活。 Broker写文件流程、 Proxy、 多机房部署、BMQ的高级特性、 泳道消息 开发流程：开发、BOE、PPE、Prod 每多一个测试人员，都需要重新搭建一个相同配置的Topic， 造成人力和资源的浪费。 解决主干泳道流量隔离问题以及泳道资源重复创建问题。 Databus 直接使用原生SDK问题：客户端配置较为复杂、不支持动态配置，更改配置需要停掉服务，对于latency不是很敏感的业务，batch效果不佳。 简化消息队列客户端复杂度、解耦业务与Topic、缓解集群压力，提高吞吐。 Mirror：通过多机房部署方式，解决跨Region读写问题。 通过最终一致的方式。 Index：直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query 服务读出数据。
Parquet： Apache Parquet 是Hadoop 生态圈中一种新型列式存储格式，可以兼容Hadoop生态圈中大多数计算框架（Hadoop、Spark等），被多种查询引擎支持（Hive、Impala、Drill等） 直接在BMQ中将数据结构化，通过Parquet Engine 可以使用不同的方式构建Parquet格式文件。
使用场景：针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等，同时也涉及许多业务峰值时刻，如秒杀活动、定期特惠等
RocketMQ 基本概念、架构图、高级特性：事务场景、事务消息、延迟发送、延迟消息、消费重试和死信队列。
本次课内容干货很多，而且很多都是以框图的形式概述基本概念的模型，理解起来不太容易，还是需要结合讲师的PPT以及学员手册一起看，当然希望在后续的工作中能够用起来，慢慢就搞明白原理了。
