前言

这次主要是讲一下云计算环境中的消息队列服务。选择这个话题，主要是上周刚好对消息队列做了一番简单的应用。虽然没有写过消息队列，但是接触多了也算是对消息队列有了自己的理解和看法。这篇文章主要是讲述云计算环境中消息队列的设计思路（再说一下我不是程序员，如果要写这个，估计会是在开源的几个mq里面做二次封装）。

正文

亚马逊的EC2算是给所有云计算的服务商树立了一座很难翻越的高峰。现在很多国内的“云计算”服务充其量也就是个VPS的服务。当然我不是说他们没有做工作，而是说做的不到位（当然也可能是国内的客户需求还处于“社会主义初级阶段”）。在云计算环境中，很多基础设施都是可以重用的，其中最重要的一个环节就是消息队列。在云计算环境中，很多服务为了做到水平扩容，数据交流一定会过消息队列。是否有可靠的消息队列服务是衡量云计算服务提供商水平的一个标志。

云环境里面，很多基础服务最明显的特征是可伸缩性。任意一个服务基本可以做到自动的，平滑的扩容。

设计思路

个人一直认为单节点的性能优势相对于可扩展性来说，是处于第二位的。一个程序如果可以很容易的通过增加节点来提升性能，那么比单机性能强悍的程序更加具有优势。因为硬件会发展，程序性能可以慢慢优化，而需求是眼前需要立马解决的。

说到设计，第一反应是利用现有的开源的几个消息队列做二次封装。现有接触过的开源主流的MQ主要是ZMQ和Rabbitmq。两者的专注的方向有点不太一样，但是都非常优秀，各自都有一批的簇拥。相对来说ZMQ更加关注于底层的数据吞吐，而rabbitmq更加注重消息的分发方式和可靠性。如果从开发量上来说rabbitmq可能更加适合。

事实上如果需求简单一些，直接参考aws的sns服务的话，发现 NSQ 很能对号入座。因为基本上需要的各个特点NSQ都符合（具体情况可以看项目主页）。在以下的比较中我基本上以rabbitmq和nsq作为原型。

设计目标

1. 消息分发可靠
2. 自动扩展

消息可靠性

基本上这个就要求，消息协议至少需要实现Ack/requeue的功能。基本上rabbitmq和nsq在这方面都没有问题。

NSQ和rabbitmq都可以写本地磁盘保证的消息不会因为突然的宕机而丢失。如果底层没有可靠的EBS服务的话，就需要额外的开发工作（题外话：云计算的服务都是环环相扣的，底层做的好，会带来很大的好处）。简单一点是双机备份，一条消息发2个节点，互为主从。粗略看上去会稍微耗资源一些，但是毕竟算是没有办法的做法。当然更加省事一点是所有的topic上都一个归档程序消费保存消息，只要topic上的消息不堆积，基本上即使有节点挂掉，也可以相对方便的通过归档数据重放。aws的sns貌似就是默认保存所有的消息。

可扩展性

NSQ天生具有很好的扩展性。rabbitmq稍微差一些，但是如果自己高一个类似nsqlookupd的程序来维护rabbitmq上的数据，还是可以做的。NSQ在这方面优势明显，基本都是现成的。rabbitmq需要额外开发服务器端的程序或者对amqp协议做自己的封装。基本上NSQ只要维护好几个公共的nsqlookup节点，剩下的只要将nsqd做成一个镜像。处理节点本身可以被云计算的autoscaling服务维护。

额外说明

rabbitmq是用erlang写的，运行需要erlang环境会更加占内存一些。部署上rabbitmq和nsq基本都一样。消息处理效率上两者相差也不会太大。监控上两者都有独立的API接口可以导出队列信息。

总结

可能有人认为zmq或者其他的开源mq更加合适，但是目前我只用对rabbitmq和nsq做过编程。在一个云计算的平台中大部分人使用mq的时候并没有使用到高端的特性，很多时候基本的pubsub就能满足需求。虽然rabbitmq在协议特性上更加强大，但是nsq在部署方便性和开发难度上有明显的优势。如果从项目本身的成熟度来说，rabbitmq算是久经考验了，nsq只是后起之秀。