分享基于分布式Http长连接框架--架构模型

我画了个简单的架构图来帮助说明:

其实为发布订阅架构模式.

生产者和消费者我们统一可理解为客户端，消息中间件可认为是服务端.

生产者和消费者做为客户端要跟服务端交互，则先通过代理订阅服务端，订阅成功后即可跟服务端互通互联，此刻的连接通道为长连接.

长连接的优势在于会将消息主动通知到客户端，避免客户端去做大量的轮询工作而造成资源浪费，而且对于移动应用来说，可较大程度上节省GPRS流量.

当连接建立好后，生产者可随时发送消息，如果在发消息过程当中，服务端由于各种原因不能连接，则消息的发送会回放重试，当达到一定的阀值则转为死信存挡.

而消费者则处于监听状态，一旦有消息过来则立即做出响应，响应方式有两种，1为同步，2为异步;不同的消息消费可以订阅为不同的响应方式.

服务端则处于居中调度，统一处理消息，制定发送消息策略，因为生产者不关心消费者，当生产者在发送消息的时候，要处理消息的消费者却停机了，则服务端会尝试给指定的消费

者重发消息，当超过一定时间，消费者还是处于停机状态则此消息转为死信归档，但如果在规定的时间内消费者恢复工作，则仍会收到消息通知避免因为没有收到消息而造成业务损失.

为了防止消息的可靠性传输，我在每个环节都会冗余消息体.一旦任何一个环节出现问题都能最大限度的保证消息不会丢失.至于用什么存储机制，则灵活定制.

我们知道生产者和消费者之间通过宿主服务来交互，以Message为载体,这样的好处是一可以解耦，可以明确职责，各自独立优化，生产者发消息不关心消费者是谁，只是单纯的执

行命令，而消费者接收到消息后进行后续的业务处理，二来可以扩展，可以部署多个消息中间件来应对高并发的消息处理，避免单点的故障问题.

对于多个生产者和多个消费者如果单个服务端无法应对大并发情况，则可横向扩展多个服务端，按组分配到不同的客户端使用即可.所以可以一定程度上应对分布式的应用.

今天又更新了下代码,欢迎提建议.源码地址:https://zycomet.codeplex.com