RabbitMQ全面解析

首先呢,还是要先说下队列和堆这两种数据结构,不过这两个大家都应该都很清楚,队列   ̄▽ ̄  先进先出,堆  ̄▽ ̄  后进先出,最经典的汉诺塔问题。而这里要说的RabbitMQ呢,就属于队列。

这里要先说下,为什么我们要用MQ呢,主要还是两点,一个是 系统间的解耦,还有一个是流量的削峰

先说说,系统的解耦,举个最简单的例子吧,比如公司里面人事变动部门,然后呢这个人因为部门变动,那么他之前申请的补贴要取消了,他之前项目角色要变了,他的权限要删了,这里在人事系统是不是要调用三个接口,到不同系统去做逻辑。那么问题了来了,如果再加个功能呢,是不是还要去改代码再调一个接口,然后联调,烦不烦。用MQ就不一样了,那事情就变得简单多了,只需要 TODO 后面逻辑

再说说,流量削峰,最经典的秒杀,一瞬间那个流量是非常高的,那么这里,用MQ以后,全部进入队列中,根据队列顺序去做就很容易做业务逻辑了。再比如我项目遇到的,微信消息推送,有个二货半分钟内发了两万条报警信息,还要这块用的MQ,消息都在MQ中,只是发送较慢,后面全部消耗掉了,否则就会出现堵塞,消息丢失,蝴蝶效应等未知问题。当然这货后来被祭天了@不愿透密姓名的沙同学。

当然前面闲扯淡了这么多,下面开始进入正题吧。

 

RabbitMQ交换机

这里呢要先说明下,消息的走向  生产者(producter)->交换机(exchange)->队列(queue)->消费者(customer)

  1. 直连交换机(Direct exchange)
  2. 扇形交换机(Fanout exchange)
  3. 主题交换机(Topic exchange)
  4. 头交换机(Headers exchange)
  5. 死信交换机

直连交换机

RabbitMQ全面解析_第1张图片

这里首先要说下routing key,生产者在向交换机发送消息的时候,会带上一个key,这个key是做什么用的呢,主要是用于让交换机确定这个消息分发到哪个队列中去。

如上图中,生产者生成三个消息,分别带着key1,key2,key3。根据交换机和队列的设置,那么key1的消息分发到queue1,key2分发到queue2,以此类推。同时多个队列可以和交换机设置同一个key。

扇形交换机

RabbitMQ全面解析_第2张图片

那么在扇形交换机中,这时候routing key就不生效了,这时候生产者发送的所有消息都会分发到不同的队列中去,如上图中,就会同时分发到三个队列里面去,每个队列都收到同样的消息。

然后比如两个消费者同时订阅了OA queue队列,那么这里队列会用轮询的方式去往两个消费者推送消息(这里可以理解成OA应用站点的多个负载)。

主题交换机

RabbitMQ全面解析_第3张图片

下面说到主题交换机,这个其实算是直连交换机的升级版。为什么这么说呢,因为主机交换机就是模糊匹配routing key,而不需要全文匹配。

*表示一个单词

#表示任意数量(零个或多个)单词

如上图中,那么第一个消息队列会受到第1,2条消息,第二个消息队列会收到三条消息,第三个消息队列会收到第1,3条消息。

头交换机

RabbitMQ全面解析_第4张图片

这个主要应用于需要有多个key的时候,这时候用消息头会更容易表达,这里的key是放在请求头里面用键值对的形式做路由。这里的话可以带多个key。

x-match属性

any  只要某一项键值对匹配上就行

all  必须所有的键值对匹配上才行

如上图中,第一个消息队列会受到第2条消息,第二个消息队列会收到两条消息,而第三个消息队列则会收到第1条消息。

死信交换机

这时候大家肯定会有个问题,如果消息没有能匹配的规则去分发到对应的队列怎么办。那么这个时候,这个消息就会被丢到死信交换机中去。但是,这里要注意的是,在死信交换机中的数据,只能人工去处理,而rabbitMQ是不会对这些消息做任何的处理。

 

RabbitMQ管理后台

RabbitMQ全面解析_第5张图片

RabbitMQ呢自带管理后台,直接设置就好了,首页是个MQ的总览,然后菜单分别就是 Connection(当前链接客户端),Channels(通道),Exchanges(交换机),Queues(队列),Admin(用户管理)。

基本上类似交换机和队列都可以在后台中新建配置,然后可以给不用的用户设置不同交换机或者队列的权限。

主流开发语言都有对应的组件可以直接使用,很方便,这里就不说具体的使用了。

 

RabbitMQ容灾

1,交换机,队列和消息的落地。这里可以设置交换机和队列存储到磁盘中,同时消息也可以设置存储到磁盘中,当MQ发生故障奔溃时候,重新启动会把磁盘中消息重新加载到内存中去。

2,可以设置需要数据的回执,也就是说,如果发生消费者当机等问题导致发送的消息,没有收到消费者的回执,表示消息接受成功,那么这个消息会再次发送给下一个消费者去消费。这时候会有个问题就是如果因为网路波动等原因导致回执没有收到,那么这个消息会重复被消费掉,所以要注意下消息的消费幂等问题。

3,拒绝消息,当消费者消费的时候触发了异常,那么可以发送回调表示这个消息没有消费成功,如在catch中。

4,RabbitMQ支持集群部署。

5,RabbitMQ事务,当生产者发送消息的时候,如果发送异常,MQ没有收到消息。提交txCommit异常了,那么这时候可以出发txRollback去回滚,然后重新发送消息。

你可能感兴趣的:(RabbitMQ全面解析)