从TIBCO开始谈，数据复制的代价

说起TIBCO，估计很少人知道。事实上，虽然我自诩在金融软件行业混了很年，却没有听说过。不过，TIBCO在交易所等地方，却有很广泛的应用。本博客主要从TIBCO开始说起，侧重于从数据拷贝方面论述，在服务端如何提供高性能低延时的服务。

我们假设有个网络服务，为客户端提供实时数据分发服务。那么整个流程就象下面这个样子：

 

    CLIENT----- subscribe---->DISPATCHER----request---->DATA FEED----response---->DISPATCHER----publish---->CLIENT

 

如果DATA FEED是一个数据库，那么实际上DISPATCHER就没有必要存在，这个流程是一个很传统的数据库应用。可是我们考虑一下，在这个流程上，加入2个特性，一个是海量CLIENT，另外一个是实时DATA FEED，那么问题就复杂多了。

 

    假设有一个subject，消息长度100Byte，有1000个终端订阅，那么需要单这个subject就需要服务端出口100 * 1000 = 10W字节，大约100K字节的带宽，这个是很吓人的。因为网络带宽通常只有10M/100Mbps。折算成字节也就1.2M/12M字节。

    TIBCO的作用有2个，一个实现基于subject的过滤，比如你监听A.B.C，那么A.C.D就不会发送给你。这样就减少了网络上传输的带宽。另外一个作用，是在局域网内广播。如果有监听器1、2、3、4，那么每个监听器就可以独立对A.B.C就行过滤。刚才提到1000个终端同时监听，如果是4000个终端同时监听，那么每个监听器负责1000个终端的过滤，当数据源向局域网内进行广播时，每个监听器，同时从网络上抓取自己感兴趣的包，然后进行过滤。对于数据源来说，4个监听器和8个监听器，实际上没有任何区别。数据复制的代价跟监听器的数量没有关联。

 

    我们加入实际应用场景，1、每秒10K个message从Data Feed进行发布；2、有10K个终端订阅这些消息。那么，我们来算下，总共有多少个消息进行传输？很简单，10K*10K＝100M，每个消息以100个字节算，就是10G个字节，还是每秒啊。很恐怖的一个负荷。那么，TIBCO的解决方案就变成这个样子了。

    10K个消息，共1M个字节，通过UDP广播在网络中传输，这个负荷很小的。然后，有10台机器，每台机器都安装一个TIBCO监听器。这时候，网络中，依然只传输1M字节，到达每台机器上的TIBCO监听器的时候，也只有1M个字节。