消息队列 ｜ 青训营笔记

conason
161 阅读6分钟

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

消息队列

  • 消息队列的前世今生
  • 消息队列-Kafka
  • 消息队列-BMQ
  • 消息队列-RocketMQ
  • 课后思考

消息队列的前世

世界上第一个现代消息队列软件: Teknekron 的 The Information Bus(TIB) 由孟买的26岁工程师发明

1994年由大型的新闻机构路透社收购

1993年左右IBM MQ在英国温切斯特诞生

1997年 微软的消息队列(MSMQ)

2001年 Java Message Service (JMS)诞生 JMS 试图通过提供公共的Java API的方式,隐藏单独的MQ产品供应商提供的实际接口,从而跨越了壁垒和解决了互通问题.

2004年 MQ规范发布，同年 RabbitMQ 面市

2010年 Linked 开源 Kafka

2011年 阿里自研 RocketMQ

2012年 Pulsar 诞生于 Yahoo 内部

为什么需要消息队列？

我们知道计算机处理能力是有限的，过多的消息阻塞不仅影响机器的响应速度，同时可能引起机器的不稳定性导致服务崩溃。我们能否让服务消息稳定的被消费，还能让处理不完的消息被协同消费呢？Ans：将洪水般的消息使用消息队列缓存起来，再均匀的让其被消费，这样子就保证了服务的稳定性。

消息队列-Kafka

使用场景：

搜索服务、直播服务、订单服务、支付服务、日志存储、用户行为（点赞、评论、收藏）等等

如何使用Kafka？

Kafka.png

基本概念：

  • Producer：Producer即生产者，消息的产生者，是消息的入口
  • Broker：Broker是kafka实例，每个kafka集群内的broker都有一个不重复的编号
  • Topic：消息的主题，可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上都可以创建多个topic
  • Partition：Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个一个的文件夹
  • Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）
  • Message：每一条发送的消息主体
  • Consumer：消费者，即消息的消费方，是消息的出口
  • Consumer Group：我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量
  • Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性

Kafka设计：

  • Consumergroup： 各个consumer可以组成一个组，每个消息只能被组中的一个consumer消费，如果一个消息可以被多个consumer消费的话，那么这些consumer必须在不同的组
  • offset： 在Kafka中，消息的状态被保存在consumer中，broker不会关心哪个消息被消费了被谁消费了，只记录一个offset值（指向partition中下一个要被消费的消息位置），这就意味着如果consumer处理不好的话，broker上的一个消息可能会被消费多次
  • 批量发送： Kafka支持以消息集合为单位进行批量发送，以提高push效率
  • 零拷贝： 所谓的零拷贝是指将数据在内核空间直接从磁盘文件复制到网卡中，而不需要经由用户态的应用程序之手。这样既可以提高数据读取的性能，也能减少核心态和用户态之间的上下文切换，提高数据传输效率。

Kafka-问题总结

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

消息队列-BMQ

云原生消息引擎（简称 BMQ ）是火山引擎自研，100%兼容 Apache Kafka 协议的全托管，高吞吐，高可用，高可扩展性的分布式消息服务，支持动态扩缩和流批一体计算，广泛应用于日志收集、数据聚合、在离线数据分析等使用场景

BMQ架构：

bmq.png BMQ架构，适配Kafka协议，存算分离

在BMQ中，对于所有节点的变更操作都仅仅只是集群数据的变化，真正的数据已经转移到下层分布式文件存储系统。通常情况下都能秒级完成，运维不在需要关心数据复制带来的时间成本。

消息队列-RockerMQ

使用场景：

针对电商业务线，应用广泛。诸如：注册、订单、库存、物流等；也会应用在许多业务峰值时刻，例如秒杀活动、周年庆、定期特惠等

RockeMQ 与 Kafka 基本概念区别

kafkaRocketMQ
逻辑队列TopicTopic
消息体MessageMessage
标签无Tag
分区PartitiionConsumer
生产者ProducerProducer
生产者集群无Producer Group
消费者ConsumerConsumer
消费者集群Consumer GroupConsumer Group
集群控制器ControllerNameserver

高级特性：

  • 事务消息
  • 死信队列
  • 延迟队列

课后思考

  1. 消息队列的应用场景有哪些？

    1. 异步处理
    2. 模块解耦
    3. 流量削峰
    4. 消息通讯

  2. Kafka的哪些Feature让其可以支撑大吞吐写入的场景？

    1. 零拷贝
    2. 内存直读
    3. 批量发送
    4. 消息压缩

  3. Kafka Consumer Rebalance的流程简述？

    1. Consume Group 中的所有消费者都向Kafka发起 FindCoordinatorRequest
    2. 这时 Kafka 会选举出对应的 broker 作为 Group Coordinator
    3. Consume 又向 Group Coordinator 发出 JionGroupRequest
    4. Group Coordinator 会指定一个 Consume 作为Group中的Leader
    5. leader 会执行partition的分配
    6. 分配完成，Consume 发出 SyncGroupRequest，leader 发出rebalance方案给 Group Coodinator
    7. Group Coordinator 记录topic、partition、consume、leader信息

  4. BMQ相比较Kafka有哪些优势？

    1. 运维便捷，不再需要考虑重启等操作造成数据复制带来的时间成本
    2. 分布式存储，数据更加可靠

  5. RocketMQ有哪些特有的Feature？

    1. 支持tag，细分消息
    2. 支持事务消息
    3. 支持死信队列

  6. RocketMQ事务消息处理流程简述？

    1. 发送消息
    2. 服务端消费消息写入结果
    3. MQ根据发送的结果执行本地事务
    4. MQ根据本地事务状态执行Commit或者Rollback

  7. 你认为MQ后面应该如何发展？（开放题）

    1. 不同的MQ取长补短，专精于解决某些场景
avatar
文章
阅读
粉丝