MetaQ（全称Metamorphosis）是一个高性能、高可用、可扩展的分布式消息中间件，思路起源于LinkedIn的Kafka，但并不是Kafka的一个Copy。MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，目前在淘宝和支付宝有着广泛的应用。   Github地址：  链接地址
为了使大家对MetaQ有进一步的了解，本期我们采访了MetaQ的核心开发者庄晓丹。 
欢迎大家推荐更多开源项目给我们，支持中国的开源项目发展，如果您和您的团队希望展示创业理念和有趣之处，或者有朋友正在创造这样的价值，请联系我们，发信到blog@csdn.com即可。

先来个自我介绍吧！ 

我叫庄晓丹，工作5年左右，工作经历比较杂，在创业公司呆过，在大公司呆过。目前在AVOS的中国分公司工作，我们的主要产品是美味书签（delicious.com和中文版的meiweisq.com）、美味爱读（readwise.net）等。我的主要工作语言是Clojure/Java，编程既是我的工作，也是兴趣爱好。

 

MetaQ是什么？能做什么？ 

MetaQ（全称为Metamorphosis）是一个淘宝开源的分布式的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。这个产品是我在淘宝中间件团队发起并作为核心开发者的一个项目。第一个版本的完整代码包括完整的单元测试是我在两周内（印象中是，可能更短）写出来的。 
MetaQ既然是一个消息中间件，那么消息中间件能做的事情，MetaQ都是可以做到的。消息中间件作为分布式系统可扩展、可伸缩性的关键一环，MetaQ可以起到很好的作用。 

MetaQ项目的由来？ 

MetaQ的起源是我从对Linkedin的开源MQ（现在转移到  Apache kafka的学习开始的，这是一个设计很独特的MQ系统，它采用pull机制，而不是一般MQ的push模型，它大量利用了zookeeper做服务发现和offset存储，它的设计理念我非常欣赏并赞同，强烈建议有兴趣的同学阅读一下它的  设计文档，总体上说MetaQ的设计跟它是完全一致的。 

可不可以说MetaQ是Apache Kafka的Java实现 & 功能增强版本？

可以这样说，因为总体的设计是一致的，但是我们做了很多优化和改进。 
可以简单概括下我们重新写metaq的原因：

•     Kafka是scala写的，我对scala不熟悉，并且在当时kafka整个社区的发展太缓慢了。
•     有一些功能是kakfa没有实现，但是我们却需要，比如事务、多种offset存储、高可用方案(HA)等

Meta相对于kafka特有的一些功能：

•     文本协议设计，非常透明，支持类似memcached stats的协议来监控broker
•     纯Java实现，从通讯到存储，从client到server都是重新实现。
•     提供事务支持，包括本地事务和XA分布式事务
•     支持HA复制，包括异步复制和同步复制，保证消息的可靠性
•     支持异步发送消息
•     消费消息失败，支持本地恢复
•     多种offset存储支持，数据库、磁盘、zookeeper，可自定义实现
•     支持group commit，提升数据可靠性和吞吐量。（目前kafka已实现）
•     支持消息广播模式
•     一系列配套项目：Python/Ruby/C/C++客户端、Twitter Storm的Spout、Tail4j等。 

与其他消息系统（如ActiveMQ、HornetQ）相比，MetaQ有哪些优势或特点？ 

ActiveMQ和HornetQ都是符合Java EE中JMS规范的MQ实现，两者都是很优秀的开源MQ。同时两者也不局限在JMS规范，同时也支持其他一些MQ协议，如stomp协议、AMQP协议等。相比来说，就我当时了解的情况来看，HornetQ的性能会比ActiveMQ更强，因为HornetQ使用JNI基于异步IO做了更多优化，而对于MQ来说，最终的瓶颈都是落在IO存储上。MetaQ的性能是远远超过这两个MQ的，有一个网友做的比较可以说明一定问题（链接地址），但是这不能说MetaQ比它们就更优秀，因为这跟它们的实现，和面对的场景有很大关系。

