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

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

同步VS异步

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

  • 发出去的消息是否需要确认,如果不需要确认,更像是异步通信,这种通信有时候也称为单向通信(One-Way Communication)。
  • 如果需要确认,可以根据需要确认的时间长短进行判断。时间长的更像是异步通信,时间短的更像是同步通信。当然时间长短的概念是纯粹的主观概念,不是客观标准。
  • 发出去的消息是否阻塞下一个指令的执行,如果阻塞,更像是同步,否则,更像是异步。

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

发送者接收者解耦

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

  • 无论是发送方还是接收方,只需要跟消息中间件通信,接口统一。统一意味着降低开发成本。
  • 在不影响性能的前提下,同一套消息中间件部署,可以被不同业务共享。共享意味着降低运维成本。
  • 发送方或者接收方单方面的部署拓扑的变化不影响对应的另一方。解藕意味着灵活和可扩展。

消息暂存机制

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

如何传递

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

  • 可用性,如何保障通信的高可用。
  • 可靠性,如何保证消息被可靠地传递。
  • 持久化,如何保证消息不会丢失。
  • 吞吐量和响应时间。
  • 跨平台兼容性。
  • 除非工程师对造轮子有足够的兴趣,并且有充足的时间,采用一个满足各项指标的分布式队列编程模型就是一个简单的选择。











性能

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

    • 是否需要确认机制,即写入队列后,或从队列读取后,是否需要进行确认。确认机制对响应时间的影响往往很大。
    • 能否批处理,即消息能否批量读取或者写入。批量操作可以大大减少应用程序与消息中间件的交互次数和消息传递量,大大提高吞吐量。
    • 能否进行分区(Partition)。将某一主题消息队列进行分区,同一主题消息可以有多台机器并行处理。这不仅仅能影响消息中间件的吞吐量,还决定着消息中间件是否具备良好的可伸缩性(Scalability)。
    • 是否需要进行持久化。将消息进行持久化往往会同时影响吞吐量和响应时间。

可靠性

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

    • 消息中间件代理服务器(Broker)具有主从备份。即当一台代理服务宕机之后,备用服务器能接管相关的服务。
    • 消息中间件中缓存的消息是否有备份、并持久化。
    • 根据CAP理论,高可用、高一致性以及网络分裂不可兼得。根据作者的观察,大部分的消息中间件在面临网络分裂的情况下下,都很难保证数据的一致性以及可用性。 很多消息中间件都会提供一些可配置策略,让使用者在可用性和一致性之间做权衡。

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

    • 磁盘损坏问题。长时间来看,磁盘出问题的概率仍然存在。
    • 性能问题。与操作内存相比,磁盘I/O的操作性能要慢几个数量级。频繁持久化不仅会增加响应时间,也会降低吞吐量。
    • 解决这两个问题的一个解决方案就是:多机确认,定期持久化。即消息被缓存在多台机器的内存中,只有每台机器都确认收到消息,才跟发送者确认(很多消息中间件都会提供相应的配置选项,让用户设置最少需要多少台机器接收到消息)。由于多台独立机器同时出故障的概率遵循乘法法则,指数级降低,这会大大提高消息中间件的可靠性。

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

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

客户端接口所支持语言

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

总结

相关技术与理论参考:

1. Zookeeper https://zookeeper.apache.org/
2. CAP https://en.wikipedia.org/wiki/CAP_theorem

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

希望对您系统架构,软件项目开发,运维管理,系统架构与研发管理体系, 信息安全, 企业信息化等有帮助。 其它您可能感兴趣的文章:

集中队列的模式
消息系统架构设计演进
DevOps的基本原则与介绍
Docker与CI持续集成/CD
持续交付中高效率与高质量
持续集成CI与自动化测试
软件研发工程基础设施
容器化实践金融业案例一
云计算参考架构几例
微服务与Docker介绍
互联网直播平台架构案例一
高可用架构案例一
某互联网公司广告平台技术架构
某大型电商云平台实践
云计算参考架构几例
移动应用App测试与质量管理一
全面的软件测试
著名ERP厂商的SSO单点登录解决方案介绍一
软件项目风险管理介绍
企业项目化管理介绍
智能企业与信息化之一
由企业家基本素质想到的
敏捷软件质量保证的方法与实践
构建高效的研发与自动化运维
IT运维监控解决方案介绍
IT持续集成之质量管理
人才公司环境与企业文化
企业绩效管理系统之平衡记分卡
企业文化、团队文化与知识共享
高效能的团队建设
餐饮连锁公司IT信息化解决方案一

