http://arthurchiao.art/blog/starbucks-do-not-use-two-phase-commit-zh/
本文翻译自 2004 年的一篇文章: Starbucks Does Not Use Two-Phase Commit.
由于译者水平有限，本文不免存在遗漏或错误之处。如有疑问，请查阅原文。
以下是译文。
刚结束了一次为期两周的日本之旅。印象深刻的是数量多到难以置信的星巴克 —— 尤其是在 新宿和六本木地区。在等待咖啡制作时，我开始思考星巴克是如何处理订单的。
与大多数商业公司一样，星巴克主要关心的也是订单最大化。更多的订单就意味着更 多的收入。因此，他们采用异步的方式处理订单：
在这种方式中，如果咖啡师真的忙不过来了，可以再加几个咖啡师，这就是所谓的 Competing Consumer 场景。
享受异步带来的好处的同时，星巴克也需要解决异步方式内在的挑战。例如，关联（correlation）问题。
咖啡制作完成的顺序不一定与下单的顺序一致。这有两个可能的原因：
因此，星巴克会面临咖啡与顾客之间的关联问题。咖啡制作完成的顺序是不确定的，需 要将每一杯咖啡分别对应到正确的顾客。星巴克解决这个问题的方式与我们在消息系统 中所使用的“模式”（pattern）是一样的：使用某种关联 ID（Correlation Identifier）。
异步消息系统中的异常处理是很困难的。如果说现实世界中已经很好的解决了这个问题，那 我们可以通过观察星巴克如何处理异常学到一些东西。
这些场景分别描述了几种常见的错误处理策略。
这是所有错误处理策略中最简单的：什么都不用做。或者是，丢弃已经做的所有东西。
听起来似乎不靠谱，但实际业务中，有时这种方式是可接受的。如果销账带来的损失很小， 那相比斥巨资实现一种复杂的错误处理机制，销账的方式还是更划算的。
例如，我曾为多家因特网服务提供商（ISP）工作，在他们的业务中，如果计费（billing / provisioning cycle）发生错误，它们就会选择销账的方式。其导致的结果是，客户可能会 享受了某些服务，但没有被收费。
这种处理方式给他们带来的营业损失足够小，因此业务能够保持运营。另外，公司会定期地 对账（reconciliation），主动检测这些“免费”账户并将其关闭。
当一大组操作（例如，一次事务）中的某些操作失败时，我们基本有两种选择：
如果重试有较大的概率能成功，那就可以考虑重试方式。例如，
这里有一种特殊的重试：幂等接收器 重试（retry with Idempotent Receiver）。在这种场景中，我们可以简单地重试所有操 作，因为接收器成功之后便会忽略重复的消息。
最后一种方式是回退所有已完成的操作（undo operations that were already completed）， 让系统回到一致的状态。
例如，在金融系统中，这些“补偿动作”能在交易失败时对已扣款进行退款处理。
以上所有策略都与两阶段提交不同。两阶段提交包含前后两个步骤：
如果在星巴克中使用两阶段提交，那买一杯咖啡的过程将变为：
在“事务”（transaction）完成之前，收银员和顾客都不能离开。
显然，如果使用这种提交方式，星巴克的业务量将急剧下降，因为相同时间内能服务的 顾客数量将锐减。
这个例子也提醒我们，两阶段提交会让生活变得加更简单（因为错误处理非常简单），但它 也会妨碍消息的自由流动（以及自由流动带来的可扩展性），因为它必须将多个异步操作 封装成一个有状态事务。
咖啡店交互的过程其实也是一个简单但很常见的 Conversation 模式的例子。
双方（顾客和咖啡店）之间由两次交互组成：
这种类型的会话（conversation）在电商场景中是非常普遍的。例如，在 Amazon 买东 西时，时间较短的异步交互过程会分配订单号，而所有的后续步骤（信用卡扣款、打包、配 送）都是异步完成的。这些额外的异步步骤完成后，你会收到邮件方式（异步）的通 知。如果中间发生任何差错，Amazon 通常会
可以看到，真实世界往往都是异步的。我们的日常生活是由许多协调但异步的（ coordinated, but asynchronous）过程组成的，例如读取和回复电子邮件，购买咖啡等等 。这意味着，异步消息模型（asynchronous messaging architecture）通常能很自然地对 这些类型的交互进行建模。
此外，这还意味着，经常观察日常生活有助于设计出成功的消息系统（ messaging solutions）。
感谢阅读！