最近使用了一下ZMQ的java版本，先不评述其它，网上已经有很多内容了。
我通过ZMQ的模式，在MsgClient,MsgServer中封装了基础ZMQ的使用。以此扩展了使用模型；
主要是基于2类分布式
1.订阅发布模型
你可以原样使用订阅发布ZMQ。我再此基础上进行了如图扩展
MQ为消息中心，发布端将消息发送给MQ，订阅端订阅；每个MQ处理了接收发布，订阅的端口外，另外添加了自己节点的全数据接口，可以将节点的所有数据发送出去，我称为级联接口，另外还有一个服务验证端口；
如图，MQ1与MQ2建立了级联，则SUB2将可以收到PUB1,PUB2的数据，SUB1只能接受PUB1的数据，类似，SUB3可以接收PUB1,PUB2,PUB3的数据，MQ2启动后与MQ1级联，则MQ2会订阅MQ1的全数据。
如果MQ1如果通过请求服务端口，连接不上，则认为MQ1死亡，有MQ2建立了级联关系，如果发布订阅端设置了允许判断更新，那么PUB1,SUB1将自动连接到MQ2,直到MQ1恢复，PUB1,SUB1将再次连接到MQ1.
级联信息及发布订阅地址，是每个MQ提供一个服务接收，专门处理，所以一个完整的扩展，MQ就需要5个端口；分别是发布订阅的前后端2个，级联全数据1个，请求服务1个以及1个监视端口；
MQ定时会向监视管理地址发送MQ信息，原设计是监视管理接收到MQ信息，通过该信息，可以向每个MQ的请求服务发送指令，随时建立级联，网页图像化，类似上图，拖到箭头就可以使MQ建立级联关系。监视管理客户端现在没有实现，我不是做前端的。
补充：上面的扩展有一个问题，监测MQ的死亡需要时间，默认20秒，那么这20秒内的数据怎么办呢，为了解决该问题，默认把最近20000包数据缓存在内存中，如果超出就落盘（嵌入式数据库），开启一个线程，不断删除20秒以外的落盘数据，同时最新的落盘。一旦MQ发送死亡通过级联更新发布订阅地址，则将最新的数据再次发送。开启该功能订阅端已经了消息重复判断。每一个发布端进程，都会在消息数据头上加入一个消息ID（IP+PID+标识，标识的方式是时间戳（ddHHmmss）+序列号，当前认为每秒最大10w包生成）;订阅端会记录接收的消息ID,判断最近30s内是否接收过该信息，解析的时间是根据标识的时间戳30s，这样解决死亡丢失和重复问题。当然如果开启了该功能，则会造成jar很大，引入了嵌入式数据库包，同时会增加内存。所以在没有必要的情况下建议关闭。缓存的包数，判断的时间都可以自己根据需要设置。
2.分布式服务模型
分布式服务模型直接使用了ZMQ的代理模式router-dealer
简单使用原来模式即可完成，也可以自己多重组合
针对以上模式的扩展，将代理变为多个，进行主从备份，原来类似订阅发布
扩展模型如图：
REQ,REP封装了生产类，为一个REQ,REP组，生产的组可以将代理1，代理2的地址同时传入，在生产时，获取到master,双方都会去连接master地址，如果代理没有指定master,则IP,端口大的为master.生产类会隔一段时间要求各个组检查自己的连接状态，如果连接的代理死亡，就连接其它代理，直到master恢复后重新置回。
检查的方式依然是每个代理另外提供一个端口（代理的服务端口+1），提供一个服务检查，检查失败或者检查到代理设置了master就要要求各个组处理。服务不用解决时间内失效问题，请求会自然返回错误。
该代码已经上传git
地址：
https://github.com/jinyuttt/ZMQMSG.git