zeroMQ初体验-14.命名机制 进阶

[url=http://iyuan.iteye.com/blog/981677]前文[/url]曾提到过命名机制，事实上它是一把双刃剑。在能够持有数据等待重新连接的时候，也增加了持有数据方的负担(危险)，特别是在"发布/订阅"模式下，可谓牵一发而动全身。

这里先给出一组示例，在代码的运行过程中，通过重启消费者来观察发布者的进程状态。

发布端：

import zmq
import time

context = zmq.Context()

sync = context.socket(zmq.PULL)
sync.bind("tcp://*:5564")

publisher = context.socket(zmq.PUB)
publisher.bind("tcp://*:5565")

sync_request = sync.recv()

for n in xrange(10):
    msg = "Update %d" % n
    publisher.send(msg)
    time.sleep(1)

publisher.send("END")
time.sleep(1)  # Give 0MQ/2.0.x time to flush output

订阅端：

import zmq
import time

context = zmq.Context()

subscriber = context.socket(zmq.SUB)
subscriber.setsockopt(zmq.IDENTITY, "Hello")
subscriber.setsockopt(zmq.SUBSCRIBE, "")
subscriber.connect("tcp://localhost:5565")

sync = context.socket(zmq.PUSH)
sync.connect("tcp://localhost:5564")
sync.send("")

while True:
    data = subscriber.recv()
    print data
    if data == "END":
        break

订阅端得到的信息：

$ durasub
Update 0
Update 1
Update 2
^C
$ durasub
Update 3
Update 4
Update 5
Update 6
Update 7
^C
$ durasub
Update 8
Update 9
END

数据被发布者存储了，而发布者的内存占用也节节升高(很危险啊)。所以是否使用命名策略是需要谨慎选择的。为了以防万一，zeromq也提供了"高水位"机制，即当发送端持有数据达到一定数量就不再存储后面的数据，很好的控制了风险。这个机制也适当解决了[url=http://iyuan.iteye.com/blog/973013]这里[/url]的慢消费问题。

使用了 高水位 后的测试结果：

$ durasub
Update 0
Update 1
^C
$ durasub
Update 2
Update 3
Update 7
Update 8
Update 9
END

"高水位"封堵了内存崩溃的可能性，却是以数据丢失为代价的，zeromq也为此配对提供了"swap"功能，将内存中的数据转存入硬盘，实现了"既不耗内存又不丢数据"。

实现代码：

import zmq
import time

context = zmq.Context()

# Subscriber tells us when it's ready here
sync = context.socket(zmq.PULL)
sync.bind("tcp://*:5564")

# We send updates via this socket
publisher = context.socket(zmq.PUB)
publisher.bind("tcp://*:5565")

# Prevent publisher overflow from slow subscribers
publisher.setsockopt(zmq.HWM, 1)

# Specify the swap space in bytes, this covers all subscribers
publisher.setsockopt(zmq.SWAP, 25000000)

# Wait for synchronization request
sync_request = sync.recv()

# Now broadcast exactly 10 updates with pause
for n in xrange(10):
    msg = "Update %d" % n
    publisher.send(msg)
    time.sleep(1)

publisher.send("END")
time.sleep(1)  # Give 0MQ/2.0.x time to flush output

注意点：
高水位与交换区的设定，是需要根据实际运用状态来确定的，高水位设的过小，会影响到速度。
如果是数据存储端崩溃了，那么，所有数据将彻底消失。
关于高水位的特别说明：
除了PUB型会在达到高水位丢弃后续数据外，其他类型的都会以阻塞的形式来应对后续数据。
线程间的通信，高水位是通信双方共同设置的总和，如果有一方没有设置，则高水位规则不会起到作用。

（未完待续）