fjs的专栏

前面的文章介绍了比较简单的Request/Subscribe模式， 这篇文章介绍更为经典的Publish/Subscribe通信模式用来ZeroMQ的实现，其通信方式如下图：客户端（subscriber）向服务器（publisher）订阅消息，然后服务器可以将消息推送到所有订阅了消息的客户端，这里也可以理解为广播吧。。。。好了，闲话不多说了，直接上用ZeroMQ实现

基本上ZeroMQ（java）中基本的代码都算是过了一遍了吧，不过觉得它在日志这一块貌似基本没有做什么工作，也就是我们通过日志来知道ZeroMQ都发生了什么事情。。而且由于ZeroMQ中将连接的建立和重连接都进行了隔离，用户不需要做什么事情来维护连接，当然这样做的好处是使程序员的编码工作变少了，但是当然也有不好的地方，那就是用户失去了对ZeroMQ整个运行阶段的控制。。例如，当我们主动去连接一个远程地址，或者连接中断之后，没有日志告诉我们都这些事情发生了。。。当时对于一个消息通信系统来说，这些日志，或者

好像也有一段时间没有写博客了。。。ZeroMQ到现在，其实基本的原理也都了解的还算差不多了，剩下的就是一些细节的了。。。我们知道ZeroMQ中定义了很多类型的Socket，其实这个里面最为简单的就是Dealer类型的socket看了，它基本没有做太多额外的处理。。。在看具体的Dealer之前，先来看看两个类型，其实是两个工具类，用于维护在pipe上面执行的读写操作。。。首先是FQ类

前面的一篇文章分析了Dealer类型的Socket，它的行为是非常简单的，它会维护一个链表，在链表的前面是当前活动的pipe，因为pipe连接的是下面的Session，那么活动的pipe也就意味着活动的StreamEngine，那么也就意味着活动的连接，对于执行send方法，也非常的简单，就是在活动的pipe部分，通过循环的方式，选出一个pipe，将数据写进去就好了，因为可以看成是循环的遍

在ZeroMQ（java）中，整个IO的处理流程都是分层来进行的，当然处于最下端的肯定是前面介绍过的poller以及StreamEngin了。。。。涉及到上层的话就还有session，以及socket，先用一张图来大概的描述一下整个层次关系吧。。

哎，各种各样杂七杂八的事情。。。好久没有看代码了，其实要搞明白一个与IO相关的框架，最好的办法就是把它的I/0的读写两个过程搞清楚。。。例如在netty中，如果能将eventLoop的运行原理搞清楚，然后摸清楚整个I/O读写两个过程，那么也就差不太多了。。。。这次来看看ZeroMQ（java）中如何来处理I/O的，先来看看一个类型的定义，IOObject类型，这个类型应该扮演的是工具类的形象，

前面的文章中已经比较的清楚了ZeroMQ（java）中如何在底层处理IO，通过StreamEngine对象来维护SelectableChannel对象以及IO的事件回调，然后通过Poller对象来维护Selector对象，然后用IOObject对象来具体的管理SelectableChannel对象在Poller上面的注册，以及事件回调，他们之间的关系可以用下面的图形来简单的描述一下：

在进一步看ZeroMQ（java）的源代码之前，先来搞清楚一个必须要弄懂的地方吧。。。在前面使用ZeroMQ的时候，就会看到，里面的Socket更多的是一种伪Socket概念，更多的是一种用于维护真正的底层连接的形象，那么就很自然的会想到它持有和维护了底层的连接，可以将其看成是一个集合，其实在整个ZeroMQ的java实现中，这种持有和维护的结构有很多，于是在源码中抽象出了Own类型，用于处理

算是开始读ZeroMQ（java）的代码实现了吧，现在有了一个大体的了解，看起来实现是比较的干净的，抽象什么的不算复杂。。。这里先来看看它的I/O线程的实现吧，顺带看看是如何实现组件的通信的。。。。

前面见到过的Request和Response类型的socket都是同步的：例如Request，必须先要执行send，将请求发送出去，接着执行recv等待返回。。。这种最大的好处就是编程代码逻辑简单，坏处就是伸缩性比较差。。。于是就有了实现异步Request/Response的需求。。。那接下来来看看在ZeroMQ中是如何实现的吧：这个是官方的guid文档上面给出的构

我们在实际的应用中最常遇到的场景如下：A向B发送请求，B向A返回结果。。。。但是这种场景就会很容易变成这个样子：很多A向B发送请求，所以B要不断的处理这些请求，所以就会很容易想到对B进行扩展，由多个B来处理这些请求，那么这里就出现了另外一个问题：B对请求处理的速度可能不同，那么B之间他们的负载也是不同的，那么应该如何对请求进行分发就成了一个比较重要的问题。。。也就变

ZeroMQ(java)之Router与Dealer运行原理在开始这部分的内容之前,先来看看ZeroMQ中HWM概念---High-Water Marks当系统的数据量很大,而且发送频率很高的情况下,内存就很重要了,如果处理不好会出现很多问题,例如如下场景:A很快速的向B发送数据,但是B处理起来却很慢,这样子的话,数据就可能会在A的发送缓冲区,或者B的接收缓冲区累计起来....如果双方速度差太多,就很容易出现问题.......

在开始之前先把guid里面提到的几个ZeroMQ的特性列一下吧：（1）ZeroMQ有自己的I/O线程来异步的处理I/O，而且后台采用了无锁的数据结构（2）在ZeroMQ中，所有的组件都可以动态的加入和移除，而且可以启动组件以任何的顺利，例如我们可以先启动request，再启动response，依然可以工作，而且还会自动的重连接。（3）如果有需要的话，会自动的将message进行排队，当

ZeroMQ(java)之push/pull模式可以用于非常方便的实现任务分发，分布式数据统计等

ZeroMQ(java)入门之Requerst/Response模式强大的消息中间件或者说网络通信框架

前面的一篇文章分析了ZeroMQ中最为简单Socket类型，Dealer。。不过觉得这种具体的Socket类型的分析可以留到以后，或者等以后什么时候会用到了再分析再不迟。。。。但是作为一个消息通信的框架，最重要的还是通信的可靠性，而这其中最最重要的就是连接断开之后的重连接机制。。。