互联网业务场景下消息队列架构

Posted 2021-04-26 Megadotnet

消息队列作为一种基础的抽象数据结构，被广泛应用在各类编程与系统设计中。

同步VS异步

通信的一个基本问题是：发出去的消息什么时候需要被接收到？这个问题引出了两个基础概念：“同步通信”和“异步通信”。根据理论抽象模型，同步通信和异步通信最本质的差别来自于时钟机制的有无。同步通信的双方需要一个校准的时钟，异步通信的双方不需要时钟。现实的情况是，没有完全校准的时钟，所以没有绝对的同步通信。同样，绝对异步通信意味着无法控制一个发出去的消息被接收到的时间点，无期限的等待一个消息显然毫无实际意义。所以，实际编程中所有的通信既不是“同步通信”也不是“异步通信”；或者说，既是“同步通信”也是“异步通信”。特别是对于应用层的通信，其底层架构可能既包含“同步机制”也包含“异步机制”。判断“同步”和“异步”消息的标准问题太深，而不适合继续展开。这里给一些启发式的建议：

• 发出去的消息是否需要确认，如果不需要确认，更像是异步通信，这种通信有时候也称为单向通信（One-Way Communication）。

• 如果需要确认，可以根据需要确认的时间长短进行判断。时间长的更像是异步通信，时间短的更像是同步通信。当然时间长短的概念是纯粹的主观概念，不是客观标准。

• 发出去的消息是否阻塞下一个指令的执行，如果阻塞，更像是同步，否则，更像是异步。

当分析一个通信需求或者进行通信构架的时候，工程师们被迫作出“同步”还是“异步”的决定。当决策的结论是“异步通信”的时候，分布式队列编程模型就是一个备选项。

发送者接收者解耦

在进行通信需求分析的时候，需要回答的另外一个基本问题是：消息的发送方是否关心谁来接收消息，或者反过来，消息接收方是否关心谁来发送消息。消息的发送方和接收方不关心对方是谁、以及在哪里，分布式队列编程模型就是一个备选项。因为在这种场景下，分布式队列架构所带来的解耦能给系统架构带来这些好处：

• 无论是发送方还是接收方，只需要跟消息中间件通信，接口统一。统一意味着降低开发成本。

• 在不影响性能的前提下，同一套消息中间件部署，可以被不同业务共享。共享意味着降低运维成本。

• 发送方或者接收方单方面的部署拓扑的变化不影响对应的另一方。解藕意味着灵活和可扩展。

消息暂存机制

在进行通信发送方设计的时候，如果消息无法被迅速处理掉而产生堆积怎么办、能否被直接抛弃？如果根据需求分析，确认存在消息积存，并且消息不应该被抛弃，就应该考虑分布式队列编程模型构架，因为队列可以暂存消息。

如何传递

对通信需求进行架构，一系列的基础挑战会迎面而来，这包括：

• 可用性，如何保障通信的高可用。

• 可靠性，如何保证消息被可靠地传递。

• 持久化，如何保证消息不会丢失。

• 吞吐量和响应时间。

• 跨平台兼容性。

• 除非工程师对造轮子有足够的兴趣，并且有充足的时间，采用一个满足各项指标的分布式队列编程模型就是一个简单的选择。

 
 
 
 
 
 
 
 
 
 

性能

性能主要有两个方面需要考虑：吞吐量（Throughput）和响应时间（Latency）。 
不同的消息队列中间件的吞吐量和响应时间相差甚远，在选型时可以去网上查看一些性能对比报告。 
对于同一种中间件，不同的配置方式也会影响性能。主要有如下几方面的配置：

• 是否需要确认机制，即写入队列后，或从队列读取后，是否需要进行确认。确认机制对响应时间的影响往往很大。

• 能否批处理，即消息能否批量读取或者写入。批量操作可以大大减少应用程序与消息中间件的交互次数和消息传递量，大大提高吞吐量。

• 能否进行分区（Partition）。将某一主题消息队列进行分区，同一主题消息可以有多台机器并行处理。这不仅仅能影响消息中间件的吞吐量，还决定着消息中间件是否具备良好的可伸缩性（Scalability）。

• 是否需要进行持久化。将消息进行持久化往往会同时影响吞吐量和响应时间。
  
  

可靠性

可靠性主要包含：可用性、持久化、确认机制等。 
高可用性的消息中间件应该具备如下特征：

• 消息中间件代理服务器（Broker）具有主从备份。即当一台代理服务宕机之后，备用服务器能接管相关的服务。

• 消息中间件中缓存的消息是否有备份、并持久化。

• 根据CAP理论，高可用、高一致性以及网络分裂不可兼得。根据作者的观察，大部分的消息中间件在面临网络分裂的情况下下，都很难保证数据的一致性以及可用性。 很多消息中间件都会提供一些可配置策略，让使用者在可用性和一致性之间做权衡。

高可靠的消息中间件应该确保从发送者接收到的消息不会丢失。中间件代理服务器的宕机并不是小概率事件，所以保存在内存中的消息很容易发生丢失。大部分的消息中间件都依赖于消息的持久化去降低消息丢失损失，即将接收到的消息写入磁盘。即使提供持久化，仍有两个问题需要考虑：

• 磁盘损坏问题。长时间来看，磁盘出问题的概率仍然存在。

• 性能问题。与操作内存相比，磁盘I/O的操作性能要慢几个数量级。频繁持久化不仅会增加响应时间，也会降低吞吐量。

• 解决这两个问题的一个解决方案就是：多机确认，定期持久化。即消息被缓存在多台机器的内存中，只有每台机器都确认收到消息，才跟发送者确认（很多消息中间件都会提供相应的配置选项，让用户设置最少需要多少台机器接收到消息）。由于多台独立机器同时出故障的概率遵循乘法法则，指数级降低，这会大大提高消息中间件的可靠性。

确认机制本质上是通讯的握手机制（Handshaking）。如果没有该机制，消息在传输过程中丢失将不会被发现。高敏感的消息要求选取具备确认机制的消息中间件。当然如果没有接收到消息中间件确认完成的指令，应用程序需要决定如何处理。典型的做法有两个：

• 多次重试。

• 暂存到本地磁盘或其它持久化媒介。

客户端接口所支持语言

采用现存消息中间件就意味着避免重复造轮子。如果某个消息中间件未能提供对应语言的客户端接口，则意味着极大的成本和兼容性问题。

总结

相关技术与理论参考：

1. Zookeeper  
2. CAP