如有想了解更多软件研发 , 系统 IT集成 , 企业信息化,项目管理,企业管理 等资讯,请关注我的微信订阅号:

 

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog

时间: 2024-10-25 11:54:33

互联网业务场景下消息队列架构的相关文章

某种业务场景下,将一个工作区的多个字段整理到一个内表中

1 DATA:num TYPE i. 2 CONSTANTS: times TYPE i VALUE 29. 3 DATA: BEGIN OF ih_lgty, 4 lgty TYPE lgtyp, 5 END OF ih_lgty, 6 it_lgty LIKE TABLE OF ih_lgty. 7 FIELD-SYMBOLS: <lgty> TYPE any, 8 <t334t> LIKE t334t. 9 10 DATA:lh_t334t LIKE t334t, 11 lt

(转)(二)RabbitMQ消息队列-RabbitMQ消息队列架构与基本概念

http://blog.csdn.net/super_rd/article/details/70238869 没错我还是没有讲怎么安装和写一个HelloWord,不过快了,这一章我们先了解下RabbitMQ的基本概念. RabbitMQ架构 说是架构其实更像是应用场景下的架构(自己画的有点丑,勿嫌弃) 从图中可以看出RabbitMQ主要由Exchange和Queue两部分组成,然后通过RoutingKey关联起来,消息投递到Exchange然后通过Queue接收. RabbitMQ消息队列基本概

用SendNotifyMessage代替PostMessage避免消息丢失(WIN7下消息队列的默认长度是10000,队列满后消息将被丢弃)

大家都知道PostMessage会丢消息,但是消息队列的大小是多少呢,下面做了一个测试. 代码: 1 unit Unit1; 2 3 interface 4 5 uses 6 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, 7 Dialogs, StdCtrls; 8 9 const 10 UM_ADD = WM_USER + 100; 11 12 type 13 TForm1 = class(

linux 下消息队列发送后没有信息

在使用消息队列时,调用 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <sys/ipc.h> #include <sys/msg.h> struct mymsg { long mytype; char even[32]; }; #define VALUE (key_t)0x1fff int main(

高CPU业务场景下的任务分发方案Gearman搭建一览

  Gearman是当年LiveJournal用来做图片resize的,大家也明白图片resize是一个高CPU的操作,如果让web网站去做这个高CPU的功能,有可能会拖垮你的 web应用,那本篇我们来看看gearman是如何解决这个问题的,它的架构图类似下面这样: 从上面这张图,你应该会看到,Gearman是由三个部分组成: 1. Job Server 这个就是Gearman的Job Server,通过它对Client 和 jobwork 进行桥接,是不是想起来了中介者模式... 2. Cli

MvcPager.js在特定业务场景下的问题解决

用到了MvcPager.js,在一个常见的场景中出现了不能POST表单数据的问题,场景描述如下: 日期:2012-12-12 编号:*****                                                                                                                         [查询] 数据列表 首页 1 2 3 ...19 尾页 页面加载完成后,如果首先点击分页页码,那么查询条件部分的日期

refs的作用是什么,你在什么业务场景下使用过refs

作用是操作dom 场景:图片加载完以后获取图片的宽高 // window上添加事件监听后,组件销毁前需要移除 class Test extends React.Component { constructor(props){ super(props); this.state = { top: 0 } this.handleWindowScroll = this.handleWindowScroll.bind(this); } handleWindowScroll() { this.setState

互联网业务基础设施建设

非功能性需求 ------------------------------------------------------------------ 今天先到这儿,希望对您技术领导力, 企业管理,系统架构设计与评估,团队管理, 项目管理, 产品管理,团队建设 有参考作用 , 您可能感兴趣的文章: 国际化环境下系统架构演化微服务架构设计视频直播平台的系统架构演化微服务与Docker介绍Docker与CI持续集成/CD互联网电商购物车架构演变案例互联网业务场景下消息队列架构互联网高效研发团队管理演进之

浅析腾讯云分布式高可靠消息队列服务CMQ架构

在分布式大行其道的今天,我们在系统内部.平台之间广泛运用消息中间件进行数据交换及解耦.CMQ是腾讯云内部自研基于的高可靠.强一致.可扩展分布式消息队列,在腾讯内部包括微信手机QQ业务红包.腾讯话费充值.广告订单等都有广泛使用.目前已上线腾讯云对外开放,本文对腾讯云CMQ核心技术原理进行分享介绍. CMQ消息队列主要适用于金融.交易.订单等对可靠性.可用性有较高要求的业务场景. 以腾讯充值系统为例,该充值系统通过CMQ 对交易模块.发货部分.结算系统进行异步解耦.削峰填谷,一方面大大降低了模块间耦