final class Replicator extends Actor with ActorLogging

A replicated in-memory data store supporting low latency and high availability requirements.

The Replicator actor takes care of direct replication and gossip based dissemination of Conflict Free Replicated Data Types (CRDTs) to replicas in the the cluster. The data types must be convergent CRDTs and implement ReplicatedData, i.e. they provide a monotonic merge function and the state changes always converge.

You can use your own custom ReplicatedData or DeltaReplicatedData types, and several types are provided by this package, such as:

For good introduction to the CRDT subject watch the Eventually Consistent Data Structures talk by Sean Cribbs and and the talk by Mark Shapiro and read the excellent paper A comprehensive study of Convergent and Commutative Replicated Data Types by Mark Shapiro et. al.

The Replicator actor must be started on each node in the cluster, or group of nodes tagged with a specific role. It communicates with other Replicator instances with the same path (without address) that are running on other nodes . For convenience it can be used with the DistributedData extension but it can also be started as an ordinary actor using the Replicator.props. If it is started as an ordinary actor it is important that it is given the same name, started on same path, on all nodes.

Delta State Replicated Data Types are supported. delta-CRDT is a way to reduce the need for sending the full state for updates. For example adding element 'c' and 'd' to set {'a', 'b'} would result in sending the delta {'c', 'd'} and merge that with the state on the receiving side, resulting in set {'a', 'b', 'c', 'd'}.

The protocol for replicating the deltas supports causal consistency if the data type is marked with RequiresCausalDeliveryOfDeltas. Otherwise it is only eventually consistent. Without causal consistency it means that if elements 'c' and 'd' are added in two separate Update operations these deltas may occasionally be propagated to nodes in different order than the causal order of the updates. For this example it can result in that set {'a', 'b', 'd'} can be seen before element 'c' is seen. Eventually it will be {'a', 'b', 'c', 'd'}.

Update

To modify and replicate a ReplicatedData value you send a Replicator.Update message to the local Replicator. The current data value for the key of the Update is passed as parameter to the modify function of the Update. The function is supposed to return the new value of the data, which will then be replicated according to the given consistency level.

The modify function is called by the Replicator actor and must therefore be a pure function that only uses the data parameter and stable fields from enclosing scope. It must for example not access sender() reference of an enclosing actor.

Update is intended to only be sent from an actor running in same local ActorSystem as the Replicator, because the modify function is typically not serializable.

You supply a write consistency level which has the following meaning:

  • WriteLocal the value will immediately only be written to the local replica, and later disseminated with gossip
  • WriteTo(n) the value will immediately be written to at least n replicas, including the local replica
  • WriteMajority the value will immediately be written to a majority of replicas, i.e. at least N/2 + 1 replicas, where N is the number of nodes in the cluster (or cluster role group)
  • WriteAll the value will immediately be written to all nodes in the cluster (or all nodes in the cluster role group)

As reply of the Update a Replicator.UpdateSuccess is sent to the sender of the Update if the value was successfully replicated according to the supplied consistency level within the supplied timeout. Otherwise a Replicator.UpdateFailure subclass is sent back. Note that a Replicator.UpdateTimeout reply does not mean that the update completely failed or was rolled back. It may still have been replicated to some nodes, and will eventually be replicated to all nodes with the gossip protocol.

You will always see your own writes. For example if you send two Update messages changing the value of the same key, the modify function of the second message will see the change that was performed by the first Update message.

In the Update message you can pass an optional request context, which the Replicator does not care about, but is included in the reply messages. This is a convenient way to pass contextual information (e.g. original sender) without having to use ask or local correlation data structures.

Get

To retrieve the current value of a data you send Replicator.Get message to the Replicator. You supply a consistency level which has the following meaning:

  • ReadLocal the value will only be read from the local replica
  • ReadFrom(n) the value will be read and merged from n replicas, including the local replica
  • ReadMajority the value will be read and merged from a majority of replicas, i.e. at least N/2 + 1 replicas, where N is the number of nodes in the cluster (or cluster role group)
  • ReadAll the value will be read and merged from all nodes in the cluster (or all nodes in the cluster role group)

As reply of the Get a Replicator.GetSuccess is sent to the sender of the Get if the value was successfully retrieved according to the supplied consistency level within the supplied timeout. Otherwise a Replicator.GetFailure is sent. If the key does not exist the reply will be Replicator.NotFound.

