最近在看后台框架的源码中，在初次看到系统的三层架构中使用了中间件rabbitmq,可能之前没有使用过相关的中间件，一时之间在看到rabbitmq中间件的使用的时候，没有看懂，于是看了相关的博客，发现很多博客都只是很抽象的描述了，但我们在看代码的过程中，里面的数据其实还是比较复杂的，导致了第一次直接看源码的时候并没有了解到其真正的含义，如果想更好的了解，其实根本不用看相关的博客，rabbitmq官网的说明其实很清晰，同时为了是自己更好的加深对rabbitmq的理解，决定写一篇相关的博客，同时也帮助和我一样第一次没有看懂的人更好的去理解。为了便于方便的描述，不掺杂过多的代码，我们查看python代码的实现以及借助官网的图片.
rabbitmq的第一种方式（我们最容易理解的方式，也就是exchange不工作的状态）
生产者
1.与rabbitmq建立连接
2.获取连接的句柄
3.声明队列
4.通过basic_publish生产消息 由于exchange不工作，必须通过routing_key来指明消息发往哪放个队列 body未发送的消息
5.关闭连接
消费者
1.与rabbitmq建立连接
2.获取连接的句柄
3.声明队列（这里为什么要再次声明队列 我们无法确保是生产者还是消费者那个先启动，因此在双方声明了队列，如果由一方发现队列已经存在 则不会再创建）
4.通过basic_consume消费消息 callback为上拿到消息后要执行的回调函数 queue指明从那个对列去获取消息 no_ack 表明不必做出回复
5.关闭连接
扩展
.消息的持久化处理 在声明队列的时候声明队列的属性durable = true
.消费者消费消息后 确认消息已经消费 no_ack = false
1） 如果接收方一直不发送确认消息，消息将会在队列中积压，从而严重影响性能；
2） 如果接收方在发送确认消息前崩溃了，那么在他下次启动时，该消息仍然会推送给他。
3） 如果队列上同时连接了多个接收方，其中一个崩溃了，那么Rabbitmq会将该接收方未确认的消息发送给其他接收方。
4） 消息确认没有超时机制，只要接收方和Rabbitmq的连接存在，就不会超时；如果连接断开了而消息仍然未确认，那么Rabbitmq会将未确认的消息发送给其他接收方，如果没有其他接收方的话，则消息会一直存在于队列中。
rabbitmq的第二种工作方式(Fanout 发布/订阅 exchange工作 此时生产者不在直接将消息发送到消息队列中 而是发送给exchange 再由exchange发送到相对应的队列中)
1.与rabbitmq建立连接
2.获取连接的句柄
3.声明交换机的名字与交换机的类型
4.发送消息到交换机
5.关闭连接
1.与rabbitmq建立连接
2.获取连接的句柄
3.交换机声明
4.声明队列
5.将队列与交换机进行绑定(此时交换机并不知道将消息发送给那个队列 因此我们要将队列与交换机进行绑定)
6.消费信息
7.关闭连接
扩展
如果在一个队列上有多个消费者，那么rabbitmq会自动在多个消费者之间进行负载均衡。当接收方处理完一条消息后，rabbitmq会将消息从队列中删除。
rabbitmq的第三种工作方式(direct方式)
1.与rabbitmq建立连接
2.获取连接的句柄
3.声明交换机的名字与交换机的类型
4.发送消息到交换机
5.关闭连接
1.与rabbitmq建立连接
2.获取连接的句柄
3.交换机声明
4.声明队列
5.将队列与交换机进行绑定(此时交换机并不知道将消息发送给那个队列 因此我们要将队列与交换机进行绑定)
6.消费信息
7.关闭连接
rabbitmq的第四种工作方式(topic)
1.与rabbitmq建立连接
2.获取连接的句柄
3.声明交换机的名字与交换机的类型
4.发送消息到交换机
5.关闭连接
1.与rabbitmq建立连接
2.获取连接的句柄
3.交换机声明
4.声明队列
5.将队列与交换机进行绑定(此时交换机并不知道将消息发送给那个队列 因此我们要将队列与交换机进行绑定)
6.消费信息
7.关闭连接
我们可以看出exchange工作的其他三种方式其实类似 ，唯一不同的是:
1.direct 发送的消息与routingkey 和 bindingkey无关 只需要将队列与交换机进行绑定
2.fanout 发送的消息会根据routingkey和bindingkey的相等关系来到进行发送
3.topic 发送的消息会根据routingkey和bindingkey进行部分匹配而进行发送
rammbitmq 的另一种功能 RPC远程调用
1） 客户端首先创建一个队列用于接收应答消息，并使用一个BindingKey将该队列绑定到一个Exchange上
2） 客户端发送请求消息前，将该消息的ReplyTo属性设置为应答队列的BindingKey；
3） 服务端收到请求消息，以进行业务处理，处理完成后生成一个应答消息，并取接收消息的ReplyTo属性，使用这个属性作为应答消息的RoutingKey，从而就可以将消息正确的发送给客户端了。
4） 如果客户端是多线程的，应答消息除了要找到对应的客户端外，还要和请求消息对应起来，这个时候可以使用CorrelationID。客户端设置好请求消息的CorrelationID，服务端获取请求消息的CorrelationID后，将其原样写入应答消息的CorrelationID属性中。这样客户端收到应答消息后，就可以利用CorrelationID和请求消息进行对应了。
当然整个后台的框架远不止这些 其中涉及到了很多之前并没有了解到的技术，如logcplus,protobuf,com组件以及redis内存数据等等值得学习的技术。
扫一扫
10万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
