Tibco与TCP（Rendezvous / RV）

Question

我无法理解Tibco的特殊之处。

他们的营销材料强调TCP是一种悲观的传输协议，不需要客户确认收据。这怎么可能是真的？

对我来说，Tibco基本上是一个由队列支持的TCP协议。

有人可以帮我理解Tibco的主要卖点吗？我即将对我的经理咆哮，告诉他我们已经完全被扯掉了。

Answer 1

我假设您将使用RV（Rendezvous），因为这是他们的主要消息传递协议。

这是一种基于UDP的类似广播的协议，它比TCP更快，但仍然不一定有客户端确认。

它的配置确实支持它（认证消息传递），所以无论是TCP还是UDP，它都取决于你尝试用它做什么。

Tibco（BusinessWorks）增加的价值在于它提供了一个简单，直观的中间件应用程序设计器，使得在负载平衡和容错环境中部署应用程序变得简单。它为您提供各种连接器（soap，http，jdbc，jms等）以连接您需要的东西并将其吐出许多不同的格式。

如果我们有更多关于你将使用它的东西的信息会有所帮助。

PS。而不是RV，请使用EMS（JMS实现。）

RV与EMS：

• RV是UDP，EMS是TCP
• RV是分散的：每个主机上都有一个rv客户端。非常适合有多个收件人的广播消息。除非你使用'远程守护进程'，否则你的消息包含在你的class-c子网中，没有单点故障或瓶颈，
• EMS在特定服务器上集中（中心和辐射），并且可以遍历子网没问题。
• EMS受制于SPOF，但您可以成对集群服务器以消除此问题。
• 对于1-1或1-2，EMS更好，但对于1-many
，RV更好

Answer 2

增值应该是“可靠多播”和平台独立性。 整个架构与rvd在一切的中间是有点愚蠢，所以在我看来你被扯掉，就像我们在这里，以及其他人支付他们:)）

Answer 3

很好的问题 - 但你有没有试过通过TCP套接字连接500个消费者？

如果您的消息率也很高（> 10k msgs / sec），您最终将使用UDP（一条消息发送给所有消费者，而不是副本！）。 但是你没有TCP的可靠性，这是PGM或TRDP的用武之地。 有了这样的要求，我发现TIBCO RV非常有用/我所知道的最好。 C API非常快（如果你的速度超过10k msgs / sec，请忘记Java。）

当然，您可以推出自己的可靠多播，但RV API使用起来非常简单并且可以移植到许多不同的平台上。我想简单的使用是反对TCP的主要论据。教一个初级程序员如何编写一个稳定且有效的RV pub / sub应用程序需要一天的时间，用TCP做一个月也需要一个月。

rvd本身只是坐在那里看不见，所以你为什么要担心呢？

如果扇出不是问题（1-1或甚至1-5场景），请查看TIBCO EMS（或其他JMS提供商）或者AMQP。

TCP的另一个真正优势是主题（或JMS主题）。 如果要集成20个不同的应用程序，这会有很大帮助。

Answer 4

这取决于你是谁以及你的目标是什么。我对TIBCO的熟悉之处在于，它是我们金融服务行业的许多竞争对手使用的消息传递系统，可以将来自基于Web的前端的消息安全地发送回大型机进行处理，并向我们的前端提供股票报价等内容。

我们拥有自己的消息产品，与我们公司以前工作过的高层产品之一的消息产品有着奇怪的相似之处：）

我们有3亿技术预算，但请记住，我们还有2个大型数据中心和几个生产中心，以及3个开发办公室。

现在，在我们的情况下，一家公司可能会发现开箱即用TIBCO之类的东西很不错（我们可能已经节省了大量的3亿美元）。

如果你没有那种预算而且你的要求要少得多，那么对你来说它可能确实是一个“扯掉”。但是，为了自己开发这种系统，对于像我工作过的那样的组织......我相信它会占据3亿的大部分。