消息系统的设计要点

存系统，基本上解决一个存取问题，就万事大吉了，调用是同步的。对于消息队列来说，就不太一样。它的使用场景多样，可靠级别多变，从生产端到消费端，过程是异步的。

消息系统的设计要点，有很多。现在，很难有一个消息系统，能够兼顾下面提到的设计要点。它要是说可以，那就是母体在吹。

所以很多时候，现在流行的Kafka、RabbitMQ、RocketMQ等，会被同时使用。如果你在做相关方面的选型，下面这些技术点就是权衡之处。那句话叫什么来着：牝鸡司晨，惟家之索。

要点

本文将针对这些mq，从整体上抽象一些共有特性。包括：协议、类型、消费方式、堆积能力、高可用、高可靠、高性能、扩展性和生态。如果你想要深入某个mq，这里也有几篇关于kafka的文章。

可用主要解决集群单节点，在异常情况下的failover和HA。解决高可用问题的一般思路就是副本机制。

通过增加副本，可以将数据的风险分散到多台机器上。这就需要在主分片出现问题时，能够从副本中找出一个作为新的主分片。有很多这样的协调工具，比如zk。也有的mq，自己去实现这个过程。

有的模式就比较浪费资源了，比如rocketmq，使用standby从机进行高可用保证，出问题再顶上来。


 

息系统的可靠性和性能是相悖的。一般的mq，可靠性级别都是可以调节的，但性能会发生相反的联动性。从消息级别来说，大体路线有：

发出去就不管了->单节点确认->多节点确认->多节点确认同步刷盘->所有节点同步刷盘->事务消息等。

单机高可靠

集群的高可靠方面，会有ack机制和多副本机制进行保证。对于单个节点来说，断电或者主机异常，会是一个比较大的挑战。为了处理这种情况，需要有刷盘机制或者其他持久化机制。同时，数据的完整性校验也是需要的，这也是类似kafka这种消息系统，数据量大的时候，启动时间非常长的原因。

生产端

生产端除了要考虑buffer丢失的问题，还要考虑到一些发送错误的情况，包括与集群通信的超时和重试处理。

消费端

消费端通过消息确认机制来保证消息已经被正确消费。由于其间会发生很多异常情况，所以大多数消息系统保证at least once语义。即确保消息至少被消费1次。

言外之意，消息是会重复的，消费者需要做到幂等，保证重复消费不会引起业务异常。

消费端同样会发生一些错误情况，有些mq可以在多次消费失败后自动进入死信队列，有些mq需要自行设计topic进行规划。

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!