分布式系统中发送消息，进行异步通信，是一个与具体平台无关的API。TIBCO Rendezvous（或称为TIBCO RV）也是一种中间件，具有发布/订阅(Publish/Subscribe)、基于主题寻址(Subject-Based Addressing) 和自定义数据信息(Self-Describing Data Messages)等专利技术功能，使不同应用平台上的信息在一个共享的虚拟总线Information Bus(TIB)上进行传输交换。
先总结一下消息中间件的功能，以上的三类中间件都实现了这些功能。
? 实现消息的异步发送接收，发布订阅，使得两端的应用解耦（减少或解除应用程序
之间的耦合度）。
? 实现消息持久化机制，保证消息可靠性传输。 ? 优化网络传输，支持断点续传。 １、区别之是否分布式
RV 和 MQ 都是分布式结构的， 和 JMS 消息中间件的星型结构不同。分布式消息中间件的Sever在应用环境里都会部署多个，彼此互联，没有主备之分。JMS消息中间件的应用部署一般都是主备两个Server，消息的发送和接收应用平时和主Server相连，有问题时切换到备 Server，主备Server共用公共的存储设备来保存消息。 ２、区别之是否接收端主动
MQ 和 JMS 消息中间件都采用消息接收端主动接收消息的方式。消息从发送端发出后，首先会缓存到Server上，接收端应用发起一个接收消息的请求，Server把消息作为应答返回给接收端。接收端不执行接收动作，消息就会一直在Server上保存。RV 和这两种消息中间件都不同，使用的是发送端主动的消息推送模式。消息从发送端发出后，并不在Server上缓存，Server只做路由把消息推送给消息接收端。消息接收端只要连接上Server，订阅要接收的消息，这些消息就会源源不断地从Server那里推送过来，消息先缓存到接收客户端的队列里，接收端应用再从队列里取消息。RV的最大特点就是把一个数据生产者的数据以最快的速度推送到多个数据消费者那里。RV从金融市场数据系统的需求中产生而来，正是这些特点使得它在证券系统得到最广泛的应用。 ３、区别之是否便于一对多分布
MQ 和 JMS 消息中间件在 IP 层都使用点对点的一对一传输方式，而RV在IP层使用的是广播或者组播的一对多方式。使用广播或者组播可以直接实现一对多的发布订阅形式，发布应用（发送端）发布消息到RV网络上，这些消息会广播到网络的每一个节点上，每一个订阅应用（接收端）都会收到这些消息。而MQ和JMS实现一对多发布订阅就要麻烦的很多，都是在Server按消息的Topic（主题）来缓存消息，为每一个订阅者拷贝每一条消息的引用。当所有订阅者都从 Server 上取走某条消息，这条消息才可在Server上删除。 ４、区别之是否在传输层使用TCP
MQ和JMS 消息中间件不论是Server和Server的通信，还是Server和Client的通信，在传输层都使用 TCP 协议，保证消息传输连接的可靠性。而RV在Server和Server之间的通信使用了UDP协议，牺牲可靠性来达到高实时性的需求。RV有两种可靠性级别，RV Reliable 和 RVCM 。 RV Reliable 模式使用基于UDP增加了一定可靠机制的TRDP协议，在一定范围内具有消息包的检查和重传机制，保证了一定程度的消息可靠性，但不保证消息不丢失。RVCM 在 RV Reliable 基础上更进一步，在消息级别具有消息确认和重传机制，可以保证消息绝对不丢失。对于长度在 1500个字节以下的消息， RV Reliable 发布消息能达到150万笔消息每秒，接收也能达到50万笔消息每秒，传输消息的性能非常好。 ５、区别之是否用Subject做收发端的匹配
RV使用消息的Subject 来做消息发送端和接收端的匹配。RV不在Server端缓存消息，也没有Server端的Queue和Topic。每个消息都有 Subject，Subject格式是多个字符串的串
接，没有数目或者长度的限制。比如在市场数据系统里，行情数据消息的Subject里包含金融品种的名字，这样的 Subject 可以有上百万个。消息订阅端可以细到只接收某个市场的某个品种的行情数据，所以RV能使用细粒度的消息分类。MQ和JMS消息中间件在Server端按Queue 和Topic来缓存消息，消息的发送端和接收端按Queue和Topic的名字来匹配。每个Server能创建的Queue和Topic是有限的，这也就限制了使用 MQ和JMS消息中间件构建的应用，这些应用在做消息收发处理的时候只能使用粗粒度的消息分类。 ６、区别之中间件结构
7、区别之典型应用场景实例
MQ已知的典型应用场景是商业银行向人民银行报送监管信息； JMS已知的典型应用场景是异步发送邮件；
RV已知的典型应用场景是金融市场数据提供商（如路透、彭博、道琼斯）向银行、大型企业提供证券、外汇等金融市场信息。
淘宝开源框架Metaq:
淘宝吸收其它消息中间件(Apache Kafka)而自己开发的一款消息中间件.原名（Metamorphosis）
MetaQ作为一个分布式的消息中间件，需要依赖zookeeper，对于一些规模不大、单机应用的场景，我个人并不是特别支持尝试用MetaQ，因为多一个依赖系统，其实就是多一份风险，在这些简单场景下，可能类似memcacheq、kestrel甚至redis等轻量级MQ就非常合适。而MetaQ一开始就是为大规模分布式系统设计的，如果不当使用，可能没有带来好处，反而多出一堆问题。开发者需要根据自己面对的场景，团队的技术能力，做出一个合适的选择。
MetaQ初探
博客分类：
?
开源
MetaQ（全称Metamorphosis）是一个高性能、高可用、可扩展的分布式消息中间件，,MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，METAQ在阿里巴巴各个子公司被广泛应用，每天转发250亿+条消息。主要应用于异步解耦，Mysql数据复制，收集日志等场景。
总体结构
主要特点
? ? ? ? ? ? ? ? ? ? ?
生产者、服务器和消费者都可分布式 消息存储顺序写 性能极高,吞吐量大 支持消息顺序 支持本地和XA事务
客户端pull，随机读,利用sendfile系统调用，zero-copy ,批量拉数据 支持消费端事务 支持消息广播模式 支持异步发送消息 支持http协议 支持消息重试和recover
? ? ?
数据迁移、扩容对用户透明 消费状态保存在客户端 支持同步和异步复制两种HA
主要特性
数据完整性
消息生产者发送的消息，meta服务器收到后在做必要的校验和检查之后的第一件事就是写入磁盘，写入成功之后返回应答给生产者，生产者发送消息返回SendResult，如果isSuccess返回为true,则表示消息已经确认发送到服务器并被服务器接收存储。整个发送过程是一个同步的过程。保证消息送达服务器并返回结果。因此，可以确认每条发送结果为成功的消息服务器都是写入磁盘的。
写入磁盘，不意味着数据落到磁盘设备上，毕竟我们还隔着一层os，os对写有缓冲。Meta有两个特性来保证数据落到磁盘上:每1000条（可配置），即强制调用一次force来写入磁盘设备。每隔10秒（可配置），强制调用一次force来写入磁盘设备。因此,Meta通过配置可保证在异常情况下（如磁盘掉电）10秒内最多丢失1000条消息。当然通过参数调整你甚至可以在掉电情况下不丢失任何消息。
虽然消息在发送到broker之后立即写入磁盘才返回客户端告诉消息生产者消息发送成功，通过
unflushThreshold和unflushInterval两个参数的控制，可以保证单机消息数据的安全性，只要机器的磁盘没有永久损坏，消息总可以在重启后恢复并正常投递给消费者们。但是，如果遇到了磁盘永久损坏或者数据文件永久损坏的情况，那么该broker上的消息数据将可能永久丢失。为了防止这种情况的发生，一个可行的方案就是将消息数据复制到多台机器，类似mysql的主从复制功能（异步复制和同步功能） 数据可靠性
服务器通常组织为一个集群，一条从生产者过来的消息可能按照路由规则存储到集群中的某台机器。Meta已经实现高可用的HA方案，类似mysql的同步和异步复制，将一台meta服务器的数据完整复制到另一台slave服务器，并且slave服务器还提供消费功能（同步复制不提供消费）。消息的消费者是一条接着一条地消费消息，只有在成功消费一条消息后才会接着消费下一条。如果在消费某条消息失败（如异常），则会尝试重试消费这条消息（默认最大5次），超过最大次数后仍然无法消费，则将消息存储在消费者的本地磁盘，由后台线程继续做重试。而主线程继续往后走，消费后续的消息。因此，只有在MessageListener确认成功消费一条消息后，meta的消费者才会继续消费另一条消息。由此来保证消息的可靠消费。
消费者的另一个可靠性的关键点是offset的存储，也就是拉取数据的偏移量。我们目前提供了以下几种存储方案zookeeper，默认存储在zoopkeeper上，zookeeper通过集群来保证数据的安全性。mysql，可以连接到您使用的mysql数据库，只要建立一张特定的表来存储。完全由数据库来保证数据的可靠性。file，文件存储，将offset信息存储在消费者的本地文件中。Offset会定期保存，并且在每次重新负载均衡前都会强制保存一次
下载、配置、运行
首先需要安装配置Zookeeper，如果不知道怎么配置的，看我的文章，有一章讲解过！