RabbitMQ应用一:分散业务处理

  对于需要处理很多工作的业务接口中,对各种接口的调用往往造成这个接口耗时过长,而各种接口的频繁调用,也对服务器造成了很大压力。用线程来解决前面的问题,在线程的新建和销毁都需要耗费时间,即使用线程池来实现,服务器照样也有压力。而提升服务器性能来解决后一个问题,性价比不够高。如果这时能用上MQ,不为是一个比较好的解决方法。


  如上图所示,在一个博彩类APP中,用户在界面下注比赛,会调用服务器的下注接口。下注接口是一个业务处理量非常大的接口。对用户的体验也非常主要,谁也不想下注一场比赛要等好几秒才下单成功。但这个接口不仅要把下注信息写入到数据库中,还要统计很多信息,比如用户的喜好,用户花费金额的排行榜,下注额在一场比赛的某一方的总额,总额过高,就要调低这一方的赔率,防止黑天鹅事件导致公司亏损过大等。

  在普通应用处理场景,一条流水线下来,每个业务处理都要花费时间,同步进行的处理,累积出来的时间就延长了。如果访问量过大,还会造成服务器崩溃。所以我们想到,最重要的主业务还是主服务器处理,而那些统计及其其他不重要、不需要及时反馈的业务处理通过MQ来发送。MQ再推送到其他副业务处理服务器上处理。减轻了服务器压力,提高了响应能力。

详细代码参考我的git项目:https://github.com/888xin/rabbitmq

里面的主服务器(也就是MQ的发送端)是项目:rabbit-pruducer , 副服务器(也就是MQ的消费端)是项目:rabbit-consumer


主服务器端(MQ发送端)先实现下注逻辑PlayBall.java

package com.lhx.contest;

import com.lhx.bean.Bet;
import org.codehaus.jackson.map.ObjectMapper;
import org.slf4j.Lo
  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值