加入收藏 | 设为首页 | 会员中心 | 我要投稿 云计算网_泰州站长网 (http://www.0523zz.com/)- 视觉智能、AI应用、CDN、行业物联网、智能数字人!
当前位置: 首页 > 服务器 > 安全 > 正文

一篇文了解分布式队列编程:从模型、实战到优化

发布时间:2021-01-09 13:12:45 所属栏目:安全 来源:网络整理
导读:副标题#e# 《一篇文了解分布式队列编程:从模型、实战到优化》要点: 本文介绍了一篇文了解分布式队列编程:从模型、实战到优化,希望对您有用。如果有疑问,可以联系我们。 本文由美团点评技术团队出品,一篇文助你掌握分布式队列编程的要义.从模型到实战再
副标题[/!--empirenews.page--]

《一篇文了解分布式队列编程:从模型、实战到优化》要点:
本文介绍了一篇文了解分布式队列编程:从模型、实战到优化,希望对您有用。如果有疑问,可以联系我们。

本文由美团点评技术团队出品,一篇文助你掌握分布式队列编程的要义.从模型到实战再到优化,基本涵盖你可能踩的坑与其解决办法.

作为一种基础的抽象数据结构,队列被广泛应用在各类编程中.大数据时代对跨进程、跨机器的通讯提出了更高的要求,和以往相比,分布式队列编程的运用几乎已无处不在.但是,这种常见的基础性的事物往往容易被忽视,使用者往往会忽视两点:

使用分布式队列的时候,没有意识到它是队列.

有具体需求的时候,忘记了分布式队列的存在.

文章首先从最基础的需求出发,详细剖析分布式队列编程模型的需求来源、定义、结构以及其变化多样性.通过这一部分的讲解,作者期望能在两方面帮助读者:一方面,提供一个系统性的思考方法,使读者能够将具体需求关联到分布式队列编程模型,具备进行分布式队列架构的能力;另一方面,通过全方位的讲解,让读者能够快速识别工作中碰到的各种分布式队列编程模型.

文章的第二部分实战篇.根据作者在新美大实际工作经验,给出了队列式编程在分布式环境下的一些具体应用.这些例子的基础模型并非首次出现在互联网的文档中,但是所有的例子都是按照挑战、构思、架构三个步骤进行讲解的.这种讲解方式能给读者一个“从需求出发去构架分布式队列编程”的旅程.

老司机介绍

刘丁,新美大广告平台CRM系统技术负责人,曾就职于Amazon、Tripadvisor.2014年加入美团,先后负责美团推荐系统、智能筛选系统架构,作为技术负责人主导了美团广告系统的开发和上线.目前致力于推进新美大广告运营的标准化、自动化和智能化.

新美大广告平台是美团、大众点评双平台的营销推广平台,帮助商户推广店铺品牌及提升客流量.

1、模型篇

模型篇从基础的需求出发,去思考何时以及如何使用分布式队列编程模型.建模环节非常重要,因为大部分中高级工程师面临的都是具体的需求,接到需求后的第一个步骤就是建模.通过本篇的讲解,希望读者能够建立起从需求到分布式队列编程模型之间的桥梁.

何时选择分布式队列

通信是人们最基本的需求,同样也是计算机最基本的需求.对于工程师而言,在编程和技术选型的时候,更容易进入大脑的概念是RPC、RESTful、Ajax、Kafka.在这些具体的概念后面,最本质的东西是“通讯”.

所以,大部分建模和架构都需要从“通信”这个基本概念开始.当确定系统之间有通讯需求的时候,工程师们需要做很多的决策和平衡,这直接影响工程师们是否会选择分布式队列编程模型作为架构.从这个角度出发,影响建模的因素有四个:When、Who、Where、How.

When:同步VS异步

通信的一个基本问题是:发出去的消息什么时候需要被接收到?这个问题引出了两个基础概念:“同步通讯”和“异步通讯”.根据理论抽象模型,同步通信和异步通信最本质的差别来自于时钟机制的有无.同步通信的双方需要一个校准的时钟,异步通信的双方不需要时钟.

现实的情况是,没有完全校准的时钟,所以没有绝对的同步通信.同样,绝对异步通信意味着无法控制一个发出去的消息被接收到的时间点,无期限的等待一个消息显然毫无实际意义.

所以,实际编程中所有的通信既不是“同步通信”也不是“异步通信”;或者说,既是“同步通信”也是“异步通信”.特别是对于应用层的通信,其底层架构可能既包含“同步机制”也包含“异步机制”.判断“同步”和“异步”消息的标准问题太深,而不适合继续展开.作者这里给一些启发式的建议:

发出去的消息是否需要确认,如果不需要确认,更像是异步通信,这种通信有时候也称为单向通信(One-WayCommunication).

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

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

无论如何,工程师们不能生活在混沌之中,不做决定往往是最坏的决定.当分析一个通信需求或者进行通信构架的时候,工程师们被迫作出“同步”还是“异步”的决定.当决策的结论是“异步通信”的时候,分布式队列编程模型就是一个备选项.

Who:发送者接收者解耦

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

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

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

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

Where:消息暂存机制

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

How:如何传递

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

可用性,如何保障通信的高可用.

可靠性,如何保证消息被可靠地传递.

持久化,如何保证消息不会丢失.

吞吐量和响应时间.

跨平台兼容性.

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

分布式队列编程定义

很难给出分布式队列编程模型的精确定义,由于本文偏重于应用,作者并不打算完全参照某个标准的模型.总体而言:分布式队列编程模型包含三类角色:发送者(Sender)、分布式队列(Queue)、接收者(Receiver).发送者和接收者分别指的是生产消息和接收消息的应用程序或服务.

需要重点明确的概念是分布式队列,它是提供以下功能的应用程序或服务:

接收“发送者”产生的消息实体;

传输、暂存该实体;

为“接收者”提供读取该消息实体的功能.

特定的场景下,它当然可以是Kafka、RabbitMQ等消息中间件.但它的展现形式并不限于此,例如:

队列可以是一张数据库的表,发送者将消息写入表,接收者从数据表里读消息.

如果一个程序把数据写入Redis等内存Cache里面,另一个程序从Cache里面读取,缓存在这里就是一种分布式队列.

流式编程里面的的数据流传输也是一种队列.

(编辑:云计算网_泰州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读