消息中间件要解决什么问题？
消息中间件要解决的问题是：
- 解耦：需要互相通信的应用之间的解耦
- 缓冲：如果一个应用正忙，但其他应用还在不停的给他发消息，这时候需要一个地方暂存无法被处理的请求。
消息中间件的通用属性？
- no SPOF: SPOF = Single Point of Failure，你就一个单点，就一台服务器，挂了整个系统的消息都跑不通了，你必须要有替补、要有搭档。这一点，解决思路就是采用集群，nsq和nsqlookup，都支持集群架构
- 可拓展性强：当一台服务器不够用时，你是否支持方便的横向扩展？nsq的扩展非常简单，默认一个生产者配置一个nsq，如果你需要俩，那就配置两个nsq地址即可
- 可靠性强：这一点，nsq并不具备，默认情况下，消息是保存到内存的，一旦系统崩溃了，消息就没了。就算消息持久化到磁盘了，也只是做了一次备份，不像Kafka的partition机制，可以做多次备份
- 性能好：这点毋庸置疑，采用push+内存的实现策略，再加上面提到的高可拓展性，nsq的性能可以得到保障
消息中间件的特殊属性？
- 消息投递策略：消息投递是至少一次，还是最多一次，还是需要控制在准确一次？nsq选择的是至少一次，这种适用面最广的方式，Kafka则支持全部三种，当然，这也给系统引入了更多的复杂性，而nsq则选择一如既往的”极简“
- 消息时序性：为了性能考虑，nsq选择了不去无序，让消息飞~ 当然，如果你能设计出一套可以在topic级别进行时序性控制的消息中间件，是最牛逼不过了，比如有赞自研的nsq
- push or pull：为了追求实时性，nsq选择了push，不同的消息中间件有不同的实现策略
- 内存 or 磁盘：通常，如果你选择了push，那么对应的就会选择内存，当然为了消息可靠性，你还是得做一些刷盘的操作