今天為大家介紹push/pull模式，這是一個什麼模式呢？戰爭時期，食物緊缺，實行配給制，大家都排好隊，有人專門發放食物，前一個人領取了食物，後一個人跟上繼續領取食物，這個push端就是發放食物的，pull端就是領取食物的，所不同的是，現實中，你領取完了食物就不能排隊等候了，但zmq的push/pull模式中，一個pull端領取完了食物，可以繼續排隊等待push端發放食物。

        push端程式碼：

#coding=utf-8
'''
Created on 2015-10-29
 

@author: kwsy2015
‘’’
import zmq
import time

context = zmq.Context()
server = context.socket(zmq.PUSH)
server.bind(‘tcp://*:6666’)
count = 0
while True:
server.send(’%d’ % count)
print ‘send’,‘count’
count +=1
time.sleep(0.2)
pull端程式碼：

#coding=utf-8

‘’’

Created on 2015-10-29

@author: kwsy2015
‘’’
import zmq
context = zmq.Context()
client = context.socket(zmq.PULL)
client.connect(‘tcp://localhost:6666’)

while True:
msg = client.recv()
print msg

        開啟一個push端，開啟三個pull端，你可以通過列印的日誌感受這種模式

        push端只管向外推送資料，而不關心有多少個pull端連線自己，pull端呢，只管等待訊息，至於各個pull端是如何競爭的，我們不需要考慮，一個任務資料，只會被一個pull端接收，這個模式像不像一個小的負載均衡呢。

        在push/pull模式中，服務端和客戶端誰都可以先啟動，一方斷掉不會影響到另一方。

        熟悉redis的同學應該已經想到了，這種模式不就是redis裡的任務佇列麼，沒錯，其實呢，這個和redis裡的任務佇列沒有區別，但redis的任務佇列是不會丟失訊息的，也就是說，在redis中，一方不停的向任務佇列裡放任務，哪怕沒有客戶端從任務佇列裡取任務也是沒有任何問題的，想要達到redis任務佇列容量的最高上限恐怕是不容易的。但在zmq中，我們push的訊息卻是沒有一個數據庫來儲存的，訊息要麼在傳送緩衝區，要麼在接收緩衝區，要麼在從傳送緩衝區去接收緩衝區的路上，如果一方非常快的push訊息，而pull方卻動作緩慢，那麼訊息就會在這三個區域累積，累積的越多也就越危險。zmq中，套接字的連線都有自己的傳送或接收的管道和hwm,這個hwm就是管道的容量，在v2.x中，hwm預設是無限的，在v3.x版本中，預設為1000，我查閱了一些資料，卻沒有弄清楚這個1000的單位是什麼，M，K,還是訊息的數量？不得而知，但我們務必清楚，累積了太多總是不好的，就算hwm設定為無限，你的記憶體也總是有限的，這一點一定要在程式設計時注意