MQ(4) —— 如何设计一个靠谱的消息中间件

Posted by ZY on October 2, 2018

如何设计一个靠谱的消息中间件

在前面的三篇文章中,我们从微观到宏观,再从宏观到微观的了解了一遍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的理解。

参考