Upload
chris-patterson
View
494
Download
2
Embed Size (px)
Citation preview
Distributing TransactionsChris PattersonFellowMcKesson
Chris Patterson
• Principal Architect, FellowRelayHealth Intelligence, a part of McKesson• Microsoft MVP (C#, .NET)• Open Source Enthusiast
Begin Conversation
• Deconstructing transactions into activities• Orchestrating activities into a distributed transaction• Tracking distributed transactions
Using Transactions For Good
• Atomic completion of operations• Consistency maintained when systems fail• Isolation from concurrent operations• Durability when crashes occur
Taking Transactions Too Far
• Combining two separate transactions using a distributed transaction coordinator• Calling high latency services during a transaction• Using triggers inside a transaction
Creating Inconsistency
Reserve Seat
Process Payment
Reservation Web Site
Deconstructing a Transaction
• A transaction is a sequence of activities that complete entirely, or not at all
Defining an Activity
• An activity should have a single responsibility• An activity may have explicit input arguments• An activity may produce output variables• An activity may update an activity log
Creating an Activity
• An activity should be an autonomous service
Topshelfis an open source framework for creating and deploying .NET services.
Creating an Activity
• An activity should be an autonomous service• An activity should use asynchronous endpoints for availability• An activity should use durable messaging for reliability• An activity should be load balanced for scalability
MassTransitis a free, open-source distributed application framework for .NET. MassTransit makes it easy to create applications and services which leverage message-based, loosely-coupled asynchronous communication for higher availability, reliability, and scalability.
Creating an Itinerary
• An itinerary is a list of activities to be executed
Executing an Itinerary
• An itinerary is executed using a routing slip• A routing slip is a workspace for a distributed transaction
The analogy to a paper routing slipis both obvious and intentional
Creating a Routing Slip
• Activities can be added to the itinerary• Variables may be added to the routing slip
Executing a Routing Slip
• A routing slip is sent to the execute address of the first activity• A routing slip with an empty itinerary completes immediately
Executing an Activity
• An activity is executed using the arguments from the itinerary• An activity’s arguments may be read from the routing slip variables
Completing an Activity
• A completed activity sends the routing slip to the next activity in the itinerary• A completed activity may add or update variables in the routing slip• A completed activity may add an activity log to the routing slip
Completing a Routing Slip
• The routing slip completes when every activity has completed
Publishing Events
Faulting an Activity
• A faulted activity sends the routing slip to the compensate address of the last activity log• A routing slip with no activity log entries faults immediately
Compensating an Activity
• A previously completed activity is compensated using the activity log from the routing slip• A previously completed activity that faults during compensation fails the routing slip
Revising an Itinerary
• A completed activity may revise the itinerary• A completed activity may terminate the routing slip
Tracking a Routing Slip• A routing slip has a unique identifier• An event is published when a routing slip is completed, faulted, or when a routing slip compensation fails• An event is published when a routing slip itinerary is revised• An event is published when a routing slip is terminated
Tracking an Activity
• An activity execution has a unique identifier• An event is published when an activity is completed, faulted, compensated, or when an activity compensation fails
Monitoring a Routing Slip
• A state machine observes routing slip events to track the status of a routing slip
Monitoring a Distributed Transaction
• A state machine maintains separate instances for each transaction• A state machine monitors transaction creation events• A state machine monitors routing slip events to determine when a transaction is completed or faulted
Identifying a Distributed Transaction
• A transaction has a unique identifier• A routing slip event includes the transaction identifier• A transaction event includes the transaction identifier
Retrying Faulted Transactions
• A retry state machine observes transaction fault events• A retry state machine can coordinate additional transaction attempts• A retry state machine may use a retry policy to determine a retry schedule for any additional transaction attempts
Learning Resources
MassTransit• Main Project Site
http://masstransit-project.com
• Documentation Site http://docs.masstransit-project.com
• Source Browser http://source.masstransit-project.com
• GitHub Repository https://github.com/MassTransit
• Build Server https://ci.appveyor.com/project/phatboyg/masstransit