前言

这是我参与【第五届青训营】伴学笔记创作活动第十三天， 今天学习的主要内容是消息对立的前世今生和消息队列Kafka，消息队列-BMQ，消息队列-RocketMQ。

正文

1. 消息队列

• 定义：消息队列，指保存消息的一个容器，本质是个队列，但在这个队列中，学要支持高吞吐，高并发，并且高可用。
• 业内消息队列对比：
• Karka :分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
• RocketMQ ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
• Pulsar ：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计 上 PULSAR BMQ ：和 Pulsar 架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的 Kafka 集群

2. Karka

• 如何使用：创建集群——新增Topic——编写生产者逻辑——编写消费者逻辑
• 基本概念：
• Topic：逻辑队列，不同topic可以建立不用的topic
• Cluster：物理集群，每个集群中可以建立多个不同的topic
• Producer：生产者，负责将业务消息发送到topic中
• consumer：消费者，负责消费topic中的信息
• consumerGroup：消费者组，不同的consumer互不干涉
• Offset：消息在partition内的相对weizhi，可以理解为唯一ID，在partition内部严格递增。
• Replica：每个分片有多个Replica，leader，Replica将会从ISR中选出。
• Zookeeper：负责存储集群元信息，包括分区分配信息等。 -Preducer-批量发送，可以减少IO次数，从而加强发送能力
• Producer——数据压缩：通过压缩，减少信息大小，目前支持Snappy，Gzip，LZ4，ZSTD压缩算法。
• Broker：数据的存储，消息文件存储，磁盘结构，顺序写，偏移量索引文件时间戳索引文件，传统数据拷贝，；零拷贝
• Kafka——重启操作：关闭，重启——Leader切换，追赶数据——数据同步完成——Leader回切
• Kafka——问题总结：运维成本高；对于负载不均衡场景，解决方案复杂；没有自己的缓存，完全依赖Page cache；Cotroller和Coordinator在同一进程中，大量IO性能下降

3.BMQ

• 兼容Kafka协议，存算分离，云原生消息队列
• 运维操作对比：

• HDFS写文件流程：随机写入一定的DataNode进行写入
• BMQ的架构模型：解决Kafka存在问题
• BMQ读写流程：Failover机制，写入状态机
• BMQ高级特性：泳道，Databus Mirror，Index，Parquet

4.RocketMQ

• 使用场景：电厂业务线，其业务涉及广泛，如注册，订单，库存，物流等，同时也会涉及许多业务峰值时刻，如秒杀哦活动，周年庆，定期特惠。
• 高级特性：
• 事务场景
• 事务消息
• 延迟发送
• 延迟消息
• 处理失败
• 消费重试和死信队列