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