You will always read your own writes. For example if you send a Update message followed by a Get of the same key the Get will retrieve the change that was performed by the preceding Update message. However, the order of the reply messages are not defined, i.e. in the previous example you may receive the GetSuccess before the UpdateSuccess.

In the Get message you can pass an optional request context in the same way as for the Update message, described above. For example the original sender can be passed and replied to after receiving and transforming GetSuccess.

Subscribe

You may also register interest in change notifications by sending Replicator.Subscribe message to the Replicator. It will send Replicator.Changed messages to the registered subscriber when the data for the subscribed key is updated. Subscribers will be notified periodically with the configured notify-subscribers-interval, and it is also possible to send an explicit Replicator.FlushChanges message to the Replicator to notify the subscribers immediately.

The subscriber is automatically removed if the subscriber is terminated. A subscriber can also be deregistered with the Replicator.Unsubscribe message.

Delete

A data entry can be deleted by sending a Replicator.Delete message to the local local Replicator. As reply of the Delete a Replicator.DeleteSuccess is sent to the sender of the Delete if the value was successfully deleted according to the supplied consistency level within the supplied timeout. Otherwise a Replicator.ReplicationDeleteFailure is sent. Note that ReplicationDeleteFailure does not mean that the delete completely failed or was rolled back. It may still have been replicated to some nodes, and may eventually be replicated to all nodes.

A deleted key cannot be reused again, but it is still recommended to delete unused data entries because that reduces the replication overhead when new nodes join the cluster. Subsequent Delete, Update and Get requests will be replied with Replicator.DataDeleted, Replicator.UpdateDataDeleted and Replicator.GetDataDeleted respectively. Subscribers will receive Replicator.Deleted.

In the Delete message you can pass an optional request context in the same way as for the Update message, described above. For example the original sender can be passed and replied to after receiving and transforming DeleteSuccess.

CRDT Garbage

One thing that can be problematic with CRDTs is that some data types accumulate history (garbage). For example a GCounter keeps track of one counter per node. If a GCounter has been updated from one node it will associate the identifier of that node forever. That can become a problem for long running systems with many cluster nodes being added and removed. To solve this problem the Replicator performs pruning of data associated with nodes that have been removed from the cluster. Data types that need pruning have to implement RemovedNodePruning. The pruning consists of several steps:

  • When a node is removed from the cluster it is first important that all updates that were done by that node are disseminated to all other nodes. The pruning will not start before the maxPruningDissemination duration has elapsed. The time measurement is stopped when any replica is unreachable, but it's still recommended to configure this with certain margin. It should be in the magnitude of minutes.
  • The nodes are ordered by their address and the node ordered first is called leader. The leader initiates the pruning by adding a PruningInitialized marker in the data envelope. This is gossiped to all other nodes and they mark it as seen when they receive it.
  • When the leader sees that all other nodes have seen the PruningInitialized marker the leader performs the pruning and changes the marker to PruningPerformed so that nobody else will redo the pruning. The data envelope with this pruning state is a CRDT itself. The pruning is typically performed by "moving" the part of the data associated with the removed node to the leader node. For example, a GCounter is a Map with the node as key and the counts done by that node as value. When pruning the value of the removed node is moved to the entry owned by the leader node. See RemovedNodePruning#prune.
  • Thereafter the data is always cleared from parts associated with the removed node so that it does not come back when merging. See RemovedNodePruning#pruningCleanup
  • After another maxPruningDissemination duration after pruning the last entry from the removed node the PruningPerformed markers in the data envelope are collapsed into a single tombstone entry, for efficiency. Clients may continue to use old data and therefore all data are always cleared from parts associated with tombstoned nodes.
Source
Replicator.scala
Linear Supertypes
ActorLogging, Actor, AnyRef, Any
Type Hierarchy
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. Replicator
  2. ActorLogging
  3. Actor
  4. AnyRef
  5. Any
Implicitly
  1. by any2stringadd
  2. by StringFormat
  3. by Ensuring
  4. by ArrowAssoc
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. Protected

Instance Constructors

  1. new Replicator(settings: ReplicatorSettings)

Type Members

  1. type Receive = [, Unit]
    Definition Classes
    Actor

Value Members

  1. var allReachableClockTime: Long
  2. var changed: [KeyId]
  3. val clockTask: Cancellable
  4. val cluster: Cluster
  5. def collectRemovedNodes(): Unit
  6. implicit val context: ActorContext

    Scala API: Stores the context for this actor, including self, and sender.

    Scala API: Stores the context for this actor, including self, and sender. It is implicit to support operations such as forward.

    WARNING: Only valid within the Actor itself, so do not close over it and publish it to other threads!

    akka.actor.ActorContext is the Scala API. getContext returns a akka.actor.AbstractActor.ActorContext, which is the Java API of the actor context.

    Definition Classes
    Actor
  7. var dataEntries: [KeyId, (DataEnvelope, Digest, Timestamp)]
  8. def deleteObsoletePruningPerformed(): Unit
  9. val deltaPropagationSelector: DeltaPropagationSelector { val gossipIntervalDivisor: Int }
  10. val deltaPropagationTask: [Cancellable]
  11. def digest(envelope: DataEnvelope): (Digest, Int)

    returns

    SHA-1 digest of the serialized data, and the size of the serialized data

  12. val durable: [KeyId]
  13. val durableStore: ActorRef
  14. val durableWildcards: [KeyId]
  15. var exitingNodes: [UniqueAddress]
  16. val expiryEnabled: Boolean
  17. val expiryWildcards: [, FiniteDuration]
  18. var fullStateGossipEnabled: Boolean
  19. def getData(key: KeyId): Option[DataEnvelope]
  20. def getDeltaSeqNr(key: KeyId, fromNode: UniqueAddress): Long
  21. def getDigest(key: KeyId): Digest
  22. def getExpiryDuration(key: KeyId): FiniteDuration
  23. def getUsedTimestamp(key: KeyId): Timestamp
  24. val gossipTask: Cancellable
  25. def gossipTo(address: UniqueAddress): Unit
  26. val hasDurableKeys: Boolean
  27. def hasSubscriber(subscriber: ActorRef): Boolean
  28. def initRemovedNodePruning(): Unit
  29. def isDurable(key: KeyId): Boolean
  30. def isExpired(key: KeyId, timestamp: Timestamp): Boolean
  31. def isExpired(key: KeyId): Boolean
  32. def isLeader: Boolean
  33. def isLocalGet(readConsistency: ReadConsistency): Boolean
  34. def isLocalSender(): Boolean
  35. def isLocalUpdate(writeConsistency: WriteConsistency): Boolean
  36. def isNodeRemoved(node: UniqueAddress, keys: Iterable[KeyId]): Boolean
  37. var joiningNodes: [UniqueAddress]
  38. var leader: [Member]
  39. val load: Receive
  40. def log: LoggingAdapter
    Definition Classes
    ActorLogging
  41. def matchingRole(m: Member): Boolean
  42. val maxPruningDisseminationNanos: Long
  43. var membersByAge: [Member]
  44. val newSubscribers: [, []] with [, ActorRef]
  45. var nodes: [UniqueAddress]
  46. val normalReceive: Receive
  47. val notifyTask: Cancellable
  48. def performRemovedNodePruning(): Unit
  49. def postRestart(reason: Throwable): Unit

    User overridable callback: By default it calls preStart().

    User overridable callback: By default it calls preStart().

    reason

    the Throwable that caused the restart to happen Is called right AFTER restart on the newly created Actor to allow reinitialization after an Actor crash.

    Definition Classes
    Actor
    Annotations
    @throws(classOf[Exception])
  50. def postStop(): Unit

    User overridable callback.

    User overridable callback.

    Is called asynchronously after 'actor.stop()' is invoked. Empty default implementation.

    Definition Classes
    → Actor
  51. def preRestart(reason: Throwable, message: [Any]): Unit

    Scala API: User overridable callback: By default it disposes of all children and then calls postStop().

    Scala API: User overridable callback: By default it disposes of all children and then calls postStop().

    reason

    the Throwable that caused the restart to happen

    message

    optionally the current message the actor processed when failing, if applicable Is called on a crashed Actor right BEFORE it is restarted to allow clean up of resources before Actor is terminated.

    Definition Classes
    Actor
    Annotations
    @throws(classOf[Exception])
  52. def preStart(): Unit

    User overridable callback.

    User overridable callback.

    Is called when an Actor is started. Actors are automatically started asynchronously when created. Empty default implementation.

    Definition Classes
    → Actor
  53. var previousClockTime: Long
  54. val pruningTask: [Cancellable]
  55. def receive: actor.Actor.Receive

    Scala API: This defines the initial actor behavior, it must return a partial function with the actor logic.

    Scala API: This defines the initial actor behavior, it must return a partial function with the actor logic.

    Definition Classes
    → Actor
  56. def receiveClockTick(): Unit
  57. def receiveDelete(key: KeyR, consistency: WriteConsistency, req: [Any]): Unit
  58. def receiveDeltaPropagation(fromNode: UniqueAddress, reply: Boolean, deltas: Map[KeyId, Delta]): Unit
  59. def receiveDeltaPropagationTick(): Unit
  60. def receiveFlushChanges(): Unit
  61. def receiveGet(key: KeyR, consistency: ReadConsistency, req: [Any]): Unit
  62. def receiveGetKeyIds(): Unit
  63. def receiveGetReplicaCount(): Unit
  64. def receiveGossip(updatedData: Map[KeyId, (DataEnvelope, Timestamp)], sendBack: Boolean, fromSystemUid: [Long]): Unit
  65. def receiveGossipTick(): Unit
  66. def receiveMemberExiting(m: Member): Unit
  67. def receiveMemberJoining(m: Member): Unit
  68. def receiveMemberRemoved(m: Member): Unit
  69. def receiveMemberUp(m: Member): Unit
  70. def receiveMemberWeaklyUp(m: Member): Unit
  71. def receiveOtherMemberEvent(m: Member): Unit
  72. def receiveReachable(m: Member): Unit
  73. def receiveRead(key: KeyId): Unit
  74. def receiveReadRepair(key: KeyId, writeEnvelope: DataEnvelope): Unit
  75. def receiveRemovedNodePruningTick(): Unit
  76. def receiveStatus(otherDigests: Map[KeyId, (Digest, Timestamp)], chunk: Int, totChunks: Int, fromSystemUid: [Long]): Unit
  77. def receiveSubscribe(key: KeyR, subscriber: ActorRef): Unit
  78. def receiveTerminated(ref: ActorRef): Unit
  79. def receiveUnreachable(m: Member): Unit
  80. def receiveUnsubscribe(key: KeyR, subscriber: ActorRef): Unit
  81. def receiveUpdate[A <: ReplicatedData](key: KeyR, modify: (Option[A]) => A, writeConsistency: WriteConsistency, req: [Any]): Unit
  82. def receiveWrite(key: KeyId, envelope: DataEnvelope): Unit
  83. var removedNodes: Map[, Long]
  84. def replica(node: UniqueAddress): ActorSelection
  85. var replyTo: ActorRef
  86. def selectRandomNode(addresses: [UniqueAddress]): [UniqueAddress]
  87. implicit final val self: ActorRef

    The 'self' field holds the ActorRef for this actor.

    The 'self' field holds the ActorRef for this actor.

    Can be used to send messages to itself: 

    self ! message

    Definition Classes
    Actor
  88. val selfAddress: Address
  89. val selfFromSystemUid: [Long]
  90. val selfUniqueAddress: UniqueAddress
  91. final def sender(): ActorRef

    The reference sender Actor of the last received message.

    The reference sender Actor of the last received message. Is defined if the message was sent from another Actor, else deadLetters in akka.actor.ActorSystem.

    WARNING: Only valid within the Actor itself, so do not close over it and publish it to other threads!

    Definition Classes
    Actor
  92. val serializer: Serializer
  93. def setData(key: KeyId, envelope: DataEnvelope): DataEnvelope
  94. var statusCount: Long
  95. var statusTotChunks: Int
  96. val subscribers: [, []] with [, ActorRef]
  97. var subscriptionKeys: [KeyId, KeyR]
  98. val supervisorStrategy: OneForOneStrategy

    User overridable definition the strategy to use for supervising child actors.

    User overridable definition the strategy to use for supervising child actors.

    Definition Classes
    → Actor
  99. def unhandled(message: Any): Unit

    User overridable callback.

    User overridable callback.

    Is called when a message isn't handled by the current behavior of the actor by default it fails with either a (in case of an unhandled message) or publishes an to the actor's system's akka.event.EventStream

    Definition Classes
    Actor
  100. var unreachable: [UniqueAddress]
  101. def updateUsedTimestamp(key: KeyId, timestamp: Timestamp): Unit
  102. var weaklyUpNodes: [UniqueAddress]
  103. val wildcardSubscribers: [, []] with [, ActorRef]
  104. def write(key: KeyId, writeEnvelope: DataEnvelope): Option[DataEnvelope]
  105. def writeAndStore(key: KeyId, writeEnvelope: DataEnvelope, reply: Boolean): Unit