这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天

前言

出现的问题

• 系统奔溃
• 服务处理能力有限
• 链路耗时长尾
• 日志如何处理

解决

解耦

削峰

异步

日志处理

消息队列的前世今生

消息队列发展历程

业界的消息队列对比

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

Kafka

使用场景

基本概念

• Topia:逻辑队列,不同Topic可以建立不同的Topic
• Cluster:物理集群,每个集群中可以津立多个不同的Topic
• Prodtucer:生产者,负责将业务消息发送到Topic中
• Cansumer：消费者,负责瑞费Topic中的潺息
• CansumerGroup：消费者组，不同组Concumer 消费进度互不干涉

问题总结

• 运维成本高
• 对于负载不均衡的场景，解决方案复杂
• 没有自己的缓存，完全依赖Page Cache
• Controller和 Coordinator和Broker 在同一进程中，大量IO会造成其性能下降

BMQ

兼容Kafka协议,存算分离，云原生消息队列

Databus

直接使用原生的SDK会有什么问题？

• 客户端配置较为复杂
• 不支持动态配置，更改配置需要停掉服务
• 对于 latency 不是很敏感的业务,batch 效果不佳

• 简化消息队列客户端复杂度
• 解耦业务与Topic
• 运解集群压力,提高吞吐

Parquet

Apache Parquet是Hadoop生态圈中一种新型列式存储格式，它可以兼容Hadoop生态圈中大多数计算框架(Hadoop、Spark等)，被多种查询引擎支持(Hive、lmpala、Drill等)。

直接在BMQ中将数据结构化，通过 Parquet Engine，可以使用不同的方式构建Parquet格式文件。

RocketMQ

使用场景

例如，针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等;同时，也会涉及许多业务峰值时刻,如秒杀活动、周年庆、定期特惠等

与Kafka的对比

引用

本文全部内容来自于- 字节内部课：后端入门 - 中间件