Build distributed transactions using MassTransit, Routing Slips, and Automatonymous state machines using C# and .NET with RabbitMQ or Azure Service Bus
2. Chris Patterson
• Principal Architect, Fellow
RelayHealth Intelligence, a part of McKesson
• Microsoft MVP (C#, .NET)
• Open Source Enthusiast
3. Begin Conversation
• Deconstructing transactions into activities
• Orchestrating activities into a distributed transaction
• Tracking distributed transactions
4. Using Transactions For Good
• Atomic completion of operations
• Consistency maintained when systems fail
• Isolation from concurrent operations
• Durability when crashes occur
5. 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
8. 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
10. Topshelf
is an open source framework for creating and deploying .NET services.
11. 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
12. MassTransit
is 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.
14. 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 slip
is both obvious and intentional
15. Creating a Routing Slip
• Activities can be added to the
itinerary
• Variables may be added to the
routing slip
16. 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
17. 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
18. 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
19. Completing a Routing Slip
• The routing slip completes when every activity
has completed
21. 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
22. 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
23. Revising an Itinerary
• A completed activity may revise the itinerary
• A completed activity may terminate the routing
slip
24. 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
25. 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
26. Monitoring a Routing Slip
• A state machine observes routing slip events to
track the status of a routing slip
27. 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
28. 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
29. 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
31. 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
Hinweis der Redaktion
In the event of a system failure, a transaction can maintain data consistency by rolling back incomplete operations.
Supported by most databases, at least SQL ones. Distributed database make concessions in many areas.
Or, how I came to hate the MS-DTC.
Two separate services without a transaction coordinator results in reservations that are not paid.
While transactions are a feature of any ACID SQL database, scalability issues are frequently solved by relaxing consistency levels, which may increase concurrency and/or reduce contention.
We could create an activity as an RPC service that is called by an application or service.
We could create an activity as an RPC service that is called by an application or service.
This eliminates the need for a hub-and-spoke style where each activity executes and then returns to a central coordinator
Variables are the state of the routing slip.
There is nothing to compensate, so it’s over.
Convert a token stream and send to a search engine (elastic search)
Events include that tracking number
Executing, Completed, Faulted
ConversationId for transaction identifier
CorrelationId for routing slip identifier
Remember, all of the inputs required to complete the transaction are available at the start