Distributing Transactions using MassTransit
•Download as PPTX, PDF•
6 likes•2,082 views
Build distributed transactions using MassTransit, Routing Slips, and Automatonymous state machines using C# and .NET with RabbitMQ or Azure Service Bus
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to Distributing Transactions using MassTransit
Similar to Distributing Transactions using MassTransit (20)
Recently uploaded
Recently uploaded (20)
Distributing Transactions using MassTransit
- 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
- 7. Deconstructing a Transaction • A transaction is a sequence of activities that complete entirely, or not at all
- 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
- 9. Creating an Activity • An activity should be an autonomous service
- 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.
- 13. Creating an Itinerary • An itinerary is a list of activities to be executed
- 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
- 20. Publishing Events Activity RoutingSlip Activity Faulted RoutingSlip Activity Completed RoutingSlip Execute Activity throw Exception Next Activity Endpoint If More Activities Completed RoutingSlip Completed If Last Activity
- 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
Editor's Notes
- 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