标签：style blog http io ar color os 使用 sp
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（全称为Metamorphosis）是一个淘宝开源的分布式的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。这个产品是我在淘宝中间件团队发起并作为核心开发者的一个项目。第一个版本的完整代码包括完整的单元测试是我在两周内（印象中是，可能更短）写出来的。
MetaQ既然是一个消息中间件，那么消息中间件能做的事情，MetaQ都是可以做到的。消息中间件作为分布式系统可扩展、可伸缩性的关键一环，MetaQ可以起到很好的作用。
MetaQ的起源是我从对Linkedin的开源MQ（现在转移到 Apache kafka的学习开始的，这是一个设计很独特的MQ系统，它采用pull机制，而不是一般MQ的push模型，它大量利用了zookeeper做服务发现和offset存储，它的设计理念我非常欣赏并赞同，强烈建议有兴趣的同学阅读一下它的 设计文档，总体上说MetaQ的设计跟它是完全一致的。
可以这样说，因为总体的设计是一致的，但是我们做了很多优化和改进。
可以简单概括下我们重新写metaq的原因：
Meta相对于kafka特有的一些功能：
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充分利用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上的文档：
关于性能，可以看wiki上的性能测试页面 链接地址
总体来说,MetaQ的性能还是很优秀，但是很大程度上取决于使用的存储磁盘的性能。
MetaQ在淘宝每日有十亿级别的消息流转，在支付宝有百亿级别的消息流转（作为storm的spout源），在阿里B2B也有部分应用。
在我目前的AVOS.com我们也在使用它作为后端系统的消息中间件。就我所知还有部分公司在尝试使用，例如腾讯、京东等。
MetaQ还有一位主要开发者是我在淘宝的前同事 无花/花名），以及一位非常热心的网友 netcomm，贡献了不少的文档。
MetaQ作为一个分布式的消息中间件，需要依赖zookeeper，对于一些规模不大、单机应用的场景，我个人并不是特别支持尝试用MetaQ，因为多一个依赖系统，其实就是多一份风险，在这些简单场景下，可能类似memcacheq、kestrel甚至redis等轻量级MQ就非常合适。而MetaQ一开始就是为大规模分布式系统设计的，如果不当使用，可能没有带来好处，反而多出一堆问题。开发者需要根据自己面对的场景，团队的技术能力，做出一个合适的选择。
MetaQ采用宽松的、对商业友好的Apache 2.0开源协议。
新版本1.4.4一直在开发过程中，但是因为我个人工作重心的转移，整体进展不是特别理想。1.4.4主要想解决易用性和消费者负载均衡的问题。
特别希望有兴趣的朋友参与这个项目的发展，共同学习和促进。
标签：style blog http io ar color os 使用 sp
原文地址：http://www.cnblogs.com/springwind268/p/4156291.html
