星巴克不使用两阶段提交 - linzhiqi07的专栏 - 博客频道 - CSDN.NET



星巴克不使用两阶段提交 - linzhiqi07的专栏 - 博客频道 - CSDN.NET

Kudasai 的 "Hotto Cocoa"
我刚从日本旅行2周回来。 较为熟悉的景点之一是星巴克咖啡馆,特别是围绕 Shinjuku 和Roppongi。 在等待我的 "Hotto Cocoa",我开始思考星巴克是如何处理订单的。 星巴克象其他商业一样,追求订单量最大化。 更多的订单等于更多的收入。 因此,他们使用的异步处理。 当您下订单时,收银员在一咖啡杯上标上你的订单,并放入队列。 队列指的是咖啡机上一字排开咖啡杯的队列。 此队列将收银员和咖啡师分工,允许收银员持续不断下单,即使咖啡师离开片刻。 此模式在高峰时刻,即竞争消费者(competing consumer)场景,允许他们部署多个咖啡师的。

相关性(Correlation)
星巴克获得了异步方式带来的优势,也同样需要解决异步与生俱来带来的挑战。举个例子,相关性。 饮料订单不一定按他们下单的顺序完成。 可能发生这种情况的原因有两个。 首先,多个咖啡师可能使用不同的设备的处理订单。 相比滴漏式咖啡,混合咖啡饮料可能需要更长的时间。 其次,咖啡师可能批量制作多个饮料,以优化加工时间。 因此,星巴克有一个相关性的问题。 饮料送出的顺序需要匹配到正确的客户。 星巴克使用了我们在消息架构(messaging architectures)中使用的同一"模式"-相关性标识(Correlation Identifier)。 在美国,大多数星巴克店使用一个明确的相关性标识符:即在饮料杯上写你的名字,当饮料准备好时,呼唤你的名字。 在其他国家,只有与饮料类型相关。

异常处理 (Exception Handling)
在异步消息传递场景中的异常处理可能会很困难。 如果现实世界描述的是最好的故事,也许我们可以通过观察星巴克如何处理异常学到些东西。 
如果你不能支付他们将做些什么? 如果饮料已经制作好,他们会丢弃饮料,否则,从"队列"中抽出你的杯子。 
如果他们提供的饮料是不对或不能令人满意?
他们将重做。 
如果机器坏了?
他们不能制作饮料,他们将退还你的钱。 


这些情景都描述不同,但共同的错误处理策略:

    取消 - 这种错误处理策略是最简单的:什么也不做;或回退你已经完成的。 这似乎像一个坏的计划,但在现实的业务,此选项可能会被接受。 如果损失小,构建一个纠错解决方案可能会比取消昂贵的多。 例如,我曾在好几个ISP供应商工作,当计费出错/供应周期有问题时, 他们会选择这种方法时。 因此,客户可能最终得到服务,但不会得到帐单。 该收入损失小到足以允许业务以这种方式运作。 每隔一段时间,他们将执行和解报告检测到的"免费"的帐户,并关闭它们。
    重试 - 当一个较大的组(即"交易")的一些操作失败,我们基本上有两个选择:撤消已经完成的或重试失败的。 重试是一个似是而非的选项,如果有是一个可行的时机,重试最终会成功;但象违反业务规则的情况,它是不大可能重试成功的。 但是,如果是因为外部系统不可用,重试可能会获得成功。 一个特殊情况,是一个重试幂等接收(Idempotent Receiver)。 在这种情况下,我们可以简单地重试所有业务以来,成功的接收器将忽略重复的消息。
    补偿(Compensating)行动- 最后一个选项是撤消已经完成操作以便将系统推回到一致的状态。 这种"补偿行动"在诸如货币体系处理系统中工作的很好,因为我们可以将已经取出的钱重新存入帐户。 

所有这些策略都与两阶段提交不同,两阶段提交依赖于单独的编制和执行步骤。 在星巴克的例子,两阶段提交等同于拿着手中的收条和钱在柜台旁等待着收银员,直到饮料制作完成。 然后饮料将放入混合区域(Then, the drink would be added to the mix)。 最后钱,收据和饮料将一举被转手。 无论是收银员还是客户都不能够离开直到完成"交易"。 使用两阶段提交的方法肯定会将星巴克的业务毙了,因为在一定的时间间隔内,他们的客户数量将急剧下降。 这是一个很好的提醒,两阶段提交,可以使生活变得简单许多,但它也伤害了消息的自由流动(因此损害扩展性),因为它必须维护跨多个异步动作的交易资源的状态。


会话(Conversations)
咖啡店互动也是一个简单的且常见的对话模式的例子。 双方(客户和咖啡厅)之间的相互作用,包括一个简短的同步交互(订购和支付)和一个较长的,异步交互(制作和领取饮料)。 这种类型的谈话是相当普遍的购买场景。 例如,在亚马逊下订单时,短期的同步交互分配一个订单号码和异步完成所有的后续步骤(收费的信用卡,包装,运输)。 额外的步骤完成时,将通过电子邮件通知您(异步)。 如果有什么差错,亚马逊通常补偿(退还到信用卡)或重试(重发丢失的货物)。

综上所述,我们可以看到,现实世界往往是异步的。 我们的日常生活中,包括许多协调,但异步交互(阅读和回复电子邮件,购买咖啡等)。 这意味着异步消息架构往往可以以自然的方式来模拟这些类型的相互作用。 这也意味着,我们常常可以在日常生活中观察,以帮助设计成功的消息解决方案。


Read full article from 星巴克不使用两阶段提交 - linzhiqi07的专栏 - 博客频道 - CSDN.NET


No comments:

Post a Comment

Labels

Algorithm (219) Lucene (130) LeetCode (97) Database (36) Data Structure (33) text mining (28) Solr (27) java (27) Mathematical Algorithm (26) Difficult Algorithm (25) Logic Thinking (23) Puzzles (23) Bit Algorithms (22) Math (21) List (20) Dynamic Programming (19) Linux (19) Tree (18) Machine Learning (15) EPI (11) Queue (11) Smart Algorithm (11) Operating System (9) Java Basic (8) Recursive Algorithm (8) Stack (8) Eclipse (7) Scala (7) Tika (7) J2EE (6) Monitoring (6) Trie (6) Concurrency (5) Geometry Algorithm (5) Greedy Algorithm (5) Mahout (5) MySQL (5) xpost (5) C (4) Interview (4) Vi (4) regular expression (4) to-do (4) C++ (3) Chrome (3) Divide and Conquer (3) Graph Algorithm (3) Permutation (3) Powershell (3) Random (3) Segment Tree (3) UIMA (3) Union-Find (3) Video (3) Virtualization (3) Windows (3) XML (3) Advanced Data Structure (2) Android (2) Bash (2) Classic Algorithm (2) Debugging (2) Design Pattern (2) Google (2) Hadoop (2) Java Collections (2) Markov Chains (2) Probabilities (2) Shell (2) Site (2) Web Development (2) Workplace (2) angularjs (2) .Net (1) Amazon Interview (1) Android Studio (1) Array (1) Boilerpipe (1) Book Notes (1) ChromeOS (1) Chromebook (1) Codility (1) Desgin (1) Design (1) Divide and Conqure (1) GAE (1) Google Interview (1) Great Stuff (1) Hash (1) High Tech Companies (1) Improving (1) LifeTips (1) Maven (1) Network (1) Performance (1) Programming (1) Resources (1) Sampling (1) Sed (1) Smart Thinking (1) Sort (1) Spark (1) Stanford NLP (1) System Design (1) Trove (1) VIP (1) tools (1)

Popular Posts