并发计算模型BSP与SEDA

 

1    BSP批量同步并行计算

BSP(Bulk Synchronous Parallel)批量同步并行计算用来解决并发编程难的问题。名字听起来有点矛盾，又是同步又是并行的。由于计算被分组成一个个超步(super-step)，超步内并行计算而且结点间不能通讯。在超步之间设置同步栅栏(barrier synchronization)，计算完成后相互通讯，所有完成后才能继续下一个超步。

2 SEDA阶段式事件驱动架构

SEDA(staged event-driven architecture)分阶段的事件驱动架构。它不一样于经典的基于线程的并发处理架构，也区别于现今流行的事件驱动。

 

 

Ø  基于线程的并发：资源使用率高(上下文切换，锁争夺)，过多的线程难以实现高吞吐量、低响应时间。传统作法是限制总的线程数。

Ø  事件驱动的并发：用少许事件处理线程配合许多状态机(FSM)，提供高效和可扩展的并发性能。FSM间没有错误和性能隔离，而且FSM代码不能阻塞。

事件驱动的有限状态机在Web服务器中很常见。

 

接下来要说的就是SEDA了，它具备如下特色：

Ø  将服务分解为用队列分隔开的阶段

Ø  每阶段执行请求处理的一部分

Ø  阶段内事件驱动(非阻塞的)

Ø  队列的引入方便了执行边界的隔离

Ø  每阶段包含一个线程池

Ø  然而线程不对应用程序暴露

Ø  线程池的大小根据须要会自动扩张或收缩

能够看出关键词有三个：阶段、队列、线程池。

队列

首先，经过队列咱们可以实施一些控制策略(admission control policy)。例如经过阀值、速率控制是否入队仍是阻塞(将压力反弹回去, backpressure)、服务降级、丢弃。

其次，各个线程只在阶段内执行，实现了性能隔离、模块化和独立的加载管理。

最后，显式的事件分发使应用程序可以追踪事件流，监控队列长度来检测瓶颈。

线程池

观察输入队列长度，动态添加线程，或移除空闲线程。观察输出速率，找到高吞吐量与低响应时间的平衡点。

吞吐量与响应时间的关系

“计算机系统的整体性能标准是吞吐量和响应时间。

吞吐量是对单位时间内完成的工做量的量度。示例包括：每分钟的数据库事务；每秒传送的文件千字节数；每秒读或写的文件千字节数；每分钟的 Web 服务器命中数

响应时间是提交请求和返回该请求的响应之间使用的时间。示例包括：数据库查询花费的时间；将字符回显到终端上花费的时间；访问 Web 页面花费的时间

这些度量之间的关系很复杂。有时可能以响应时间为代价而获得较高的吞吐量，而有时候又要以吞吐量为代价获得较好的响应时间。在其余状况下，一个单独的更改可能对二者都有提升。可接受的性能基于合理的吞吐量与合理的响应时间相结合。

一般，平均响应时间越短，系统吞吐量越大；平均响应时间越长，系统吞吐量越小。可是，系统吞吐量越大， 未必平均响应时间越短。由于在某些状况（例如，不增长任何硬件配置）吞吐量的增大，有时会把平均响应时间做为牺牲，来换取一段时间处理更多的请求。

举个例子：一个理发店，只有一个理发师、一把理发椅子、一张方便客人等待的长凳。理发师一次只能处理一个客户，其余等待的用户显得很不耐烦，外面打算进来理发的人也放弃了在这家店理发的打算……有一天，理发师有钱了，他多买了2把理发椅子。这样他能够同时给3我的理发：当其中一我的理到必定阶段须要调整或定型的时候，他就转向另一个客户为其服务，依次类推。这样，他发现一天内他能够理的人数比之前增多了，可是还会有一些后来的客户抱怨等待时间太长。后来，理发师招了2名学徒帮他一块儿干活。他发现这样一来天天的理发效率增长了将近2倍，并且客户的等待时间也明显减小。可是成本增多了，理发用具、洗发水、发工资，这让他以为开个理发店也要精打细算。“

以上面Web服务器中的事件驱动有限状态机为例，经过SEDA改造后，其架构就变为：

FSM中的各个状态被划分红一系列的阶段，由不一样的队列隔离开。每一个阶段能被独立管理，而且阶段间能够或串行或并行或二者组合的方式地执行。 

参考资料

1 The Staged Event-Driven Architecture for Highly-Concurrent Server Applications

2 SEDA: An Architecture for Scalable, Well-Conditioned Internet Services