消息队列作为一种基础的抽象数据结构,被广泛应用在各类编程与系统设计中。 同步VS异步 通信的一个基本问题是:发出去的消息什么时候需要被接收到?这个问题引出了两个基础概念:“同步通信”和“异步通信”。根据理论抽象模型,同步通信和异步通信最本质的差别来自于时钟机制的有无。同步通信的双方需要一个校准的时钟,异步通信的双方不需要时钟。现实的情况是,没有完全校准的时钟,所以没有绝对的同步通信。同样,绝对异步通信意味着无法控制一个发出去的消息被接收到的时间点,无期限的等待一个消息显然毫无实际意义。所以,实际编程中所有的通信既不是“同步通信”也不是“异步通信”;或者说,既是“同步通信”也是“异步通信”。特别是对于应用层的通信,其底层架构可能既包含“同步机制”也包含“异步机制”。判断“同步”和“异步”消息的标准问题太深,而不适合继续展开。这里给一些启发式的建议:
当分析一个通信需求或者进行通信构架的时候,工程师们被迫作出“同步”还是“异步”的决定。当决策的结论是“异步通信”的时候,分布式队列编程模型就是一个备选项。 发送者接收者解耦 在进行通信需求分析的时候,需要回答的另外一个基本问题是:消息的发送方是否关心谁来接收消息,或者反过来,消息接收方是否关心谁来发送消息。消息的发送方和接收方不关心对方是谁、以及在哪里,分布式队列编程模型就是一个备选项。因为在这种场景下,分布式队列架构所带来的解耦能给系统架构带来这些好处:
消息暂存机制 在进行通信发送方设计的时候,如果消息无法被迅速处理掉而产生堆积怎么办、能否被直接抛弃?如果根据需求分析,确认存在消息积存,并且消息不应该被抛弃,就应该考虑分布式队列编程模型构架,因为队列可以暂存消息。 如何传递 对通信需求进行架构,一系列的基础挑战会迎面而来,这包括:
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() 性能 性能主要有两个方面需要考虑:吞吐量(Throughput)和响应时间(Latency)。 不同的消息队列中间件的吞吐量和响应时间相差甚远,在选型时可以去网上查看一些性能对比报告。 对于同一种中间件,不同的配置方式也会影响性能。主要有如下几方面的配置:
可靠性 可靠性主要包含:可用性、持久化、确认机制等。 高可用性的消息中间件应该具备如下特征:
高可靠的消息中间件应该确保从发送者接收到的消息不会丢失。中间件代理服务器的宕机并不是小概率事件,所以保存在内存中的消息很容易发生丢失。大部分的消息中间件都依赖于消息的持久化去降低消息丢失损失,即将接收到的消息写入磁盘。即使提供持久化,仍有两个问题需要考虑:
确认机制本质上是通讯的握手机制(Handshaking)。如果没有该机制,消息在传输过程中丢失将不会被发现。高敏感的消息要求选取具备确认机制的消息中间件。当然如果没有接收到消息中间件确认完成的指令,应用程序需要决定如何处理。典型的做法有两个:
客户端接口所支持语言 采用现存消息中间件就意味着避免重复造轮子。如果某个消息中间件未能提供对应语言的客户端接口,则意味着极大的成本和兼容性问题。 总结 ![]() |
出处:http://www.uml.org.cn/zjjs/201711173.asp
联系客服