标签：
TIBCO Rendezvous（或称为TIBCO RV）产品是一种中间件，它具有发布/订阅(Publish/Subscribe)、基于主题寻址(Subject-Based Addressing) 和自定义数据信息(Self-Describing Data Messages)等专利技术功能，使不同应用平台上的信息在一个共享的虚拟总线Information Bus(TIB)上进行传输交换。这些技术能有效地帮助企业从传统的请求/应答(Request/Reply)模式转到自动数据接受的事件驱动模式(Event-Driven，或称之为Push)。TIBCO RV 有助于在各种应用系统中获取信息和数据，能将异构平台有机地联结起来, 通过以即插即用(Plug &Play) 、位置无关（Location-Independent）和分布式服务（Distributed Services）的方式在WAN 和LAN 间配置系统。并且TIBCO RV 具有认证消息传递(Certified Message Delivery) 、容错(Fault Tolerance) 和分布式队列（Distributed Queue）功能。因为使用TIBCO RV 不用考虑网络的技术细节，而只需专注于企业应用的开发，所以能快速建立和配置一个可伸缩的分布式应用系统。
TIBCO Rendezvous 的优点：
l 加快应用的开发，减少维护费用；
l 唯一独立于硬件、操作系统、网络和协议平台供应商；
l 动态组件替换:进程可以随时加载、退出、替换，而不影响系统运行；
l 屏蔽网络细节；
l 应用伸缩性高；
l 地址无关，简化增加/改变组件；
l 提高分布系统的生命期；
n 一般特性：
· 分布式队列实现一对多信息传送；
· 安全信息传送；
· 冗余机制实现容错；
· 所有平台间对等传输；
· 与其他通讯协议并存于统一系统；
· 支持多种数据内部交换格式；
· 系统开销低，容易嵌入；
· 线程安全，多线程安全保护；
· 支持多点传送；
n 通讯和数据特性：
· 异步通讯；
· 发布/订阅，可靠的广播(broadcast)/多播(multicast)机制；
· 点对点请求/应答；
· 基于主题消息传送；
· 自定义数据信息与硬件/操作系统无关；
· 透明的信息打包或重组；
n 认证信息传递：
· 明确的信息认证，确保信息传送到目的地；
· 在进程中断和重新启动状态下确保要传递的信息不丢失；
· 分布式队列，自动实现负载均衡功能；
· 传递信息给队列种的某一成员；
· 队列成员进程保持异步运行；
n 容错：
· 通过冗余进程实现系统容错；
· 监控活动的冗余进程；
n 开发特点：
· 提供Java、C、C++、ActiveX、.NET、Perl 的API 库；
· 源码兼容所有的平台；
· 支持同步/异步事件管理结构；
TIBCO Rendezvous Daemon（rvd）为应用进程传递信息，过滤主题信息，分配信息；
TIBCO Rendezvous Routing Daemon（rvrd） 在WAN 和LAN 间跨网段有效地传递信息,对TIBCO Rendezvous 应用编码不做任何修改；
TIBCO RV 在当前的操作环境中加入两个组件：
ü API 库。每个应用程序连接到RV API 库的某一版本；
ü RV 通讯Daemon 进程。在大多数环境，每台主机上面运行一个Daemon 进程。
下图演示了一个简单环境中两个系统进行交互的过程。主机1 上运行应用
程序A 和一个daemon 进程，主机2 上运行两个应用程序B 和C，它们通过单个daemon 进程连接到网络上。所有这三个应用程序可以进行相互通讯。
任何主机上可以运行任意数量的RV 应用程序。通常一个主机上的所有RV应用程序共享同一个RV Daemon 进程。
Rendezvous Daemon 进程
应用程序依赖RV Daemon 后台进程进行可靠和高效的网络通讯。（通常RVDaemon 进程和RV 应用程序运行在同一主机上；但是RV 应用程序也可以连接到远程daemon。）
RV 应用程序试图连接到RV daemon 进程。如果daemon 没有运行，应用程序将自动启动它并连接到daemon 进程。RV daemon 负责通讯的所有细节：如数据的传输，包的排序，接收确认包，重发请求，将信息派发到适当的应用程序进程等。它为RV 应用程序隐藏了所有这些细节。
TIBCO RV 只是一个消息中间件产品，XML 数据可以通过RV 消息进行传递，但它不提供对XML 数据的处理能力。
可以通过几种方式来实现XML 数据的处理：
使用TIBCO BusinessWorks 产品对包含XML 数据的RV 消息进行各种处理，如映射、变换、合并、分解等；
使用第三方XML 工具或API，以编程方式对RV 消息中的XML 数据进行处理。
TIBCO RV 本身只提供一些后台Daemon 程序以及API 接口供用户使用。用户使用这些API，选择RV 支持的开发语言（如C/C++，Java 等）开发相应的RV 应用程序，并通过后台Daemon 进程进行消息的发送或接收。
用户也可以选择TIBCO 基于RV 开发的一些其他产品（如BusinessWorks，各种Adapter 等）来简化应用程序的开发。
概述
TIBCO Adapter for ActiveDatabase可以把某个数据库中数据的变化可以发送给其他的数据库或应用。它把发布/订阅与请求/回复机制扩充到数据库层面，使数据库应用可以使用多种不同层次的消息传递服务。它支持所有的ODBC兼容数据库，包括DB2, Oracle, Sybase, Informix, Microsoft SQL Server, TimesTen in-memory database等。
特色
事先定义的数据库表中的行发生插入、修改或删除操作时，可以把数据按照TIBCO Rendezvous消息格式发布
l 创建数据的拷贝，按照数据值来发布数据
l 直接引用新的数据来发布信息。
l 可以使用参数定义发布消息的主题，即可以根据发布数据的内容动态床架主题。
l 可以使用可靠传输和保证传输两种方式进行数据的发布。
l 保证传输的接收者可以事先在保证传输信息的发布者上注册。
事先定义的数据库表中的行发生插入、修改或删除操作时，可以订阅按照TIBCO Rendezvous消息格式发布的数据变化
l 可以使用含有通配符的主题名称订阅消息
l 可以使用可靠传输和保证传输两种方式进行数据的订阅。
l 可以根据消息数量或超时时间进行批处理提交。
l 可以使用基于TIBCO Rendezvous 客户端应用定义特定的主题使用RV消息格式向数据库发送SQL语句或存储过程。
使用内建的函数来配置发布代理和订阅代理，修改信息内容。
配置TIBCO Adapter for ActiveDatabase 来满足需求：
定义数据库表间关系，发布所有的相关表内容。
使用定期检查或通知机制监测数据库的改变。
基于的标准:
l 通过ODBC连接多种数据库
l 与其他TIBCO ActiveEnterprise组件实现互操作。
l 使用TIBCO Hawk进行系统监控。
支持的系统平台
ü Windows
ü HP-UX
ü Solaris
ü AIX
ü Linux
支持的数据库系统
ü Oracle
ü Sybase
ü MSSQL
ü DB2 for OS/390
ü DB2 for AS/400
ü DB2 UDB for Windows and Unix
对于消息中间件，绝大多数熟悉的是 IBM MQ, 这是目前使用最广泛的中间件产品。国内还有一款中间件 TongLinkQ, 结构和 MQ 相似。其实在国外还有一款叫 Rendzvous 的消息中间件应用也非常广泛，只是在国内应用不多，所以在国内并没有 MQ 那么大的名气。这款消息中间件的设计和 MQ 是完全不同的，有很多不同的特性特点，使得它在某些应用场景具备更多的优势。 总结一下 Rendzvous 的架构特点，和 MQ 的架构以及 JMS 消息中间件的架构做比较。深入了解和比较这些中间件产品，才能用的准用的好它们。
先总结一下消息中间件的功能，以上的三类中间件都实现了这些功能。
Ø 实现消息的异步发送接收，发布订阅，使得两端的应用解耦。
Ø 实现消息持久化机制，保证消息可靠性传输。
Ø 优化网络传输，支持断点续传。
1. 分布式结构 VS 星型结构 ，推送 VS 接收， 服务端缓存 VS 客户端缓存 。
RV 和 MQ 都是分布式结构的， 和 JMS 消息中间件的星型结构不同。分布式消息中间件的 Server 在应用环境里都会部署多个，彼此互联，没有主备之分。 JMS 消息中间件的应用部署一般都是主备两个 Server ，消息的发送和接收应用平时和主 Server 相连，有问题时切换到备 Server ，主备 Server 共用公共的存储设备来保存消息。
MQ 和 JMS 消息中间件都采用消息接收端主动接收消息的方式。消息从发送端发出后，首先会缓存到 Server 上， 接收端应用发起一个接收消息的请求， Server 把消息作为应答返回给接收端。接收端不执行接收动作，消息就会一直在 Server 上保存。
RV 和这两种消息中间件都不同，使用的是消息推送的模式。消息从发送端发出后，并不在 Server 上缓存， Server 只做路由把消息推送给消息接收端。消息接收端只要连接上 Server ，订阅要接收的消息，这些消息就会源源不断地从 Server 那里推送过来，消息先缓存到接收客户端的队列里，接收端应用再从队列里取消息。
总之 RV 是一个分布式结构，推送消息模式，客户端缓存的消息中间件。分布式结构适用于分布是应用系统，方便做扩展，推送加客户端缓存适用于高实时性消息的处理，消息需要在第一时间到达目的地，过时的消息的没有必要保存下来的，消息接收端应用需要做的事情就是不断地处理已经推送到的消息。
2. 使用广播和组播来实现一对多的发布订阅 。
MQ 和 JMS 消息中间件在 IP 层都使用点对点的传输方式，而 RV 在 IP 层使用的是广播或者组播的方式。 使用广播或者组播可以直接实现一对多的发布订阅形式，发布应用发布消息到 RV 网络上，这些消息会广播到网络的每一个节点上，每一个订阅应用都会收到这些消息。而 MQ 和 JMS 实现发布订阅就要麻烦的多了， 都是在 Server 按消息的 Topic 来缓存消息，为每一个订阅者拷贝每一条消息的引用。当所有订阅者都从 Server 上取走某条消息，这条消息才在 Server 上删除。
3. UDP VS 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 万笔消息每秒。传输消息的性能是非常好的。
4. 使用消息 Subject 做收发两端的匹配 。
MQ 和 JMS 消息中间件在 Server 端按 Queue 和 Topic 来缓存消息，消息的发送端和接收端按 Queue 和 Topic 的名字来匹配。每个 Server能创建的 Queue 和 Topic 是有限的，这也就限制了使用 MQ 和 JMS 消息中间件构建的应用，这些应用在做消息收发处理的时候只能使用粗粒度的消息分类。
RV 不在 Server 端缓存消息，也没有 Server 端的 Queue 和 Topic 。它是使用消息的 Subject 来做消息发送端和接收端的匹配的。每个消息都有 Subject ， Subject 格式是多个字符串的串接，没有数目或者长度的限制。比如在市场数据系统里，行情数据消息的 Subject 里包含金融品种的名字，这样的 Subject 可以有上百万个。消息订阅端可以细到只接收某个市场的某个品种的行情数据。
RV 使用优化的算法实现 Subject 的筛选。如果 RV 网络上有一万种消息，一个 RV Server 被一千个消息接收端连接，每个接收端订阅不同的 Subject 。那 RV Server 的工作就类似一个超级的邮件分检员，对每一个从 RV 网络上广播而来的消息做 Subject 的判断，判断是否在这一千个订阅的 Subject 的范围内，是则将消息推送到订阅此消息的接收端，否则将消息抛弃。当数据量很大时，这种筛选工作是需要很高效率的。
总之， RV 的最大特点是推送模式，把一个数据生产者的数据以最快的速度推送到多个数据消费者那里。 RV 从金融市场数据系统的需求中产生而来，正是这些特点使得它在证券系统得到最广泛的应用。
标签：
原文地址：http://www.cnblogs.com/hedongnan/p/4534584.html
