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

最基础的分布式队列编程抽象模型是点对点模型,其他抽象构架模型居于改基本模型上各角色的数量和交互变化所导致的不同拓扑图.具体而言,不同数量的发送者、分布式队列以及接收者组合形成了不同的分布式队列编程模型.记住并理解典型的抽象模型结构对需求分析和建模而言至关重要,同时也会有助于学习和深入理解开源框架以及别人的代码.

点对点模型(Point-to-point)

基础模型中,只有一个发送者、一个接收者和一个分布式队列.如下图所示：

生产者消费者模型(Producer–consumer)

如果发送者和接收者都可以有多个部署实例,甚至不同的类型；但是共用同一个队列,这就变成了标准的生产者消费者模型.在该模型,三个角色一般称为生产者(Producer)、分布式队列(Queue)、消费者(Consumer).

发布订阅模型(PubSub)

如果只有一类发送者,发送者将产生的消息实体按照不同的主题(Topic)分发到不同的逻辑队列.每种主题队列对应于一类接收者.这就变成了典型的发布订阅模型.在该模型,三个角色一般称为发布者(Publisher),分布式队列(Queue),订阅者(Subscriber).

MVC模型

如果发送者和接收者存在于同一个实体中,但是共享一个分布式队列.这就很像经典的MVC模型.

编程模型

为了让读者更好地理解分布式队列编程模式概念,这里将其与一些容易混淆的概念做一些对比 .

分布式队列模型编程和异步编程

分布式队列编程模型的通讯机制一般是采用异步机制,但是它并不等同于异步编程.

首先,并非所有的异步编程都需要引入队列的概念,例如：大部分的操作系统异步I/O操作都是通过硬件中断( Hardware Interrupts)来实现的.

其次,异步编程并不一定需要跨进程,所以其应用场景并不一定是分布式环境.

最后,分布式队列编程模型强调发送者、接收者和分布式队列这三个角色共同组成的架构.这三种角色与异步编程没有太多关联.

分布式队列模式编程和流式编程

随着Spark Streaming,Apache Storm等流式框架的广泛应用,流式编程成了当前非常流行的编程模式.但是本文所阐述的分布式队列编程模型和流式编程并非同一概念.

首先,本文的队列编程模式不依赖于任何框架,而流式编程是在具体的流式框架内的编程.

其次,分布式队列编程模型是一个需求解决方案,关注如何根据实际需求进行分布式队列编程建模.流式框架里的数据流一般都通过队列传递,不过,流式编程的关注点比较聚焦,它关注如何从流式框架里获取消息流,进行map、reduce、 join等转型(Transformation)操作、生成新的数据流,最终进行汇总、统计.

2、实战篇

这里所有的项目都是作者在新美大工作的真实案例.实战篇的关注点是训练建模思路,所以这些例子都按照挑战、构思、架构三个步骤进行讲解.受限于保密性要求,有些细节并未给出,但这些细节并不影响讲解的完整性.

另一方面,特别具体的需求容易让人费解,为了使讲解更加顺畅,作者也会采用一些更通俗易懂的例子.通过本篇的讲解,希望和读者一起去实践“如何从需求出发去构架分布式队列编程模型”.

需要声明的是,这里的解决方案并不是所处场景的最优方案.但是,任何一个稍微复杂的问题,都没有最优解决方案,更谈不上唯一的解决方案.实际上,工程师每天所追寻的只是在满足一定约束条件下的可行方案.当然不同的约束会导致不同的方案,约束的松弛度决定了工程师的可选方案的宽广度.

信息采集处理

信息采集处理应用广泛,例如：广告计费、用户行为收集等.作者碰到的具体项目是为广告系统设计一套高可用的采集计费系统.

典型的广告CPC、CPM计费原理是：收集用户在客户端或者网页上的点击和浏览行为,按照点击和浏览进行计费.计费业务有如下典型特征：

• 采集者和处理者解耦,采集发生在客户端,而计费发生在服务端.

• 计费与钱息息相关.

• 重复计费意味着灾难.

• 计费是动态实时行为,需要接受预算约束,如果消耗超过预算,则广告投放需要停止.
• 用户的浏览和点击量非常大.

挑战

计费业务的典型特征给我们带来了如下挑战：

• 高吞吐量－－广告的浏览和点击量非常巨大,我们需要设计一个高吞吐量的采集架构.

• 高可用性－－计费信息的丢失意味着直接的金钱损失.任何处理服务器的崩溃不应该导致系统不可用.

• 高一致性要求－－计费是一个实时动态处理过程,但要受到预算的约束.收集到的浏览和点击行为如果不能快速处理,可能会导致预算花超,或者点击率预估不准确.所以采集到的信息应该在最短的时间内传输到计费中心进行计费.

• 完整性约束－－这包括反作弊规则,单个用户行为不能重复计费等.这要求计费是一个集中行为而非分布式行为.
• 持久化要求－－计费信息需要持久化,避免因为机器崩溃而导致收集到的数据产生丢失.

构思

采集的高可用性意味着我们需要多台服务器同时采集,为了避免单IDC故障,采集服务器需要部署在多IDC里面.

实现一个高可用、高吞吐量、高一致性的信息传递系统显然是一个挑战,为了控制项目开发成本,采用开源的消息中间件进行消息传输就成了必然选择.

完整性约束要求集中进行计费,所以计费系统发生在核心IDC.

计费服务并不关心采集点在哪里,采集服务也并不关心谁进行计费.

根据以上构思,我们认为采集计费符合典型的“生产者消费者模型”.

架构

（编辑：ASP站长网）