消息可靠性：

基本上这个就要求，消息协议至少需要实现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只是后起之秀。 标签: 云计算,可扩展性,本地磁盘,服务器,topic