走进消息队列
什么是消息队列(MQ)-引入
搜索结果-抢购-处理订单的用时-日志存储等情况下的系统崩溃,服务器处理耗时长,链路耗时长尾,日志处理等问题的解决处理
- 解耦
- 解除必须关联性
- 削峰
- 设置最高同时请求次数
- 异步
- 同时执行操作
- 日志处理
- Log-消息队列-LogStash-ES-Kibana
- 消息队列的定义:保存消息的一个容器,本质是个队列,支持高吞吐,高并发,高可用
消息队列发展历程
- 诞生于TIB-1985
- Kafka-2010年Linked开源
- RocketMQ-2011阿里自研
- Pulsar-2012-Yahoo
一些业内消息队列对比
- Kafka-分布式,分区,高吞吐
- RocketMQ-低延迟,强一致,高性能,高可靠,实时场景运用较广
- Pulsar-下一代云原生分布式消息流平台
- BMQ-和Pulsar类似,存算分离,承接高吞吐的离线业务场景
Kafka
- 常用场景
- 搜索服务,直播服务.订单服务,支付服务-表现为日志消息,Metrics数据,用户操作的信息
- 如何使用
- 创建集群-新增Topic-编写生产者逻辑-编写消费者逻辑
- 基本概念
- Topic 逻辑队列
- Cluster 物理集群,每个集群中可以建立多个不同的Topic
- Producer 生产者,负责将业务消息发送到Tpoic中
- Consumer 消费者,负责消费Topic中的消息
- ConsumerGroup 消费者组,不同组之间互不干涉
- Offset
- 概念 消息在partition内的相对位置信息,可以理解为唯一ID
- Replica
- 每个分片有多个Replica
- 一条消息的自述(流程)
Producer---(生产)-->Broker---(消费)-->Consumer - 可以帮助Kafka提高吞吐或者稳定性的功能
- Producer 批量发送,数据压缩
- Broker 顺序写,消息索引,零拷贝
- Consumer Pebalance
- 问题总结
- 运维成本高
- 对于负载不均衡的场景,解决方案复杂
- 没有自己的缓存,完全依赖Page Cache
- Controller和Coordinator和Broker在同一进程中,大量IO会导致其性能下降
BMQ
- 简介
- 兼容Kafka协议,存算分离,云原生消息队列
- 秒级操作,Kafka是分级
RocketMQ
- 使用场景
- 针对电商业务,比如注册,订单,库存等
- 设计业务峰值时刻,如秒杀,周年庆,定期特惠等
- 底层原理
- 架构模型,存储模型
- 高级特性
- 事务消息,重试和死信队列,延迟队列
