浅谈消息队列 (半成品, 待完善)

背景

作为一个有点年纪的开发, 消息队列, 竟然还是我的知识盲区(不全盲, 盲一半吧), 主要是之前项目基本用不上, 或者对应模块是其他同事负责的, 秉承着不懂就学的精神, 开始了几个晚上的自学

相关链接

github上的官方教程
github上的官方教程(基于go)
官网教程

基本思想

核心思想: 异步, 解耦, 削峰, 生活中比较熟悉常见的场景, 点外卖算其中一个吧, 就取今晚点的m记做例子吧

未接受任何广告合作, 欢迎m记来撩

商城取用户从下单到订单结算成功这个流程, 简单分析一下吧

异步

简单支付

从下单到订单结算成功最简单, 就是三步:

1. 下单 (前端提交数据)
2. 支付 (后端处理)100ms
3. 完成 (恭喜你, money–)

积分增加

点完后, 突然收到消息, 积分变更提醒, 对哦, 交易成功了, 系统给我加点积分, 不过分吧?
于是, 流程相对有复杂一些了

1. 下单 (前端提交数据)
2. 支付 (后端处理)100ms
3. 积分增加 (也在上述的后端处理中, 100ms)
4. 完成 (恭喜你, money–, but, 积分++)

这些可好, 原来用户只用等100ms的, 现在得等200ms, 不过, 200ms好像也还在接受范围内, who care

优惠券失效

突然又想起, 刚刚的订单我用了优惠券, 那订单结束后, 我的优惠券该何去何从呢? 点开"我的优惠券"一看, 果然已经"已使用"了, 这么一想, 整个流程又复杂了

1. 下单 (前端提交数据)
2. 支付 (后端处理)100ms
3. 积分变更 (也在上述的后端处理中, 100ms)
4. 优惠券失效 (也在上述的后端处理中, 100ms)
5. 完成 (恭喜你, money–)

这一整, 时间变300ms了

futhermore

当然了, 如果各个过程的响应时间不是100ms, 再加上大部分系统流程远不止上述说的这么简单, 一系列流程时间累积起来, 可能用户得等个好几s, 甚至更长时间, 如果你是用户, 你能忍?

so, 只能优化了T.T

(未完待续)