这是我参与「第五届青训营 」伴学笔记创作活动的第 2 天。
📜📜📜今天学习的是消息队列。
一、🤔思考几个问题
下面这些情况应该如何处理？
- 系统崩溃
- 服务处理能力有限
- 链路耗时长尾
- 日志如何处理
解决方案： 1.解耦——将所有行为记录拉取到消息队列中，再用存储服务拉取出来进行消费；
- 削峰——对大量的消息请求先放到消息队列中，每次从消息队列中拉取少量请求进行处理；
- 异步——将发起订单的请求放到消息队列中，将订单记录、库存记录、通知商家放到不同链路上。
4.日志处理
那么什么是消息队列呢？消息队列是指保存消息的一个容器，本质是个队列，需要支持高吞吐、高并发、并且高可用。
2.➡消息队列发展历程
TIB——》web Sphere——》MSMQ——》JMS——》AMQP——》Kafka——》RocketMQ——》Plisar
各个消息队列的对比：
- Kafka：高分布，分布式的、分区的、多副本的日志提交服务；
- RocketMQ：实时、低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性；
- Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计；
- BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
3.❗❗❗KAfka、BMQ、RocketMQ
3.1Kafka
-
使用场景：日志信息、Metrics数据、用户行为数据。
-
如何使用Kafka？ 创建集群——在集群中新建Topic，并设置好分区数量——编写生产者逻辑（即将写的hello world发送到Topic中）——编写消费者逻辑（即将刚刚写入的helloworld用told方法拉取出来）
-
下面较详细的介绍基本概念——Topic：逻辑队列； Cluster：物理集群，每个Cluster可以创建多个不同的topic； producer：生产者，负责将业务消息发送到topic中； consumer：消费者，负责消费topic中的消息； partition：topic的分区； consumergroup：消费者组，不同组consumer消费者进度互不干涉。
-
补充：Offset ：消息在 partition 内的相对位置信息，可以理解为唯一ID，在 partition 内部严格递增。
-
Replica：每个分片有多个 Replica（副本），Leader Replica 将会从ISR（In-Sync Replicas所有副本）中选出。同时，如果某个副本与leader replice的内容相差太大，该副本会被删除。
帮助Kafka提高吞吐或者稳定性的功能—— Producer：批量发送、数据压缩； Broker：顺序写（写入更快），消息索引（寻找消息的机制），零拷贝；Consumer:Rebalance
缺点：
- 运维成本高
- 对于负载不均衡的场景，解决方案复杂
- 没有自己的缓存，完全依赖 Page Cache
- Controller 和 Coordinator和Broker 在同一进程中，大量IO会造成其性能下降
3.2 BMQ
-
使用场景：实时业务用的比较多，例如，针对电商业务线，峰值秒杀，订单，物流等。
-
框架图：
-
与Kafka运维对比
- HDFS写文件流程
- BMQ解决了Kafka的不宜维护的问题
- BQM读写流程
- Failover机制——任意一分片在同一时刻只能在一个broker上存活
- 写入状态机
- BMQ高级特性
- 泳道
- Databus（1.简化消息队列客户端复杂度2.解耦业务与Topic缓解集群压力，提高吞吐）
- mirror（使用Mirror通过最终一致的方式，解决跨Region读写问题。）
4. Index
- Parquet
3.3RocketMQ
-
使用场景：实时业务用的比较多，例如，针对电商业务线，峰值秒杀，订单，物流等。
-
与Kafka对比：
- RocketMQ的高级特性
- 事务消息
- 重试和死信队列
- 延迟队列)
