- 使用消息队列的原因
- 消息队列应用场景
- 消息队列的缺点
- 重复消费
- 以redis为例
- 顺序消费
- 消息丢失
- 消息队列的产品
随着业务的不断增加,中间件这些功能已经满足不了需求,所以使用了消息队列
消息队列应用场景- 异步
- 解耦
- 削峰
队列中多个系统,一个系统失败,会重启请求队列,造成其他系统重复消费
- 解决方案
强校验:比如你监听到用户支付成功的消息,你监听到了去加GMV是不是要调用加钱的接口,那加钱接口下面再调用一个加流水的接口,两个放在一个事务,成功一起成功失败一起失败。
弱校验:这个简单,一些不重要的场景,比如给谁发短信啥的,我就把这个id+场景唯一标识作为Redis的key,放到缓存里面失效时间看你场景,一定时间内的这个消息就去Redis判断。
$res=Db::table('one')->insert($data); if($res){ $redis->rawCommand('xack','mytss','onets',$Id); }else{ //如果失败重新插入队列,其他系统已经执行成功,所以需要判断 $redis->xadd('mytss','*' ,['id'=>9900,'username'=>$username]); }顺序消费
RocketMQ提供了MessageQueueSelector队列选择机制(待写)
消息丢失RocketMQ通过设置可以实现零丢失
消息队列的产品- Kafka
- ActiveMQ
- RabbitMQ
- RocketMQ
推荐链接(敖 丙)
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)