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

消息列队

服务崩溃

一般的流程: 用户进行搜索行为,搜索会进行储存程序记录用户点击商品,点击行为会被储存程序记录

这个时候储存服务器丢失了怎么办? 那这就会出现问题解决发放就是解耦, 在储存服务前面额外增加一个消息队列

多个用户同时发起订单, 处理订单,但是只能同时处理10个订单, 面对庞大的请求量,处理订单服务也会一脸茫然
解决发放是削峰,就是把这个请求通过消息队列存起来, 然后在交给订单处理服务

发起订单5ms,库存记录-1 100ms,订单记录+1 100ms, 通知商家 30s 这样子就太长了, 怎么办呢? 解决方法很简单,就是异步. 发起订单后,先存入消息队列,然后返回下单成功的通知. 消息队列再同时和订单记录,库存记录,商家通知这三个服务异步进行

消息队列,MQ,指保存消息的一个容器,本质是一个队列,但是这个队列需要支持高吞吐,高并发

TIB 诞生于金融服务和金融机构, 叫做TIB.

IBM MQ 诞生于1993年消息队列平台市场主要玩家

MSMQ 微软与1997年发布

JMS 诞生于2001年的javaAPI

AMQP/RabbitMQ 诞生于2004年

Kafka 2010年 linked开源

RocketMQ 2011年阿里自研

PuLsar 2012年诞生于 yahoo内部

Kafka是分布式分区,多副本的日志提交服务,再高吞吐场景下发挥较为出色

RocketMQ:低延迟,强一致性,高性能,高性能,高可靠,万亿级容量和灵活的可扩展性.

Pulsar是下一代云原生分布式消息流平台,集消息,存储,轻量化函数是计算为一体

BMQ 和Pulsar类似,存算奋力,初期是承接高吞吐的离线业务场景,初步替换掉对应的kafka集群