分布式消息队列(消息中间件)

消息队列技术是分布式应用间交换信息的一种技术。有了它&＃xff0c; 可以很方便快捷地实现各分布组件间的通讯和信息交换。

XMPP 和 AMQP 是两个开放的消息标准&＃xff1a;
Extensible Messaging and Presence Protocol (XMPP) 是基于可扩展标记语言(XML)的协议, 它用于即时消息(IM)以及状态显示(Presence)

支持AMQP的开源broker: 比较有名的是ActiveMQ, 是Apache下的一个项目,这里采用的是RabbitMQ, RabbitMQ是Erlang写的&＃xff0c;因为Erlang对高并发的支持非常擅长&＃xff0c;因此RabbitMQ的表现自然也不逊色
ejabberd is a Jabber/XMPP instant messaging server.

http://www.imneio.com/2009/10/zeromq_in_dotnet/
RabbitMQ是采用Erlang开发的&＃xff0c;支持完善的AMQP协议&＃xff1b;ZeroMQ使用C语言开发&＃xff0c;重点在于效率&＃xff1b;两者均有多语言支持&＃xff0c;其中ZeroMQ支持得较多。
比较看, RabbitMQ支持的AMQP协议&＃xff0c;较为完整和复杂&＃xff1b;而ZeroMQ的接口极为简单。速度上&＃xff0c;还未对亲自对两者做压力测试。从网上的资料看&＃xff0c;RabbitMQ较慢&＃xff0c;几十个并发以内&＃xff0c;延时为几十毫秒&＃xff0c;但当客户端达到1000个并发的时候&＃xff0c;速度就无法容忍了&＃xff08;参考&＃xff09;&＃xff1b;ZeroMQ上则据称可以达到13毫米延时和高达每秒4.1兆次传递&＃xff08;参考, 国内需要翻墙才能访问&＃xff09;。如果队列较多的话&＃xff0c;RabbitMQ很容易把内存耗尽&＃xff0c;而ZeroMQ则把队列内容保存在发送端。

Advanced Message Queuing Protocol (AMQP):  http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
http://www.infoq.com/articles/AMQP-RabbitMQ

http://blog.pluskid.org/?p&＃61;376
AMQP 里主要要说两个组件&＃xff1a;Exchange 和 Queue &＃xff08;在 AMQP 1.0 里还会有变动&＃xff09;&＃xff0c;Producer 要产生消息必须要创建一个 Exchange &＃xff0c;Exchange 用于转发消息&＃xff0c;但是它不会做存储&＃xff0c;如果没有 Queue bind 到 Exchange 的话&＃xff0c;它会直接丢弃掉 Producer 发送过来的消息.
一个 Consumer 想要接受消息的话&＃xff0c;就要创建一个 Queue &＃xff0c;并把这个 Queue bind 到指定的 Exchange/topic 上&＃xff0c;然后 Exchange 会把消息转发到 Queue 那里&＃xff0c;Queue 会负责存储消息&＃xff0c;Consumer 可以通过主动 Pop 或者是 Subscribe 之后被动回调的方式来从 Queue 中取得消息.

https://www.amqp.org/confluence/display/AMQP/About&＃43;AMQP
AMQP是消息中间件的开放标准, 和语言、平台无关。定义的功能有message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security.

http://blog.csdn.net/ctowoo/archive/2009/12/18/5032047.aspx Web应用中的轻量级消息队列: Twitter以前就使用RabbitMQ

(http://www.rabbitmq.com/)实现消息队列服务&＃xff0c;现在又转而使用Kestrel(http://github.com/robey/kestrel)来实现消息队列服务&＃xff0c;此外还有很多其他的选择&＃xff0c;比如说&＃xff1a;ActiveMQ(http://activemq.apache.org/)&＃xff0c;ZeroMQ(http://www.zeromq.org/)等。

JGroups

JGroups 是一个的可靠的群组通讯工具。应用程序可以实现加入一个group&＃xff0c;发送接收消息给组内所有成员或指定成员&＃xff0c;框架会自动跟踪group内事件的通知
&＃xff08;如成员加入&＃xff0c;离开&＃xff0c;crash等&＃xff09;。Group通过group name来区分。
http://www.jgroups.org/

JGroup是当前被广泛使用的可靠组间通信的工具之一。例如OSCache以及JBossTreeCache都是用的是JGroup。
       JGroup功能十分强大&＃xff0c;通过配置各种参数就可以充分利用它所提供的各项功能。JGroup最大的特点就是支持协议栈的可配置性&＃xff0c;它本是实现了基本的Java的协议栈实现&＃xff0c;也就是最基本的消息广播的基础&＃xff0c;同时支持附加协议栈的配置&＃xff0c;消息的传递就是在这些协议栈之间相互传递&＃xff0c;封装&＃xff0c;检查&＃xff0c;丢弃&＃xff0c;重发。JGroup可以基于TCP协议来实现消息广播&＃xff0c;也可以通过UDP方式来广播消息&＃xff0c;利弊不言而喻&＃xff0c;TCP可靠&＃xff0c;但是代价大&＃xff0c;性能没有UDP来的好&＃xff0c;UDP速度快&＃xff0c;代价小&＃xff0c;但是消息的丢失率以及无序性有着很大的限制。但是JGroup在UDP方式的基础上&＃xff0c;增加了协议栈的配置&＃xff0c;通过配置上层的协议&＃xff0c;可以保证消息的重发&＃xff0c;大包体的分解&＃xff08;同时保证消息包体顺序&＃xff09;&＃xff0c;组内机器的状态检测等功能。
      
它的优势&＃xff1a;
   无需配置服务器
   可以同时对group所有成员进行调用
  
缺陷:
1.首先是采用了Jboss treeCache&＃xff0c;这是一种分布式的Cache&＃xff0c;大部分现有的开源的分布式Cache都采用了Jgroup来消息传播&＃xff0c;以保证数据的一致性&＃xff0c;但是Jgroup一直有个问题没有解决&＃xff0c;就是Jgroup中有Master node和 salve node之分&＃xff0c;当有新的service node需要加入的时候&＃xff0c;需要Jgoup中的各个master去审批&＃xff0c;当master失效的时候&＃xff0c;就会导致其它的节点无法加入或者消息出现传播问题&＃xff0c;其中也有参数配置Master的失效的策略&＃xff0c;配置上去以后的却解决了大部分的问题&＃xff0c;但是偶尔还是在集群重启后出现问题。
2.一个网状拓扑&＃xff0c;一个节点的每个变化需要通知其他N-1个其他节点&＃xff0c;造成网络较大的负载。
3. 潜在的数据不一致
解决的办法是通过&＃xff1a;同步传递。客户端请求先处于挂起状态&＃xff0c;在同步传递并在所有缓存中数据都同步之后再返回。
4. 没有deamon方式运行的server, 不可能实现多应用缓存共享