如何设计一个靠谱的消息中间件
在前面的三篇文章中，我们从微观到宏观，再从宏观到微观的了解了一遍Nsq：
现在让我们利用现有知识，试着总结一下，如何设计一个靠谱的消息中间件。
首先，你是一个中间件，必须有中间件的样子，一条队列，肯定不能作为中间件，因为你不满足：
- 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，那么对应的就会选择内存，当然为了消息可靠性，你还是得做一些刷盘的操作
- …
在只学习了Nsq的前提下，我们对消息队列的理解大概也就如此了。
接下来，我们来看看另一个消息中间件，Kafka，是如何实现一个MQ的。
在对比中，快速入门另一种开源MQ。
在对比中，开拓眼界，加深对MQ的理解。
