package scaladsl
- Alphabetic
- Public
- Protected
Type Members
- trait ClusterSharding extends Extension
This extension provides sharding functionality of actors in a cluster.
This extension provides sharding functionality of actors in a cluster. The typical use case is when you have many stateful actors that together consume more resources (e.g. memory) than fit on one machine. You need to distribute them across several nodes in the cluster and you want to be able to interact with them using their logical identifier, but without having to care about their physical location in the cluster, which might also change over time. It could for example be actors representing Aggregate Roots in Domain-Driven Design terminology. Here we call these actors "entities". These actors typically have persistent (durable) state, but this feature is not limited to actors with persistent state.
In this context sharding means that actors with an identifier, so called entities, can be automatically distributed across multiple nodes in the cluster. Each entity actor runs only at one place, and messages can be sent to the entity without requiring the sender to know the location of the destination actor. This is achieved by sending the messages via a
ShardRegion
actor provided by this extension, which knows how to route the message with the entity id to the final destination.This extension is supposed to be used by first, typically at system startup on each node in the cluster, registering the supported entity types with the ClusterSharding#init method, which returns the
ShardRegion
actor reference for a named entity type. Messages to the entities are always sent via thatActorRef
, i.e. the localShardRegion
. Messages can also be sent via the EntityRef retrieved with ClusterSharding#entityRefFor, which will also send via the localShardRegion
.Some settings can be configured as described in the
akka.cluster.sharding
section of thereference.conf
.The
ShardRegion
actor is started on each node in the cluster, or group of nodes tagged with a specific role. TheShardRegion
is created with a ShardingMessageExtractor to extract the entity identifier and the shard identifier from incoming messages. A shard is a group of entities that will be managed together. For the first message in a specific shard theShardRegion
requests the location of the shard from a central coordinator, the akka.cluster.sharding.ShardCoordinator. TheShardCoordinator
decides whichShardRegion
owns the shard. TheShardRegion
receives the decided home of the shard and if that is theShardRegion
instance itself it will create a local child actor representing the entity and direct all messages for that entity to it. If the shard home is anotherShardRegion
instance messages will be forwarded to thatShardRegion
instance instead. While resolving the location of a shard incoming messages for that shard are buffered and later delivered when the shard location is known. Subsequent messages to the resolved shard can be delivered to the target destination immediately without involving theShardCoordinator
.To make sure that at most one instance of a specific entity actor is running somewhere in the cluster it is important that all nodes have the same view of where the shards are located. Therefore the shard allocation decisions are taken by the central
ShardCoordinator
, which is running as a cluster singleton, i.e. one instance on the oldest member among all cluster nodes or a group of nodes tagged with a specific role. The oldest member can be determined by akka.cluster.Member#isOlderThan.To be able to use newly added members in the cluster the coordinator facilitates rebalancing of shards, i.e. migrate entities from one node to another. In the rebalance process the coordinator first notifies all
ShardRegion
actors that a handoff for a shard has started. That means they will start buffering incoming messages for that shard, in the same way as if the shard location is unknown. During the rebalance process the coordinator will not answer any requests for the location of shards that are being rebalanced, i.e. local buffering will continue until the handoff is completed. TheShardRegion
responsible for the rebalanced shard will stop all entities in that shard by sending thehandOffMessage
to them. When all entities have been terminated theShardRegion
owning the entities will acknowledge the handoff as completed to the coordinator. Thereafter the coordinator will reply to requests for the location of the shard and thereby allocate a new home for the shard and then buffered messages in theShardRegion
actors are delivered to the new location. This means that the state of the entities are not transferred or migrated. If the state of the entities are of importance it should be persistent (durable), e.g. withakka-persistence
, so that it can be recovered at the new location.The logic that decides which shards to rebalance is defined in a plugable shard allocation strategy. The default implementation akka.cluster.sharding.ShardCoordinator.LeastShardAllocationStrategy picks shards for handoff from the
ShardRegion
with most number of previously allocated shards. They will then be allocated to theShardRegion
with least number of previously allocated shards, i.e. new members in the cluster. There is a configurable threshold of how large the difference must be to begin the rebalancing. This strategy can be replaced by an application specific implementation.The state of shard locations in the
ShardCoordinator
is stored withakka-distributed-data
orakka-persistence
to survive failures. When a crashed or unreachable coordinator node has been removed (via down) from the cluster a newShardCoordinator
singleton actor will take over and the state is recovered. During such a failure period shards with known location are still available, while messages for new (unknown) shards are buffered until the newShardCoordinator
becomes available.As long as a sender uses the same
ShardRegion
actor to deliver messages to an entity actor the order of the messages is preserved. As long as the buffer limit is not reached messages are delivered on a best effort basis, with at-most once delivery semantics, in the same way as ordinary message sending. Reliable end-to-end messaging, with at-least-once semantics can be added by usingAtLeastOnceDelivery
inakka-persistence
.Some additional latency is introduced for messages targeted to new or previously unused shards due to the round-trip to the coordinator. Rebalancing of shards may also add latency. This should be considered when designing the application specific shard resolution, e.g. to avoid too fine grained shards.
The
ShardRegion
actor can also be started in proxy only mode, i.e. it will not host any entities itself, but knows how to delegate messages to the right location.If the state of the entities are persistent you may stop entities that are not used to reduce memory consumption. This is done by the application specific implementation of the entity actors for example by defining receive timeout (
context.setReceiveTimeout
). If a message is already enqueued to the entity when it stops itself the enqueued message in the mailbox will be dropped. To support graceful passivation without losing such messages the entity actor can send ClusterSharding.Passivate to theActorRef[ShardCommand]
that was passed in to the factory method when creating the entity.. The specifiedstopMessage
message will be sent back to the entity, which is then supposed to stop itself. Incoming messages will be buffered by theShardRegion
between reception ofPassivate
and termination of the entity. Such buffered messages are thereafter delivered to a new incarnation of the entity.This class is not intended for user extension other than for test purposes (e.g. stub implementation). More methods may be added in the future and that may break such implementations.
- Annotations
- @DoNotInherit()
- final class ClusterShardingSetup extends ExtensionSetup[ClusterSharding]
Can be used in akka.actor.setup.ActorSystemSetup when starting the ActorSystem to replace the default implementation of the ClusterSharding extension.
Can be used in akka.actor.setup.ActorSystemSetup when starting the ActorSystem to replace the default implementation of the ClusterSharding extension. Intended for tests that need to replace extension with stub/mock implementations.
- final class Entity[M, E] extends AnyRef
Defines how the entity should be created.
Defines how the entity should be created. Used in ClusterSharding#init.
- final class EntityContext[M] extends AnyRef
Parameter to
createBehavior
function in Entity.apply.Parameter to
createBehavior
function in Entity.apply.Cluster Sharding is often used together with akka.persistence.typed.scaladsl.EventSourcedBehavior for the entities. See more considerations in akka.persistence.typed.PersistenceId. The
PersistenceId
of theEventSourcedBehavior
can typically be constructed with:PersistenceId(entityContext.entityTypeKey.name, entityContext.entityId)
- trait EntityRef[-M] extends RecipientRef[M]
A reference to an sharded Entity, which allows
ActorRef
-like usage.A reference to an sharded Entity, which allows
ActorRef
-like usage.An EntityRef is NOT an ActorRef–by design–in order to be explicit about the fact that the life-cycle of a sharded Entity is very different than a plain Actors. Most notably, this is shown by features of Entities such as re-balancing (an active Entity to a different node) or passivation. Both of which are aimed to be completely transparent to users of such Entity. In other words, if this were to be a plain ActorRef, it would be possible to apply DeathWatch to it, which in turn would then trigger when the sharded Actor stopped, breaking the illusion that Entity refs are "always there". Please note that while not encouraged, it is possible to expose an Actor's
self
ActorRef and watch it in case such notification is desired. Not for user extension.- Annotations
- @DoNotInherit()
- trait EntityTypeKey[-T] extends AnyRef
The key of an entity type, the
name
must be unique.The key of an entity type, the
name
must be unique.Not for user extension.
- Annotations
- @DoNotInherit()
- trait ShardedDaemonProcess extends Extension
This extension runs a pre set number of actors in a cluster.
This extension runs a pre set number of actors in a cluster.
The typical use case is when you have a task that can be divided in a number of workers, each doing a sharded part of the work, for example consuming the read side events from Akka Persistence through tagged events where each tag decides which consumer that should consume the event.
Each named set needs to be started on all the nodes of the cluster on start up.
The processes are spread out across the cluster, when the cluster topology changes the processes may be stopped and started anew on a new node to rebalance them.
Not for user extension.
- Annotations
- @DoNotInherit()
Value Members
- object ClusterSharding extends ExtensionId[ClusterSharding]
- object ClusterShardingSetup
- object Entity
- object EntityTypeKey
- object ShardedDaemonProcess extends ExtensionId[ShardedDaemonProcess]
- object StartEntity
Allows starting a specific Sharded Entity by its entity identifier