ActiveMQ和HornetQ，这两个MQ从诞生起就是为了企业应用而设计的，JMS规范本身也是企业应用系统的规范。这一套东西，我个人认为并不适合互联网应用。互联网应用通常面对的是海量的数据，并且通常对事务一致性的要求相对较弱，而企业应用对事务一致性的要求就相对很高。互联网应用为了处理大量请求，通常采用集群处理的方式，而JMS规范并不重视分布式应用。我说的这个集群不仅仅是服务端broker的集群，还包括生产者和消费者都可能是一个又一个集群，而传统的JMS规范是没有明确处理这些情况的。互联网应用还有一个问题是异构系统特别多，而JMS规范只是Java EE这个平台上的规范，对异构系统的接入也是一个比较麻烦的地方，不同的实现有很大的差异。 
综合来讲，  HornetQ和ActiveMQ是为了企业级应用设计的消息中间件，而MetaQ从一开始就是为了大规模互联网应用设计的消息中间件，两者面对的场景和需求不同。开发者可根据实际的需求，选择合适的产品。 
从MQ的发展来看，我们可以看到，出现了越来越多特定领域的消息中间件，例如memcacheq、kestrel、beanstalkd甚至redis，它们很轻量级，并且不想做到全能，而只是解决一个领域的问题，我觉得这是未来的趋势。 

MetaQ的内部是如何实现的？

从实现角度看，MetaQ充分利用zookeeper这个优秀的服务中心，作为服务注册和查找中心、客户端负载均衡和数据偏移量的分布式存储使用。Zookeeper在MetaQ整个集群中扮演非常关键的角色。 
MetaQ的存储实现与kafka是一致的，充分利用传统磁盘顺序读写非常高效的特点，并且利用group commit、sendfile系统调用等技术来充分提高IO效率。 
MetaQ的事务实现跟ActiveMQ是类似的，采用redo日志的方式，并遵循JTA协议规范来实现分布式事务。 
MetaQ的网络协议跟memcached文本协议类似，因为我本人非常熟悉memcached（开源的xmemcached客户端是我开发的），但是MetaQ的协议引入了opaque的映射字段，提高请求的并行度。正因为采用文本协议，为MetaQ编写其他语言客户端是相对容易，并且管理MetaQ服务器也变的很容易，比如MetaQ提供了stats协议，通过telent就可以获取服务器的运行状况。 
关于更多的实现细节可以看Wiki上的文档： 

•    链接地址
•     https://github.com/killme2008/Metamorphosis/wiki/协议 

MetaQ适合的场景？

•     日志传输，高吞吐量的日志传输，这本来也是kafka的强项。
•     消息广播功能，如广播缓存配置失效。
•     数据的顺序同步功能，如MySQL binlog复制。
•     分布式环境下（broker、producer、consumer都为集群）的消息路由，对顺序和可靠性有极高要求的场景。
•     作为一般MQ来使用的其他功能。 

MetaQ的性能如何？ 

关于性能，可以看wiki上的性能测试页面  链接地址
总体来说,MetaQ的性能还是很优秀，但是很大程度上取决于使用的存储磁盘的性能。 

MetaQ目前的应用情况？

MetaQ在淘宝每日有十亿级别的消息流转，在支付宝有百亿级别的消息流转（作为storm的spout源），在阿里B2B也有部分应用。 
在我目前的AVOS.com我们也在使用它作为后端系统的消息中间件。就我所知还有部分公司在尝试使用，例如腾讯、京东等。 

目前MetaQ的主要维护者？有其他开发者参与贡献吗？

MetaQ还有一位主要开发者是我在淘宝的前同事  无花/花名），以及一位非常热心的网友  netcomm，贡献了不少的文档。 

使用MetaQ应注意哪些事项？

MetaQ作为一个分布式的消息中间件，需要依赖zookeeper，对于一些规模不大、单机应用的场景，我个人并不是特别支持尝试用MetaQ，因为多一个依赖系统，其实就是多一份风险，在这些简单场景下，可能类似memcacheq、kestrel甚至redis等轻量级MQ就非常合适。而MetaQ一开始就是为大规模分布式系统设计的，如果不当使用，可能没有带来好处，反而多出一堆问题。开发者需要根据自己面对的场景，团队的技术能力，做出一个合适的选择。 

MetaQ采用的开源协议？该项目的后续开发计划？

MetaQ采用宽松的、对商业友好的Apache 2.0开源协议。 
新版本1.4.4一直在开发过程中，但是因为我个人工作重心的转移，整体进展不是特别理想。1.4.4主要想解决易用性和消费者负载均衡的问题。 
特别希望有兴趣的朋友参与这个项目的发展，共同学习和促进。 

[转]分布式消息中间件 MetaQ 作者庄晓丹专访