共计 804 个字符，预计需要花费 3 分钟才能阅读完成。
RabbitMQ 应用场景
服务解耦
1. 假如有这样一个场景, 服务 A 产生数据, 而服务 B,C,D 须要这些数据, 那么咱们能够在 A 服务中间接调用 B,C,D 服务, 把数据传递到上游服务即可
然而, 随着咱们的利用规模不断扩大, 会有更多的服务须要 A 的数据, 如果有几十甚至几百个上游服务, 而且会一直变更, 再加上还要思考上游服务出错的状况, 那么 A 服务中调用代码的保护会极为艰难
这是因为服务之间耦合度过于严密
2. 再来思考用 RabbitMQ 解耦的状况
A 服务只须要向音讯服务器发送音讯, 而不必思考谁须要这些数据; 上游服务如果须要数据, 自行从音讯服务器订阅音讯, 不再须要数据时则勾销订阅即可
流量削峰
1. 假如咱们有一个利用, 平时访问量是每秒 300 申请, 咱们用一台服务器即可轻松应答
而在高峰期, 访问量霎时翻了十倍, 达到每秒 3000 次申请, 那么单台服务器必定无奈应答, 这时咱们能够思考减少到 10 台服务器, 来扩散拜访压力
但如果这种刹时顶峰的状况每天只呈现一次, 每次只有半小时, 那么咱们 10 台服务器在少数工夫都只分担每秒几十次申请, 这样就有点浪费资源了
2. 这种状况, 咱们就能够应用 RabbitMQ 来进行流量削峰, 顶峰状况下, 霎时呈现的大量申请数据, 先发送到音讯队列服务器, 排队期待被解决, 而咱们的利用, 能够缓缓的从音讯队列接管申请数据进行解决, 这样把数据处理工夫拉长, 以加重刹时压力
这是音讯队列服务器十分典型的利用场景
异步调用
思考定外卖领取胜利的状况
领取后要发送领取胜利的告诉, 再寻找外卖小哥来进行配送, 而寻找外卖小哥的过程十分耗时, 尤其是高峰期, 可能要期待几十秒甚至更长
这样就造成整条调用链路响应十分迟缓
而如果咱们引入 RabbitMQ 音讯队列, 订单数据能够发送到音讯队列服务器, 那么调用链路也就能够到此结束, 订单零碎则能够立刻失去响应, 整条链路的响应工夫只有 200 毫秒左右
寻找外卖小哥的利用能够以异步的形式从音讯队列接管订单音讯, 再执行耗时的寻找操作
