生產者消費者模型

2022-08-22 10:18:13 字數 2696 閱讀 5622

目錄joinablequeue

模型就是解決某個固定問題的方法或者套路

案例:

食堂飯店就是生產者,負責做飯

負責吃飯的就是消費者

那我們來想一想,這兩者之間是否有什麼問題,我需要做到的是做飯的和吃飯的能夠做到無縫銜接,也就是飯店剛做好飯,剛好吃飯的來了?

問題1:飯店不知道什麼時候吃飯的回來

問題2:吃飯的不知道飯店什麼時候做好飯

這樣一來,就會造成效率低,因為雙方的處理速度不同,乙個塊乙個慢,則雙方需要相互等待

先將雙方解開耦合,讓不同的程序負責不同的任務

提供乙個共享的容器來平衡雙方的能力,可以使用佇列

from multiprocessing import process,queue

import requests

import re,os,time,random

# 生產者任務

def product(urls,q):

i = 0

for url in urls:

response = requests.get(url)

text = response.text

# 將生產完成的資料放入佇列中

time.sleep(random.random())

q.put(text)

i += 1

print(os.getpid(),"生產了第%s個資料" % i)

def customer(q):

i = 0

while true:

text = q.get()

time.sleep(random.random())

res = re.findall('src=//(.*?) width', text)

i += 1

print(" 第%s個任務獲取到%s個img" % (i,len(res)))

if __name__ == '__main__':

urls = [

"","",

"","",

]# 建立乙個雙方能共享的容器

q = queue()

# 生產者程序

p1 = process(target=product,args=(urls,q))

p1.start()

# 消費者程序

c = process(target=customer,args=(q,))

c.start()

'''42848 生產了第1個資料

42848 生產了第2個資料

第1個任務獲取到1個img

42848 生產了第3個資料

第2個任務獲取到1個img

42848 生產了第4個資料

第3個任務獲取到1個img

第4個任務獲取到1個img

'''

問題來了:消費者啥時候結束呢

joinablequeue繼承自queue,與queue的用法一致,在queue的基礎上,增加了join和task_down兩個方法

join是乙個阻塞函式,會阻塞到task_down呼叫次數和存入的元素數量一致時,可以用於表示佇列任務處理完成

from multiprocessing import process,joinablequeue

import time,random

"""生產者 負責生產熱狗

消費者 負責吃熱狗

"""# 生產者任務

def product(q,name):

for i in range(5):

dog = "%s的熱狗%s" % (name,(i + 1))

time.sleep(random.random())

print("生產了",dog)

q.put(dog)

# 吃熱狗

def customer(q):

while true:

dog = q.get()

time.sleep(random.random())

print("消費了%s" % dog)

q.task_done() # 標記這個任務處理完成

if __name__ == '__main__':

# 建立乙個雙方能共享的容器

q = joinablequeue()

# 生產者程序

p1 = process(target=product,args=(q,"上海分店"))

p2 = process(target=product,args=(q,"北京分店"))

p1.start()

p2.start()

# 消費者程序

c = process(target=customer,args=(q,))

# c.daemon = true # 可以將消費者設定為守護程序 當主程序確認 任務全部完成時 可以隨著主程序一起結束

c.start()

p1.join()

p2.join() # **走到這裡意味著生產方完成

q.join() # 意味著佇列中的任務都處理完成了

# 結束所有任務

c.terminate() # 直接終止消費者程序

redis 訊息佇列

mq 訊息佇列

常用來做流量削峰,保證伺服器不會因為高併發而發生奔潰

生產者消費者模型

1.生產者消費者問題 producer consumer 有限緩衝,多執行緒同步。生產者執行緒和消費者執行緒共享固定大小緩衝區。2.關鍵是保證生產者不會再緩衝區滿時加入資料,消費者不會在緩衝區空時消耗資料。3.解決辦法 讓生產者在緩衝區滿時休眠,等下次消費者消耗緩衝區中的資料的時候,生產者才能被喚醒...

生產者消費者模型

生產者與消費者 3,2,1 三種關係 生產者與消費者 互斥,同步 消費者與消費者 互斥 生產者與生產者 互斥 條件變數 int pthread cond destroy pthread cond t cond int pthread cond init pthread cond t restrict...

生產者消費者模型

當佇列滿時,生產者需要等待佇列有空間才能繼續往裡面放入商品,而在等待的期間內,生產者必須釋放對臨界資源 即佇列 的占用權。因為生產者如果不釋放對臨界資源的占用權,那麼消費者就無法消費佇列中的商品,就不會讓佇列有空間,那麼生產者就會一直無限等待下去。因此,一般情況下,當佇列滿時,會讓生產者交出對臨界資...