星巴克不使用两阶段认可的事务处理

Hotto Cocoa o Kudasai（请给一杯热巧克力）

在日本待了两周，刚回家。在日本有一个熟悉的景观，那便是多得有些出奇的星巴克咖啡店， 特别是在新宿和六本木附近。在咖啡店等待我要的热巧克力的时候，我就在想着星巴克如何处理订单。 象其他任何商业机构一样，星巴克也是要追求最大程度的订单处理量，订单越多意味着产值 越大。他们采用的是异步处理方法：当你点了你的饮料后，柜台上的服务员便标记上你所要的 饮料，然后把它放到一个队列中，这其实是一个放在咖啡机上的饮料杯的队列。正是这个队列 把前台接单的服务员和后面制作饮料的咖啡师分离开来。前台服务员不停地接单，尽管后面的 咖啡师那里会有积压。如果太忙，可以调更多的咖啡师过来（这正是多个竞争消费者的情形 －Competing Consumer）。

关联（Correlation）

使用异步途径的星巴克同样得对付异步处理方式带来的挑战，例如，关联（correlation）。 顾客们订的饮料并非一定会按照接单的顺序做好。这可能有两个原因。第一，不同的咖啡师 可能会使用不同的咖啡机。还有，需要调配的咖啡会比直接从咖啡机里淌出来即可的咖啡要 花更长的时间。第二，一个咖啡师可能会同时制作多份咖啡以提高工效。这样一来，星巴克 需要解决关联问题：在咖啡做好后顺序已乱的情况下，要把每杯咖啡送到正确的顾客手中。 星巴克用来解决这个问题的方法和我们在异步消息中所用的模式是一样的，即使用关联 标识。在美国，许多星巴克是在咖啡杯上写上客人的名字作为关联标识，然后在咖啡做好 后，大声地叫客人的名字。在其他有些国家则是用客人点的饮料本身作为关联。

异常处理（Exception Handling）

异步消息传递系统中的异常处理可能会很困难。如果说，现实世界能写出最好的故事，那么 我们可以好好观察一下星巴克是怎样对付异常情况的，并从中学到些什么。设想，你如果 不付款，他们会干什么呢？如果你的咖啡已做好，他们会把它倒掉。如果还没做，他们会把 你的杯子从队列中抽出来扔掉。如果给你的咖啡弄错了或者你不满意，他们可以重做一杯。 如果机器坏了，不能做了，他们会退款。每一种情形其实都描述了一种普遍的出错处理策略。

• 注销（write-off）。这是所有策略中最简单的一种：什么都不做，或是把所做的全 扔掉。这听起来似乎很糟糕，但在商业环境中这个选择是可以被接受的，通常条件是： 如果损失很小，而建立一套错误纠正机制可能会很昂贵。例如，我曾在多家ISP工作过， 当在记帐、供应环节中出错时，他们都会选择这样的策略。其结果是某个用户可能会得到 服务而没有被记帐。因为这样造成的产值损失是很小的，可以允许公司这样操作。公司也 会周期性地运行“对账”（reconciliation）程序以检测出那些“免费”用户。
• 重试（retry）。当一组操作（如一个事务－transaction）中的某些操作失败后， 我们基本上有两种选择：撤销已执行的、或重新试一下失败的。如果有相当现实的 可能性重试能成功的话，那么重试是个可行的选择。例如，业务规则不满足造成失败，那么 重试一般来说也不会成功。可是，如果失败是因为某个外部系统暂时不工作而引起的，那么 重试很有可能会成功。一个特例是可以用幂等接收器（Idempotent receiver）作重试。 我们可以重试所有的操作，因为合格的（幂等）接收者会扔掉那些重复的消息。
• 补偿行动（conpensation action）。最后一个选择是撤销那些那些已完成的操作， 使系统回到一致性的状态。这种补偿行动在财务系统或类似的系统中工作良好， 如在财务系统中，如果取款操作撤销的话，你可以把一笔钱打回那个帐户。

所有这些策略都与那种依赖于准备和执行的两阶段式的事务管理不同。在星巴克的环境 下，两阶段式的处理意味着，在前台上，钱和收据都放在那等着，等咖啡做好后把咖啡也 拿过来放在一起。最后，钱、收据、咖啡同时易手。在此过程中，前台服务员和顾客都 不能离开（去做别的事情），一直到这笔“事务”完成。用这种两阶段的处理方式一定 会毁掉星巴克的生意，因为在一个时间段里可以服务的顾客数会大幅度地减少。这很好地 提醒我们，虽然两阶段式处理方式可以使我们的生活容易许多，但却要损伤消息的自由流动 （因此损害系统的扩放性），因为它必须要在多个异步活动间同时维持着多个具有状态性 的（stateful）事务资源。

交谈（Conversations）

咖啡店里的互动也是一个很好的简单而常见的交谈（conversation）模式。两方的互动 （顾客和咖啡店）包括一个短暂的同步性交互（点饮料和付款），以及一个长一些的 异步的互动（制作和交付饮料）。这种情形在购物时非常普遍。例如，在Amazon下单时， 一个短暂的互动给你分配一个订单号，所有后续步骤（如从信用卡取款，货物的包装和 运送）都是异步进行的。当有些步骤完成时，你会收到一个email（异步）通知你。 如果任何地方出错，Amazon通常是用补偿（退款到你的信用卡），或重试 （重新发送遗失的物品）。

总之，我们可以看到现实世界通常都是异步的。我们的日常生活包含了许多相互协调、 却是异步的互动（阅读和回复email，在咖啡店买咖啡等）。这意味着异步消息架构可以 是一个来描述这些互动的自然模型。这也意味着我们可以通过观察日常生活来帮助我们 设计成功的消息传递解决方案。Domo arigat gozaimasu（多谢光临）！

译后注：

• 原文： http://www.eaipatterns.com/ramblings/18_starbucks.html
• 译文： http://www.softwarepractitioner.org/translations/hohpe/starbucks.shtml
• 2008年11月：译自原文。