当前位置:主页 > 资料 >

Life Beyond Distributed Transactions: An Apostate's
栏目分类:资料   发布日期:2018-08-02   浏览次数:

导读:本文为去找网小编(www.7zhao.net)为您推荐的Life Beyond Distributed Transactions: An Apostates Implementation - A Primer,希望对您有所帮助,谢谢! A Primer For those working with SQL databases, working with transactio

本文为去找网小编(www.7zhao.net)为您推荐的Life Beyond Distributed Transactions: An Apostate's Implementation - A Primer,希望对您有所帮助,谢谢! copyright www.7zhao.net



  • A Primer

For those working with SQL databases, working with transactions is more or less a given. The most we may need to worry about is: www.7zhao.net

  • Using the appropriate isolation level
  • Not doing too much in a single transaction to prevent excessive locks

The vast majority of applications I see can blissfully ignore the inner workings of transactions in database. We take for granted that our operations on one or more rows are either committed or rolled back.

去找(www.7zhao.net欢迎您

Things get more complicated when we start dealing with transactions no longer confined to a single resource, or in the case of many NoSQL databases, multiple entities. In many NoSQL databases, transactions are limited to a single entity/record. And if multi-entity transaction are supported, there are a number of limitations that might make that choice undesirable. 欢迎访问www.7zhao.net

When we have two non-transactional resources, we know we have a number of overall patterns to try to coordinate these actions (covered in my : www.7zhao.net

www.7zhao.net

All of these options assume "I must have these two actions temporally coupled" and have them happen at the same time.

去找(www.7zhao.net欢迎您

But what if that wasn't the case? What if we moved away from trying to coordinate two actions, and had more loose coupling between our resources? What might that look like? 去找(www.7zhao.net欢迎您

And that's the main scope of Pat Helland's paper, . In this paper, Pat describes a mechanism to overcome the fundamental issue of coordinating actions between resources when our transactions only cover a single entity - messaging! 内容来自www.7zhao.net

www.7zhao.net

We use some sort of messaging where our messages are saved inside the entities to direct to other entities:

欢迎访问www.7zhao.net

去找(www.7zhao.net欢迎您

Since the scope of a transaction is a single entity, if we need to affect other entities, we can't do that directly. Instead, we store the intent to affect change as a message inside our entity. The transaction covers our business data, and communication to the outside world. copyright www.7zhao.net

This certainly isn't the only way to tackle this problem, as I could use the as a means to manage failures between multi-entity activities. has a , but for my situation, I couldn't directly use the Saga pattern, since that implied there was some sort of logical "undo". Instead, I wanted to be able to any of the many coordination patterns available to me, including the Saga pattern. 欢迎访问www.7zhao.net

Before we get into implementation details, let's look at some real code in a real database that doesn't completely allow multi-entity transactions. copyright www.7zhao.net

Real World Example

Let's suppose I have an ecommerce application, where I can view products, add items to a cart, check out, then finally, approve orders. As part of approving an order, I need to decrement stock. We'll skip any complex business rules, like negative stock, reservations, and the like. Just to keep things simple, when we order, we just subtract the quantity order from our stock reserve: 本文来自去找www.7zhao.net

var orderRequest = await _orderRepository.GetItemAsync(id);

orderRequest.Approve();

await _orderRepository.UpdateItemAsync(orderRequest);

foreach (var lineItem in orderRequest.Items)  
{
    var stock = (await _stockRepository
        .GetItemsAsync(s => s.ProductId == lineItem.ProductId))
        .Single();

    stock.QuantityAvailable -= lineItem.Quantity;

    await _stockRepository.UpdateItemAsync(stock);
} 

www.7zhao.net

In my case, I'm using Azure Cosmos DB, which supports a variety of . Azure Cosmos DB also supports multi-document transactions, but only in the form of , and even then, only with some limitations. Once you introduce other resources into the mix, like Azure Service Bus, Azure SQL Database, or really anything outside a single partition key, we can no longer use transactions.

欢迎访问www.7zhao.net

With this in mind, we look back at our original code, and ask ourselves, "Do this action need to couple these resources, or can we decouple them?" There are certainly cases where we need to coordinate two actions (using a coordinator as we saw before), but there are many cases we don't, and don't want to incur the cost of a larger-scoped transaction.

www.7zhao.net

For our above case, do we need to deduct stock right at the time we approve an order? Or can it happen later? According to the business, deducting stock doesn't need to happen immediately, but it does need to happen, eventually. www.7zhao.net

In the next few posts, I'll walk through building out a mechanism for communication with other entities (and even other resources), to see how we might build out an atomic communication system with Azure Cosmos DB as our example. copyright www.7zhao.net

www.7zhao.net


本文原文地址:https://jimmybogard.com/life-beyond-transactions-implementation-primer/

以上为Life Beyond Distributed Transactions: An Apostate's Implementation - A Primer文章的全部内容,若您也有好的文章,欢迎与我们分享!

欢迎访问www.7zhao.net

Copyright ©2008-2017去找网版权所有   皖ICP备12002049号-2 皖公网安备 34088102000435号   关于我们|联系我们| 免责声明|友情链接|网站地图|手机版