消息中间件的应用场景

今天基于rabbitMQ的学习聊一下他的应用场景：

1、work_queue 工作队列模式

例如我们有的时候有发送短信的的服务，同事要发送短信的时候比较多，那么一台服务吃不消，这样的话我们就可以使用这种模式来进行削峰填谷。如下图

 

 p是生产者 这个端要发送消息的量特别大（加入要发送1000），并且发送消息不影响后边的业务执行，这时候我们就使用mq来削峰。

C1和C2是相同的服务，都为短信服务，他们两个单独的处理能力为五百，这样两个加起来就有一千的量了（mq出来1000的消息量绰绰有余），而且这种模式下C1消费后C2就不会重复消费。

2、pub/sub 发布订阅模式

参照下图：

 

注意 此时红色为队列queue p是生产者 c是消费者  x是交换机

 

 使用场景：fanout 广播模式，当发送同一个消息时候c1和c2为不同的服务，分别要根据同一个消息做不同的处理，比如说c1是为了日志打印c2是为了日志保存到数据库。这个时候才用广播模式，起到应用解耦的作用。

3、routing模式 路由模式

注意：routing模式下 交换机绑定队列时要指定routing key，消息被发送时会转发到对应的队列中 ，还有交换机的类型要是direct

使用场景：下单后要对这个库存进行修改，这时候可以为库存系统专门设置一个队列，然后设置一个key，注意这时候必须是下单成功。（看不明白就别较劲了，场景是我自己想的）

 4、topics通配符模式

 

注意：其实当前模式可以实现发布订阅模式，假设所有队列绑定的都是*，那匹配时就类似于pub/sub模式了，实现routing模式，就是通配符写的不那么复杂就行，只是这种方式在设置routing key的时候更加的灵活

 使用场景：上述的皆可用（本人没有太多实战经验，键盘那选手，只是做下记录）

amqp是什么？高级消息 队列协议

AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。

 

 

未完待续。。。。