前言
这几年一直在it行业里摸爬滚打,一路走来,不少总结了一些python行业里的高频面试,看到大部分初入行的新鲜血液,还在为各样的面试题答案或收录有各种困难问题
于是乎,我自己开发了一款面试宝典,希望能帮到大家,也希望有更多的Python新人真正加入从事到这个行业里,让python火不只是停留在广告上。
微信小程序搜索:Python面试宝典
或可关注原创个人博客:https://lienze.tech
也可关注微信公众号,不定时发送各类有趣猎奇的技术文章:Python编程学习
发布与订阅
虽然redis在大多数的应用场景只是去做做缓存,或者数据的存储读取,但是其仍旧具有类似消息队列一样的发布订阅机制,并且我们可以通过这样的机制实现简易的消息队列,甚至在部分服务中结合像Celery
这样的工具实现broker
服务
发布和订阅pub/sub
,订阅者负责订阅频道,发送者负责像频道发送二进制字符串消息,每当有消息发布到订阅的这个频道,那么所有的订阅者都可以收到这个消息,
发布订阅也是像是我们生活中的电台,订阅者可以订阅收听多个电台,而发送者可以再任何电台发送消息
发布、订阅命令
指令 | 解释 |
---|---|
SUBSCRIBE CHANNLE | 订阅给定的一个或多个频道 |
UNSUBSCRIBE CHANNLE | 退订一个或多个频道,如果没有指定具体退订的频道,那么是全部退订 |
PSUBSCRIBE PATTERN | 订阅与给定模式相匹配的所有频道 |
PUNSUBSCRIBE PATTERN | 退订给定的模式相匹配的频道,未指定,则退订所有 |
PUBLISH CHANNLE MESSAGE | 向给定频道发送消息 |
在redis
中,只要按照如上的命令,选择你喜欢的一款频道名称,比如HAND_SOME_ZE_GE
,在这个频道进行消息的发布订阅即可
案例
如下为在本地测试的发布订阅
订阅晚于发布
在redis
中,订阅者最好先于发布者启动,否则发布者在订阅者启动前发布的消息,是无法被订阅者拿到的 ,好比你订阅的杂志,是不会把历史的期刊给你发一遍的
Python DEMO
以下是一个Python的小DEMO
,实现发布者订阅者
- 发布者,注意当订阅者迟于发布者时,可能会由于某些消息已经被发布而无法被新参与的订阅者拿到
def publish(conn):
'''
发布频道
conn: 连接对象
'''
time.sleep(1) # 让订阅者有充足的时间先订阅频道
for var in range(10):
conn.publish('channle',var)
time.sleep(1) # 消息发送间隔一秒
- 订阅者,这里注释部分提供了一个迟于发布者的订阅逻辑
def subscribe(conn):
'''
订阅频道
'''
pubsub = conn.pubsub()
# time.sleep(3) 当订阅迟于发布时,会丢失时间间隔内所发布的消息
pubsub.subscribe(['channle'])
i = 0
for item in pubsub.listen():
if i == 10:
pubsub.unsubscribe() # 退订!但是还不能跳出循环,要把这次取出来的打印了 下次跳出循环
if i == 11:
break
print('[SUB] : %s' % item)
sys.stdout.flush()
i += 1
- 入口函数
def main():
conn = redis.Redis(host='44.33.22.11',port=6379)
Thread(target=publish, args=(conn,)).start() # 开启发布者频道
subscribe(conn)
if __name__ == "__main__":
main()
发布、订阅模式的缺陷
对于旧版的Redis来说,如果某个订阅者的消息提取速度不够快的话,会导致消息积压而造成Redis输出缓冲区的体积变得越来越大,这可能会导致Redis的速度越来越慢,或者直接崩溃,也可能会导致Redis会被操作系统强制杀死,甚至导致操作系统不可用,毕竟这是在内存里的数据库
新版的Redis
不会出现这样的问题
- 此外,如果客户端在订阅消息操作过程中出现了断线,那么客户端将丢失在断线过程中发布者发送的所有消息