关于消息中间件的一些困惑

    我现在正参与我们的java平台的消息中间件的开发，由于工作的关系，最近经常在思考消息中间件各种特性的应用价值在哪里。
这其中有个困惑，传统的MQ(把MQ作为消息中间件的简称，比MOM更容易理解）定义了一些MQ的基本特性包括持久、离线、可靠（这里特指有序、不重复不丢失、可恢复）等特性，而这些特性在一些典型的系统中是必需的吗？

一个比较典型的应用是在线交易系统。
    首先离线特性不是必要的。其次，在大规模的集群环境中局部故障也被认为是一种常态，况且MQ不会是交易系统的瓶颈，如果一个交易请求长时间没有响应的话，有时宁愿这个交易请求消息被丢失了，而不是在几个小时之后又被提交给交易服务器。我甚至认为在线交易系统并不需要MQ提供消息持久化及其故障恢复等能力，而只需要MQ的异步、分布、异构、集群（负载均衡能力）特性就足够了。

    实际上相对传统的MQ，还存在着一些其他的MQ产品，比如ZeroMQ(0MQ)，它们不支持消息持久存储、队列深度有限、前端阻塞。而这中MQ的吞吐量是惊人的，单服务器每秒钟可以处理几十万个消息，而传统的基于消息存储的MQ只能是几千的数量级。象0MQ这样的产品非常适用于分布式的消息（事件）驱动系统、在线方式的业务整合，也适合于数据集成应用（后面会讲），甚至我认为何以满足在线交易系统的应用。

    关于前端阻塞，这个是我发明的词，类似BlockingQueue的特性，到达队列深度限制时会阻塞消息发送，可以起到平衡整个网络系统的作用，这个特性对在线交易系统非常有用。IBMMQ是不具备的，队列深度很大，有多少消息照收不误，直到把MQ或交易服务器撑爆，还美其名曰时间无关，真是扯淡。淘宝网把银行交易系统搞宕机就是个典型的反面案例。关于这个特性也有其负面因素，如果在一个XA事务内发送消息，可能由于发送被阻塞而延长事务处理时间。但这种情况是发生在超过队列深度限制的时候，象IBMMQ就直接拒绝发送，更不是个好的解决方法。

另一个比较典型的应用是数据集成系统
    数据集成系统比较理想的方式是文件传输，即数据采集成本地文件，利用消息系统或其他文件传输系统发送文件，最后从文件集成数据。置于为什么不把采集到的数据记录直接以消息的形式传输并集成，这里就不解释了，总之后者被我认为是最差实践。
MQ内核本身并不具备文件传输的功能，同时传统MQ自身的一些消息有序、消息可靠性保障机制（存储、不重、不丢）对文件传输来说不是必需的，因为MQ（即使是IBMMQ)本身无法做到完全的可靠,一个大规模的文件会被拆分成多个消息发送然后合并接收，这种情况下可靠性会更低，同时为了提供这种不太可靠的可靠性，势必也会极大地影响性能（又是传统MQ和0MQ的差异)。那么可靠的传输文件要文件传输模块自己保证，至于怎么做，这里不说。但很简单，比MQ保证可靠传输要简单得多、可靠得多。那么在文件传输的应用上，某些传统MQ的特性又成了鸡肋。

还有一种典型的应用是交易平台或是交易网关
    这种系统和在线交易系统的差别是系统本身不处理交易，而是提供转换、交换、认证、公证的能力。这种系统应用MQ是分别针对每个客户端的，MQ不会贯穿整个交易过程。况且象人行交易网关这样的系统，任何MQ的可靠性保障都无法满足系统地要求，据说最开始的交易数据的传输是用FTP的。这种情况下，传统MQ的某些特性再一次成为鸡肋。

    还有一种比较特殊的交易系统，规模非常大、实时性非常高、非集群集中交易、交易数据高可靠（不重复、不丢失、可恢复)。典型的系统是上海和深圳的证券交易中心的交易系统，不过这种系统是定制化开发的，对于一个通用的MQ产品来讲并不具有代表性的意义。MQ产品也不需要是万能的，能满足和适合多数（甚至是有限几种典型的）应用就可以了。

回到我一开始就说到的，这是我的困惑，我也怀疑我的观点的正确性，所以也希望对消息系统感兴趣的朋友批评指教或是讨论交流。