正文
沈询：
要讲明白这个问题，就需要从产品的实际需求角度入手开始做个介绍了。Notify作为一个已经存在了5年多的消息产品，被广泛的应用在整个阿里巴巴集团的大部分消息通信领域。它的核心特性是： 提供事务支持、不保证消息顺序、消息可能会重复、推模型。
因为淘宝是个交易类网站，所以事务支持的特性能够非常方便的让用户可以快速的依托于Notify完成他们自己的业务逻辑。
然而，一个产品不可能满足所有的场景，在当时我们就经常收到一些需要保证消息有序的发送和接收的需求，而这样的场景对于上来就定位于无序消息投递的 Notify 来说无异于釜底抽薪。
而正在我们讨论这类需求应该如何被满足的时候，正好赶上 LinkedIn 的 KafKa 队列开源，简单的文件队列，拉模型，保证顺序的特性一下就吸引了我们的目光，在对他的做了整体架构上的Review以后，我们认为这是个非常优雅的模型，因为他足够简单，简单就是最好的~！
然而里面也有一些特性不是我们所需要的，比如我们主要是面向内部用户，因此定期轮询去拉的方式就不适合我们的实际场景需求，并且因为 KafKa 的开发语言是 Scala ，不大利于我们的后续的维护，因此我们借鉴了 Kafka 的核心思路，对其进行了重写并开源，当然我们还是向 LinkedIn 的 KafKa 做了致敬的，MetaQ 其实是 Metamorphosis 的意思，是Kafka的名作。
从上面的发展历程其实也就能够比较清晰的找到两个消息队列产品的不同定位了：
目前 ，我们也将这套消息系统放在了云上，https://www.aliyun.com/product/ons/ 额外增加了更高的安全性保证，大家也可以看看。
InfoQ
：您个人在分布式方面有比较多的经验，而消息系统中一个重要的考虑因素就是分布式的扩展能力，尤其是对于阿里、淘宝的业务，能不能介绍下目前中间件团队在分布式是如何做的？跨域、跨机房方面？
沈询：
其实所谓分布式运算，核心的思路就是系统架构无单点， 让整个系统可扩展。
如果要介绍分布式场景的实际经验，那么我就需要先引入一个概念：“有状态存储节点和无状态运算节点”。
无状态运算节点主要是部署 Web 应用、 HSF 服务，消息队列等的机器有状态的存储节点主要是指部署数据库、缓存、配置服务器、 NoSQL 等的机器。
