kafka和rocketMQ的应用场景对比

前言:

公司采用了两种消息队列,一种是阿里云的rocketMQ,一种是kafka.分别用在了两种不同的场景.这里做个记录.

rocketMQ

使用场景:

1.异步解耦:

拿我们的项目举例,有一个场景,是需要pc端触发派单接口,然后发送给app端消息通知.此时要求能够做到每个app都能收到消息,但是又希望这个发送的过程尽量的短,也就是派单接口尽量快.那么这个派送的过程可以采用rocketMQ去进行异步处理这个过程.使这个接口能够尽快的给pc端的用户响应,已经派工成功的通知.这个场景就是异步解耦.派工的过程在消息系统中去通过rocketMQ去异步处理.这样起到解耦的作用.并且rocketMQ的广播模式能够保证每个app都能够消费到消息.

2.事务消息:

拿公司支付举例,微信支付的时候想要快速的回应微信的回调.以便让微信知道我们已经收到回调了.尽快改变支付状态就可以了.而我们这边需要再回调中做大量的逻辑处理,如修改订单状态,发送短信等操作.那么这些操作可能耗时很久,使用rocketMQ可以解决耗时久的问题.但是同时又产生一个问题,就是需要保证rocketMQ去修改订单状态的过程是事务性的.不然微信那边已经通知支付成功.但是我们这里状态却没变.这就会让客户认为我钱白付了,又会重复支付的问题.所以rocketMQ的事务消息能够做到事务性.也就是消息的回调处理,我们可以在消费者端去处理完修改订单状态逻辑之后,收到rocketMQ的一个回调通知,报告是否可以提交消息的事务.如果回调中说明修改订单状态有误.我就可以在回调中做消息的补偿处理(修改订单状态.)直到我们的状态更改成功.

3.削峰填谷

拿派单来说,一旦用户群体过多.比如我们公司会在年底某一天搞活动,派单越多,奖励越多,那么使用量上来之后,一定会产生高并发的问题,造成崩溃,影响用户体验的问题.此时我们可以采用mq去解决这种问题.mq最大的好处就是可以让消息不丢失.只要消息发出去了.就能保证消费者一定能够收到.

4.顺序收发

我们没用到,场景如一些游戏平台需要保证优先注册的五百名可以收到