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

互联网业务场景下消息队列架构 功能次要有两个方面需要考虑：吞吐量（Throughput）和响应时间（Latency）。 不同的消息队列两头件的吞吐量和响应时间相差甚远，在选型时可以去网上查看一些功能对比报告。 对于同一种两头件，不同的配置方式也会影响功能。次要有如下几方面的配置： 能否需要确认机制，即写入队列后，或从队列读取后，能否需要进行确认。确认机制对响应时间的影响往往很大。 能否批处理，即消息能否批量读取或者写入。批量操作可以大大削减应用程序与消息两头件的交互次数和消息传递量，大大提高吞吐量。 能否进行分区（Partition）。将某一主题消息队列进行分区，同一主题消息可以有多台机器并行处理。这不只仅能影响消息两头件的吞吐量，还打算着消息两头件能否具备良好的可伸缩性（Scalability）。 能否需要进行长久化。将消息进行长久化往往会同时影响吞吐量和响应时间。 牢靠性 牢靠性次要包含：可用性、长久化、确认机制等。 高可用性的消息两头件应当具备如下特征： 消息两头件代理服务器（Broker）具有主从备份。即当一台代理服务宕机之后，备用服务器能接管相关的服务。 消息两头件中缓存的消息能否有备份、并长久化。 依据CAP理论，高可用、高全都性以及网络分裂不行兼得。依据作者的观看，大部分的消息两头件在面临网络分裂的情况下下，都很难保证数据的全都性以及可用性。 很多消息两头件都会供应一些可配置策略，让使用者在可用性和全都性之间做权衡。 高牢靠的消息两头件应当确保从发送者接收到的消息不会丢失。两头件代理服务器的宕机并不是小概率大事，所以保存在内存中的消息很简约发生丢失。大部分的消息两头件都依靠于消息的长久化去降低消息丢失损失，即将接收到的消息写入磁盘。即便供应长久化，仍有两个问题需要考虑： 磁盘损坏问题。长时间来看，磁盘出问题的概率仍旧存在。 功能问题。与操作内存相比，磁盘I/O的操作功能要慢几个数量级。频繁长久化不只会添加响应时间，也会降低吞吐量。 处理这两个问题的一个处理方案就是：多机确认，定期长久化。即消息被缓存在多台机器的内存中，只要每台机器都确认收到消息，才跟发送者确认（很多消息两头件都会供应相应的配置选项，让用户设置最少需要多少台机器接收到消息）。由于多“台独”立机器同时出毛病的概率遵照乘法法则，指数级降低，这会大大提高消息两头件的牢靠性。 确认机制本质上是通讯的握手机制（Handshaking）。假如没有该机制，消息在传输过程中丢失将不会被发觉。高敏感的消息要求选取具备确认机制的消息两头件。当然假如没有接收到消息两头件确认完成的指令，应用程序需要打算如何处理。典型的做法有两个： 多次重试。 暂存到本地磁盘或其它长久化媒介。 客户端接口所支持言语 接受现存消息两头件就意味着避开反复造轮子。假如某个消息两头件未能供应对应言语的客户端接口，则意味着极大的成本和兼容性问题。 总结