互联网业务场景下消息队列架构互联网业务场景下消息队列架构
消息队列作为一种基础的抽象数据结构,被广泛应用在各类编程与系统设计中。
同步VS异步
通信的一个基本问题是:发出去的消息什么时候需要被接收到?这个问题引出了两个基础概念:“同步通信”和“异步通信”。根
据理论抽象模型,同步通信和异步通信最本质的差别来自于时钟机制的有无。同步通信的双方需要一个校准的时钟,异步通信
的双方不需要时钟。现实的情况是,没有完全校准的时钟,所以没有绝对的同步通信。同样,绝对异步通信意味着无法控制一
个发出去的消息被接收到的时间点,无期限的等待一个消息显然毫无实际意义。所以,实际编程中所有的通信既不是“同步通
信”也不是“异步通信”;或者说,既是“同步通信”也是“异步通信”。特别是对于应用层的通信,其底层架构可能既包含“同步机
制”也包含“异步机制”。判断“同步”和“异步”消息的标准问题太深,而不适合继续展开。这里给一些启发式的建议:
发出去的消息是否需要确认,如果不需要确认,更像是异步通信,这种通信有时候也称为单向通信(One-Way
Communication)。
如果需要确认,可以根据需要确认的时间长短进行判断。时间长的更像是异步通信,时间短的更像是同步通信。当然时
间长短的概念是纯粹的主观概念,不是客观标准。
发出去的消息是否阻塞下一个指令的执行,如果阻塞,更像是同步,否则,更像是异步。
当分析一个通信需求或者进行通信构架的时候,工程师们被迫作出“同步”还是“异步”的决定。当决策的结论是“异步通信”的时
候,分布式队列编程模型就是一个备选项。
发送者接收者解耦
在进行通信需求分析的时候,需要回答的另外一个基本问题是:消息的发送方是否关心谁来接收消息,或者反过来,消息接收
方是否关心谁来发送消息。消息的发送方和接收方不关心对方是谁、以及在哪里,分布式队列编程模型就是一个备选项。因为
在这种场景下,分布式队列架构所带来的解耦能给系统架构带来这些好处:
无论是发送方还是接收方,只需要跟消息中间件通信,接口统一。统一意味着降低开发成本。
在不影响性能的前提下,同一套消息中间件部署,可以被不同业务共享。共享意味着降低运维成本。
发送方或者接收方单方面的部署拓扑的变化不影响对应的另一方。解藕意味着灵活和可扩展。
消息暂存机制
在进行通信发送方设计的时候,如果消息无法被迅速处理掉而产生堆积怎么办、能否被直接抛弃?如果根据需求分析,确认存
在消息积存,并且消息不应该被抛弃,就应该考虑分布式队列编程模型构架,因为队列可以暂存消息。
如何传递
对通信需求进行架构,一系列的基础挑战会迎面而来,这包括:
可用性,如何保障通信的高可用。
可靠性,如何保证消息被可靠地传递。
持久化,如何保证消息不会丢失。
吞吐量和响应时间。
跨平台兼容性。
除非工程师对造轮子有足够的兴趣,并且有充足的时间,采用一个满足各项指标的分布式队列编程模型就是一个简单的
选择。