kafka（消息队列）应用场景简介
kafka（消息队列）应用场景简介
1. 简单理解kafka工作原理（一个比较抽象的例子）
reference：https://zhuanlan.zhihu.com/p/68052232
1.1 为什么需要消息队列
用一个快递的场景来举例子，我买了一样A物品，第二天上着班的时候快递小哥说A物品到了楼下了，但是我正在上班没法回去拿
一个折中的办法是，跟快递小哥说把快递放到楼下的小芳便利店，下班了过来拿
如果没有小芳便利店，会出现下图这个情况：
- 为了去拿快递，需要回去拿（老板不批）（对应我这边没法处理快递小哥的请求了）
- 小哥一直在楼下等（对应快递小哥那边的请求就一直卡在那块了）
- 周末再送（等不及了）
- 这个物品我不要了（不可能）
在小芳便利店出现后，交互图就是如下这样的（等我方便的时候，再去便利店里尽快的拿）：
在上面例子中，“快递小哥”和“买女朋友的我”就是需要交互的两个系统，小芳便利店是我们本文要讲的“消息中间件”
1.2 消息中间件的好处——解耦、异步、削峰
1.2.1 解耦
快递小哥手上有很多快递需要送，他每次都需要先电话——确认收货人是否有空、哪个时间段有空，然后再确定好送货的方案。这样完全依赖收货人了，如果快递一多，快递小哥就忙疯了
如果有了便利店，快递小哥只需要将同一个小区的快递放在同一个便利店，然后通知收货人来取货就可以了，这时候快递小哥和收货人就实现了解耦
1.2.2 异步
快递小哥打电话给我后需要一直在楼下等着，直到我拿走快递再去送其他人的。
快递小哥把快递放在便利店后，就又可以去干其他活了，不需要等待我的到来而一直也处在等待状态，提高了工作效率
1.2.3 削峰
假设双十一买了不同店里的各种商品，发货的快递公司都不一样，有中通、圆通、申通等等，更巧的事同时到货了
中通让去北门取、圆通南门、申通东门，就手忙脚乱
2. 消息队列应用场景
消息队列的三大特点：解耦、异步、削峰
https://baijiahao.baidu.com/s?id=1724880545500053463&wfr=spider&for=pc
2.1 解耦应用场景
2.1.1 例子1
以用户下单购买业务为例，订单系统需要通知库存系统。传统做法事订单系统调用库存系统的接口
传统模式存在的缺点：
1）加入库存系统无法访问，的订单减库存将失败，导致订单失败
2）订单系统与库存系统耦合
引入应用消息队列后的方案，如下图：
1）订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功
2）库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作
假如：在下单时库存不能正常使用，也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他后续操作了。实现订单系统和库存系统的应用解耦。
上面这个例子感觉有点简单了，和同学讨论后补充一下设定，就是我订单系统会告知用户已经完成抢购，抢购结果一段时间后告知，然后库存那边再来处理（等会儿给用户一个推送）
或者说，我订单系统就和数据库完成交互，然后事务完成持久化了，库存系统就根据着数据局来
2.1.2 例子2
还有个例子是，比如我上游是A系统，下游需要BCD系统，现在我C系统作废了，要新加一个E系统，如果是不解耦的话，这个A系统就要操作来操作去的，如果解耦了就直接A推入消息队列，BCDE从消息队列中取就行了，可能还是这个例子比较合适
2.2 异步应用场景
以用户注册，并且需要注册邮箱和短信为例。用户注册后，系统需要发送注册邮件和注册短信，传统的做法有两种，串行方式和并行方式：
- 串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信，以上三个步骤完成后，返回给客户端（150ms）
- 并行方式：将注册信息写入数据库成功后，发送注册邮件的同时发送注册短信，任务完成后返回给客户端（100ms）
引入消息队列后，将改换为异步处理，改造后的架构如下
按照上面这个流程，用户的响应时间相当于是写入数据库+MQ的事件，也就是55ms，将需要干的事写入消息队列后直接返回。因此下入消息队列的速度很快，基本可以忽略，用户的响应时间可能是55ms
2.3 流量削峰应用场景
一般在秒杀或者团抢活动中使用广泛。秒杀活动因为流量过大，导致流量暴增应用挂掉，为了解决这个问题需要加入消息队列
- 用户的请求，服务器接受后首先写入消息队列。假如消息队列长度超过最大则直接抛弃用户请求或跳转至错误界面
- 秒杀业务根据消息队列中的请求信息，再做后续处理
有以下好处：
- 可以控制活动的人数
- 可以缓解短时间内高流量压垮应用