[ 后端基础Day12 | 青训营笔记]

Ccccsn呀
68 阅读1分钟

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

消息队列

消息队列，保持消费的一个容器，本质是个队列，但是这个队列需要支持高吞吐、高并发、高可用

image-20230209201405955.png

Kafka

架构

image-20230209202043308.png

image-20230209202255940.png

会有多个partition，可以同时进行处理，增加topic吞吐能力，每个partition会有多个replica

image-20230209202308884.png

副本分布图

image-20230209205748808.png

Follower会紧跟Leader，尽量与leader保持一致，没跟上的follower会被t掉

image-20230209202547675.png

Produce

数据压缩

image-20230209202742064.png

数据存储

image-20230209202809949.png

Broker：

顺序写，减少磁盘寻道时间

传统数据拷贝

image-20230209203658900.png

零拷贝

image-20230209203719196.png

不需要经过用户状态，省去3次拷贝

接收端consumer

image-20230209204129505.png

手动分配

自动分配

image-20230209204346688.png

image-20230209204901436.png

问题总结

运维成本高；对于负载不均衡的场景，解决方案复杂；没有自己的缓存；controller、coordinator、broker在同一进程中，大量io导致性能下降

BMQ

兼容Kafka协议，存算分离

image-20230209212130970.png

image-20230209212239642.png

文件结构

image-20230209212407561.png

写文件

image-20230209212736520.png

image-20230209213119359.png

wait可以挡掉一些流量

多机房部署

image-20230209213202572.png

高级特性

image-20230209213433210.png

image-20230209213444105.png

泳道

image-20230209213742812.png

DataBus

简化消息队列客户端复杂

解耦业务与topic

缓解集群压力，提高吞吐

Mirror

image-20230209214147492.png

Index

image-20230209214257667.png

Parquet

新型的列式存储

image-20230209214511126.png

RocketMQ

适用于延迟要求低的，适用于电商线

image-20230209220411653.png

存储模型

image-20230209220623676.png

高级特性

事务场景

image-20230209220719324.png

事务消息

image-20230209220856254.png

延迟发送

image-20230209221132193.png

image-20230209221220095.png

消费重试与死信队列

image-20230209221331692.png

个人总结：

消息队列本质还是个队列，先进先出，fafka虽然有较大的吞吐量，但是运维成本高，重启成本大，BMQ则在其之上引入了分布式文件系统，而rockermq是基于电商业务的特性开发出来的，在之后的开发中要根据自己业务的需要选择。

avatar
文章
阅读
粉丝