If the state is residing where the actual service is running
then that service is called a Stateful service.
In a distributed environment having efficient and reliable state management system is a challenge,
In a distributed environment having efficient and reliable state management system is a challenge,
According to CAP (Consistency Availability and Partition Tolerance)
Theorem States that in a distributed System it is impossible to provide more
than two guarantees of the three
- Consistency – Every read gets the latest write
- Availability – Every request receives a non-error response without the guarantee that it is latest write '
- Partition Tolerance – System continues to work despite the unavailability of certain nodes (Network outage, down due to maintenance).
But this does not mean you cannot achieve good level of Consistency
and Availability.
Let’s see how Service fabric state management system helps us
get the maximum out of the two.
The Architecture and the important components associated with
the Stateful Services in service fabric is below
·
As we know by now ICommunicationListener is
designed to take request from the clients.
·
IStatefulUserServiceReplica
has the implementation in StatefulService and the Service fabric runtime
manages the lifecycle of Stateful Microservice through StatefulService.
·
The IReliableStateManager
implementation gives you the State Manager using which you can handle all the
actions related to State Providers (Reliable Collection).
·
The IReliableCollection
implementation gives you the state providers which are used to save the states,
currently there are 3 types of Reliable Collections(Reliable Dictionary ,
Reliable Queue , Reliable Concurrent Queue) , the Reliable collection implementation
is Replicated , Persisted , Asynchronous and Transactional in nature (More on this Later )
·
Transactional Replicator is responsible for replicating
the state providers(reliable collections) to the secondary replica’s this step
makes sure that the state data is reliable consistent and highly reliable and
once the replication is complete it
calls into Logger
·
Logger is responsible to save the state changes on
to the local disk using append only log files. This helps the states to be restored
when a node crashes using the log files.
o
There are two types of logs
§
Shared Logs: They are saved under node level
working directory for saving Transactional data.
§
Dedicated logs: They are replica-level logs
saved under the service working directory.
The state information first is saved to the
shared log and then is lazily transferred to dedicated logs in the background
