ZeroMQ学习笔记.docVIP

ZeroMQ学习笔记 1. API int zmq_recv (void *socket, void *buf, size_t len, int flags); int zmq_send (void *socket, void *buf, size_t len, int flags); zmq_recv 和 zmq_send 默认都是阻塞的，可以通过flags=ZMQ_DONTWAIT参数来设置为非阻塞模式。 buf 和 len都是靠应用程序来保证的。 对于阻塞模式，zmq_recv的返回值是接收到的字节数，注意如果超过 len，后面的数据将会被截断，但返回值的长度却是原本没有被截掉的长度。 如果错误，或者在非阻塞模式下没有消息，返回-1，并设置 errno。 2. 模式 2.1 request - reply 模式 如果server重启，那么这个模式就会失效，也就是说 server 和 client就不通消息了（可以有办法来解决这个问题，还没有看到那部分），但如果client重启的话是没有关系的。 并且一定要遵循一问一答的顺序，比如 send --receive --send ---receive ，中间如果顺序错了，比如发了两次，或收了两次就会出错，返回-1，或者先收再发也会同样出错。所以这是一个完全同步的模式，因为zmq不像socket，没有socket这个概念，如果这不同步的话就不知道是哪个连接发过来的，比如A，B都合C相连，C在监听，那么当收到数据之后，如果先收两个包放在本地，然后一个个返回，那么这个时候他就不知道要给A还是B，因为没有任何对应关系可循，这都是封装在里面的。 2.2 publish - subscribe 模式 这个模式是单向的，就是说 pub只能发， sub只能收 sub可以注册多个pub，并且多个pub上的消息会公平的过来。 如果pub没有任何sub，那么消息将会被丢弃 如果sub消费得比较慢，消息就会堆积在pub端 在v3.x版本里面，tcp 或 ipc的过滤是发生在publisher，而在低版本里面，所有的过滤都是发生在subscriber，这样就比较浪费流量和资源 sub 除了要创建 ZMQ_SUB 类型的socket，并连接之外，还要 调用 zmq_setsockopt (subscriber, ZMQ_SUBSCRIBE,filter, strlen (filter)); 来进行注册，才有效果。 其中filter用来匹配消息开头的字符串，如果匹配则接受下来，否则丢弃；但如果filter = NULL，并且长度为0的话，则表示所有的消息都接收。 publisher的第一个包经常是会被丢掉的，即便 sub端先起来，然后启动push 发送消息，刚开始的消息也有可能丢的 。因为即便是再快的网络，建立连接都是需要一些时间的，比如几个毫秒，而用zmq发送速度太快，在订阅者尚未与发布者建立联系时，已经开始了数据发布(内部局域网没这么夸张的)，再结合之前说的如果publisher没有任何subscriber连上来的话消息会被丢弃。官网给了两个解决方案;1, 让发布者先不发数据，而是等订阅者真正连上之后，再发数据; 2,就是发布是永不停止的，没有开始与尽头的概念。 2.3 push-pull 模式 这个模式和publish-subscrible有点像，数据都是单向流动，但push-pull是基于负载均衡的任务分发，就是说如果有多个 pull端，那么push出去的数据将会平衡得分配到各个pull端，并且一旦有一个点拿到了数据，其他pull端就没有了，就是说所有的pull拿到的数据合起来才是push的数据总和。 而 publish - subscribe则是 publish的数据，所有的subscribe都可以收到，当然如果进行了过滤则只能收到符合规则的数据。 3. 其它 ZMQ的通信层，是不分哪个主动监听，哪个主动连接的，所以你可以在任意一端监听，另一端来connect。 context：一个进程只有一个context，所有的socket都在其中维护着，如果你创建了两个context，那么他们是完全独立的，一般不用这么做。 一般在开头创建context，在结尾 destory它。 如果先创建了context，然后fork了一个子进程，那么子进程会自动得到一个context，并且是和父进程独立的。 context是线程安全的，就是说多个线程可以共享它，并且不用加锁。 socket：不是线程安全的 3.2 资源清理 zmq对于资源的清理是很重要的，如果有一个socket没有关闭，那么zmq_ctx_destory 将会永远挂起，即便你关闭了socket，如果有pending的连接或发送的话，zmq_