RabbitMQ
消息队列
作用:
1)程序解耦
允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。
2)冗余:
消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。
许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。
3)峰值处理能力:
(大白话,就是本来公司业务只需要5台机器,但是临时的秒杀活动,5台机器肯定受不了这个压力,我们又不可能将整体服务器架构提升到10台,那在秒杀活动后,机器不就浪费了吗?因此引入消息队列)
在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。
如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。
使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。
4)可恢复性:
系统的一部分组件失效时,不会影响到整个系统。
消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。
5)顺序保证:
在大多使用场景下,数据处理的顺序都很重要。
大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。(Kafka保证一个Partition内的消息的有序性)
6)缓冲:
有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致的情况。
7)异步通信:
很多时候,用户不想也不需要立即处理消息。比如发红包,发短信等流程。
消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。
rabbitMQ
-
安装rabbitmq
yum -y install erlang yum -y install rabbitmq-server
-
开启rabbitmq服务端
systemctl start rabbitmq-server
-
开启rabbitmq的管理页面
rabbitmq-plugins enable rabbutmq_management
-
创建rabbitmq的后台管理用户
sudo rabbitmqctl add_user yan 123456 #创建用户 sudo rabbitmqctl set_user_tags yan administrator #设置用户管理员身份 sudo rabbitmqctl set_permissions -p "/" yan ".*" ".*" ".*" #允许yan用户,对所有的队列都可以读写
-
重启rebbitmq服务端
systemctl restart rabbitmq-server
-
查看端口
netstat -tunlp # 访问 192.168.16.66:15672
-
下载pika模块,实现生产消费者
pip3 install pika
单发送单接收
创建一个pro.py
文件,写入如下代码,作为消费者
#!/usr/bin/env python
import pika
# 创建凭证,使用rabbitmq用户密码登录
# 去邮局取邮件,必须得验证身份
credentials = pika.PlainCredentials("yan","123456")
# 新建连接,这里localhost可以更换为服务器ip
# 找到这个邮局,等于连接上服务器
connection = pika.BlockingConnection(pika.ConnectionParameters('192.168.16.66',credentials=credentials))
# 创建频道
# 建造一个大邮箱,隶属于这家邮局的邮箱,就是个连接
channel = connection.channel()
# 声明一个队列,用于接收消息,队列名字叫“西游记”
channel.queue_declare(queue='西游记')
# 注意在rabbitmq中,消息想要发送给队列,必须经过交换(exchange),初学可以使用空字符串交换(exchange=''),它允许我们精确的指定发送给哪个队列(routing_key=''),参数body值发送的数据
channel.basic_publish(exchange='',
routing_key='西游记',
body='大师兄,师傅被妖怪抓走了')
print("已经发送了消息")
# 程序退出前,确保刷新网络缓冲以及消息发送给rabbitmq,需要关闭本次连接
connection.close()
运行:
python3 pro.py
创建一个con.py
文件,写入消费者的代码
import pika
# 建立与rabbitmq的连接
# 前四行都是连接到同一个rabbitmq服务端以及同一个队列
credentials = pika.PlainCredentials("yan","123456")
connection = pika.BlockingConnection(pika.ConnectionParameters('192.168.16.66',credentials=credentials))
channel = connection.channel()
channel.queue_declare(queue="西游记")
def callbak(ch,method,properties,body):
print("消费者取出了消息:%r"%body.decode("utf8"))
# 有消息来临,立即执行callbak,没有消息则夯住,等待消息
# 老百姓开始去邮箱取邮件啦,队列名字是西游记
channel.basic_consume(callbak,queue="西游记",no_ack=True) # no_ack 表示不用确认
# 开始消费,接收消息
channel.start_consuming()
ACK机制 -- 消息确认
默认情况下,生产者发送数据给队列,消费者取出消息后,数据将被清除。
特殊情况,如果消费者处理过程中,出现错误,数据处理没有完成,那么这段数据将从队列丢失。
no-ack机制:不确认机制也就是说每次消费者接收到数据后,不管是否处理完毕,rabbitmq-server都会把这个消息标记完成,从队列中删除。
ack机制:ACK机制用于保证消费者如果拿了队列的消息,客户端处理时出错了,那么队列中仍然还存在这个消息,提供下一位消费者继续取。
生产者 pro.py
# 消息之ack机制
#!/usr/bin/env python
import pika
# 创建凭证,使用rabbitmq用户密码登录
# 去邮局取邮件,必须得验证身份
credentials = pika.PlainCredentials("yan","123456")
# 新建连接,这里localhost可以更换为服务器ip
# 找到这个邮局,等于连接上服务器
connection = pika.BlockingConnection(pika.ConnectionParameters('192.168.16.66',credentials=credentials))
# 创建频道
# 建造一个大邮箱,隶属于这家邮局的邮箱,就是个连接
channel = connection.channel()
# 新建一个hello队列,用于接收消息
# 这个邮箱可以收发各个班级的邮件,通过
channel.queue_declare(queue='金品没')
# 注意在rabbitmq中,消息想要发送给队列,必须经过交换(exchange),初学可以使用空字符串交换(exchange=''),它允许我们精确的指定发送给哪个队列(routing_key=''),参数body值发送的数据
channel.basic_publish(exchange='',
routing_key='金品没',
body='大郎,起来喝药了')
print("已经发送了消息")
# 程序退出前,确保刷新网络缓冲以及消息发送给rabbitmq,需要关闭本次连接
connection.close()
消费者 con.py no_ack=False
import pika
credentials = pika.PlainCredentials("yan","123456")
connection = pika.BlockingConnection(pika.ConnectionParameters('192.168.16.66',credentials=credentials))
channel = connection.channel()
# 声明一个队列(创建一个队列)
channel.queue_declare(queue='金品没')
def callback(ch, method, properties, body):
print("消费者接受到了任务: %r" % body.decode("utf-8"))
int('asdfasdf')
# 我告诉rabbitmq服务端,我已经取走了消息
# 回复方式在这
ch.basic_ack(delivery_tag=method.delivery_tag)
# 关闭no_ack,代表给与服务端ack回复,确认给与回复
channel.basic_consume(callback,queue='金品没',no_ack=False) # no_ack=False 禁止不确认机制,代表需要给与服务端消息确认回复
channel.start_consuming()
消息持久化
让队列以及消息支持持久化,防止异常崩溃,消息丢失。
消息的可靠性是RabbitMQ的一大特色,那么RabbitMQ是如何保证消息可靠性的呢——消息持久化。 为了保证RabbitMQ在退出或者crash等异常情况下数据没有丢失,需要将queue,exchange和Message都持久化。
生产者 pro.py
import pika
# 无密码
# connection = pika.BlockingConnection(pika.ConnectionParameters('123.206.16.61'))
# 有密码
credentials = pika.PlainCredentials("yan","123456")
connection = pika.BlockingConnection(pika.ConnectionParameters('192.168.16.66',credentials=credentials))
channel = connection.channel()
# 声明一个队列(创建一个队列)
# 默认此队列不支持持久化,如果服务挂掉,数据丢失
# durable=True 开启持久化,必须新开启一个队列,原本的队列已经不支持持久化了
'''
实现rabbitmq持久化条件
delivery_mode=2
使用durable=True声明queue是持久化
'''
channel.queue_declare(queue='LOL',durable=True) #此步表示队列是支持持久化的参数
channel.basic_publish(exchange='',
routing_key='LOL', # 消息队列名称
body='我用双手成就你的梦想',
# 支持数据持久化
properties=pika.BasicProperties(
delivery_mode=2, # 代表消息是持久的2
)
)
connection.close()
RPC 远程过程调用
将一个函数运行在远程计算机上并且等待获取那里的结果,这个称作远程过程调用(Remote Procedure Call)或者 RPC。
RPC是一个计算机通信协议。
Callback queue 回调队列:一个客户端向服务器发送请求,服务器端处理请求后,将其处理结果保存在一个存储体中。而客户端为了获得处理结果,那么客户在向服务器发送请求时,同时发送一个回调队列地址reply_to
。
Correlation id 关联标识:一个客户端可能会发送多个请求给服务器,当服务器处理完后,客户端无法辨别在回调队列中的响应具体和那个请求时对应的。为了处理这种情况,客户端在发送每个请求时,同时会附带一个独有correlation_id
属性,这样客户端在回调队列中根据correlation_id
字段的值就可以分辨此响应属于哪个请求。
利用RabbitMQ构建一个RPC系统,包含了客户端和RPC服务器,依旧使用pika模块。
rpc_server.py
import pika
import uuid
class FibonacciRpcClient(object):
def __init__(self):
# 客户端启动时,创建回调队列,会开启会话用于发送RPC请求以及接受响应
# 建立连接,指定服务器的ip地址
self.connection = pika.BlockingConnection(pika.ConnectionParameters(
host='192.168.16.66'))
# 建立一个会话,每个channel代表一个会话任务
self.channel = self.connection.channel()
# 声明回调队列,再次声明的原因是,服务器和客户端可能先后开启,该声明是幂等的,多次声明,但只生效一次
#exclusive=True 参数是指只对首次声明它的连接可见
#exclusive=True 会在连接断开的时候,自动删除
result = self.channel.queue_declare(exclusive=True)
# 将次队列指定为当前客户端的回调队列
self.callback_queue = result.method.queue
# 客户端订阅回调队列,当回调队列中有响应时,调用`on_response`方法对响应进行处理;
self.channel.basic_consume(self.on_response, no_ack=True,
queue=self.callback_queue)
# 对回调队列中的响应进行处理的函数
def on_response(self, ch, method, props, body):
if self.corr_id == props.correlation_id:
self.response = body
# 发出RPC请求
# 例如这里服务端就是一个切菜师傅,菜切好了,需要传递给洗菜师傅,这个过程是发送rpc请求
def call(self, n):
# 初始化 response
self.response = None
# 生成correlation_id 关联标识,通过python的uuid库,生成全局唯一标识ID,保证时间空间唯一性
self.corr_id = str(uuid.uuid4())
# 发送RPC请求内容到RPC请求队列`s24rpc`,同时发送的还有`reply_to`和`correlation_id`
self.channel.basic_publish(
exchange='',
routing_key='s24rpc', properties=pika.BasicProperties( reply_to=self.callback_queue, correlation_id=self.corr_id,),
body=str(n))
while self.response is None:
self.connection.process_data_events()
return int(self.response)
# 建立客户端
fibonacci_rpc = FibonacciRpcClient()
# 发送RPC请求,丢进rpc队列,等待客户端处理完毕,给与响应
print("发送了请求sum(99)")
response = fibonacci_rpc.call(99)
print("得到远程结果响应%r" % response)
rpc_client.py
import pika
# 建立连接,服务器地址为localhost,可指定ip地址
connection = pika.BlockingConnection(pika.ConnectionParameters(
host='192.168.16.66'))
# 建立会话
channel = connection.channel()
# 声明RPC请求队列
channel.queue_declare(queue='s24rpc')
# 模拟一个进程,例如切菜师傅,等着洗菜师傅传递数据
def sum(n):
n+=100
return n
# 对RPC请求队列中的请求进行处理
def on_request(ch, method, props, body):
print(body,type(body))
n = int(body)
print(" 正在处理sum(%s)" % n)
# 调用数据处理方法
response = sum(n)
# 将处理结果(响应)发送到回调队列
ch.basic_publish(exchange='',
# reply_to代表回复目标
routing_key=props.reply_to,
# correlation_id(关联标识):用来将RPC的响应和请求关联起来。
properties=pika.BasicProperties(correlation_id= \
props.correlation_id),
body=str(response))
ch.basic_ack(delivery_tag=method.delivery_tag)
# 负载均衡,同一时刻发送给该服务器的请求不超过一个
channel.basic_qos(prefetch_count=1)
channel.basic_consume(on_request, queue='s14rpc')
print("等待接收rpc请求")
# 开始消费
channel.start_consuming()