- All Implemented Interfaces:
public class ClusterSharding$ extends java.lang.Object implements ExtensionId<ClusterSharding>, ExtensionIdProviderThis 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. - Distribution: You need to distribute them across several nodes in the cluster - Location Transparency: You need to interact with them using their logical identifier, without having to care about their physical location in the cluster, which can change over time.
'''Entities''': It could for example be actors representing Aggregate Roots in Domain-Driven Design terminology. Here we call these actors "entities" which typically have persistent (durable) state, but this feature is not limited to persistent state actors.
'''Sharding''': In this context sharding means that actors with an identifier, or entities, can be automatically distributed across multiple nodes in the cluster.
'''ShardRegion''': 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
ShardRegionactor, provided by this extension. The
ShardRegionknows the shard mappings and routes inbound messages to the entity with the entity id. Messages to the entities are always sent via the local
ShardRegionactor is started on each node in the cluster, or group of nodes tagged with a specific role. The
ShardRegionis created with two application specific functions to extract the entity identifier and the shard identifier from incoming messages.
Typical usage of this extension: 1. At system startup on each cluster node by registering the supported entity types with the
ClusterSharding.start(java.lang.String, akka.actor.Props, akka.cluster.sharding.ClusterShardingSettings, scala.PartialFunction<java.lang.Object, scala.Tuple2<java.lang.String, java.lang.Object>>, scala.Function1<java.lang.Object, java.lang.String>, akka.cluster.sharding.ShardCoordinator.ShardAllocationStrategy, java.lang.Object)method 1. Retrieve the
ShardRegionactor for a named entity type with
ClusterSharding.shardRegion(java.lang.String)Settings can be configured as described in the
akka.cluster.shardingsection of the
'''Shard and ShardCoordinator''': A shard is a group of entities that will be managed together. For the first message in a specific shard the
ShardRegionrequests the location of the shard from a central
ShardRegionowns the shard. The
ShardRegionreceives the decided home of the shard and if that is the
ShardRegioninstance 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 another
ShardRegion, instance messages will be forwarded to that
ShardRegioninstance 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 the
ShardCoordinator. To make sure 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, 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
'''Shard Rebalancing''': To be able to use newly added members in the cluster the coordinator facilitates rebalancing of shards, migrating entities from one node to another. In the rebalance process the coordinator first notifies all
ShardRegionactors that a handoff for a shard has begun.
ShardRegionactors will start buffering incoming messages for that shard, as they do when 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 complete. The
ShardRegionresponsible for the rebalanced shard will stop all entities in that shard by sending them a
PoisonPill. When all entities have been terminated the
ShardRegionowning the entities will acknowledge to the coordinator that the handoff has completed. Thereafter the coordinator will reply to requests for the location of the shard, allocate a new home for the shard and then buffered messages in the
ShardRegionactors 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. with
akka-persistenceso that it can be recovered at the new location.
'''Shard Allocation''': The logic deciding which shards to rebalance is defined in a plugable shard allocation strategy. The default implementation
ShardCoordinator.LeastShardAllocationStrategypicks shards for handoff from the
ShardRegionwith highest number of previously allocated shards. They will then be allocated to the
ShardRegionwith lowest number of previously allocated shards, i.e. new members in the cluster. There is a configurable
rebalance-thresholdof how large the difference must be to begin the rebalancing. This strategy can be replaced by an application specific implementation.
'''Recovery''': The state of shard locations in the
ShardCoordinatoris stored with
akka-persistenceto survive failures. When a crashed or unreachable coordinator node has been removed (via down) from the cluster a new
ShardCoordinatorsingleton 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 new
'''Delivery Semantics''': As long as a sender uses the same
ShardRegionactor 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 using
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.
ShardRegionactor 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
ShardRegion.Passivateto its parent
ShardRegion. The specified wrapped message in
Passivatewill be sent back to the entity, which is then supposed to stop itself. Incoming messages will be buffered by the
ShardRegionbetween reception of
Passivateand termination of the entity. Such buffered messages are thereafter delivered to a new incarnation of the entity.
Fields Modifier and Type Field Description
MODULE$Static reference to the singleton instance of this Scala object.
Constructors Constructor Description
All Methods Instance Methods Concrete Methods Modifier and Type Method Description
createExtension(ExtendedActorSystem system)Is used by Akka to instantiate the Extension identified by this ExtensionId, internal use only.
get(ActorSystem system)Returns an instance of the extension identified by this ExtensionId instance.
get(ClassicActorSystemProvider system)Returns an instance of the extension identified by this ExtensionId instance.
lookup()Returns the canonical ExtensionId for this Extension
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Methods inherited from interface akka.actor.ExtensionId
apply, apply, equals, hashCode
public static final ClusterSharding$ MODULE$Static reference to the singleton instance of this Scala object.
public ClusterSharding get(ActorSystem system)Returns an instance of the extension identified by this ExtensionId instance. Java API For extensions written in Scala that are to be used from Java also, this method should be overridden to get correct return type.
override def get(system: ActorSystem): TheExtension = super.get(system)
- Specified by:
public ClusterSharding get(ClassicActorSystemProvider system)Returns an instance of the extension identified by this ExtensionId instance. Java API For extensions written in Scala that are to be used from Java also, this method should be overridden to get correct return type.
override def get(system: ClassicActorSystemProvider): TheExtension = super.get(system)
- Specified by:
public ClusterSharding$ lookup()Description copied from interface:
ExtensionIdProviderReturns the canonical ExtensionId for this Extension
- Specified by:
public ClusterSharding createExtension(ExtendedActorSystem system)Is used by Akka to instantiate the Extension identified by this ExtensionId, internal use only.
- Specified by: