Rename active active to replicated event sourcing (#29435)
* Move active active internals into the internal package * Renaming active active to Replicated Event Sourcing * Rename of Active Active to Replicated Event Sourcing * Revert changes to testkit * Java test formatting... * Gave up on getting apidoc to link to EventSourcedBehavior and made code snippets of it Co-authored-by: Christopher Batey <christopher.batey@gmail.com>
This commit is contained in:
Johan Andrén
Christopher Batey
parent
0b11ae362c
commit
b03412d5b2
48 changed files with 1871 additions and 1439 deletions
|
|
@ -61,11 +61,7 @@ from the events, or publish the events to other services.
|
|||
|
||||
## Multi-DC Persistence
|
||||
|
||||
@java[@extref[Multi-DC Persistence example project](samples:akka-samples-persistence-dc-java)]
|
||||
@scala[@extref[Multi-DC Persistence example project](samples:akka-samples-persistence-dc-scala)]
|
||||
|
||||
Illustrates how to use Lightbend's [Multi-DC Persistence](https://doc.akka.io/docs/akka-enhancements/current/persistence-dc/index.html)
|
||||
with active-active persistent entities across data centers.
|
||||
This commercial feature has now been superseeded by @ref[Replicated Event Sourcing](../typed/replicated-eventsourcing.md)
|
||||
|
||||
## Cluster with Docker
|
||||
|
||||
|
|
|
|||
|
|
@ -192,8 +192,8 @@ other data centers.
|
|||
Especially when used together with Akka Persistence that is based on the single-writer principle
|
||||
it is important to avoid running the same entity at multiple locations at the same time with a
|
||||
shared data store. That would result in corrupt data since the events stored by different instances
|
||||
may be interleaved and would be interpreted differently in a later replay. For active active persistent
|
||||
entities see Lightbend's [Multi-DC Persistence](https://doc.akka.io/docs/akka-enhancements/current/persistence-dc/index.html)
|
||||
may be interleaved and would be interpreted differently in a later replay. For replicated persistent
|
||||
entities see @ref[Replciated Event Sourcing](replicated-eventsourcing.md).
|
||||
|
||||
If you need global entities you have to pick one data center to host that entity type and only start
|
||||
`ClusterSharding` on nodes of that data center. If the data center is unreachable from another data center the
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ project.description: Event Sourcing with Akka Persistence enables actors to pers
|
|||
@@@ index
|
||||
|
||||
* [persistence](persistence.md)
|
||||
* [active-active](persistence-active-active.md)
|
||||
* [active-active](replicated-eventsourcing.md)
|
||||
* [cqrs](cqrs.md)
|
||||
* [persistence-style](persistence-style.md)
|
||||
* [persistence-snapshot](persistence-snapshot.md)
|
||||
|
|
@ -20,6 +20,6 @@ project.description: Event Sourcing with Akka Persistence enables actors to pers
|
|||
* [persistence-query-leveldb](../persistence-query-leveldb.md)
|
||||
* [persistence-plugins](../persistence-plugins.md)
|
||||
* [persistence-journals](../persistence-journals.md)
|
||||
* [active-active-examples](persistence-active-active-examples.md)
|
||||
* [active-active-examples](replicated-eventsourcing-examples.md)
|
||||
|
||||
@@@
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Active-Active Examples
|
||||
# Replicated Event Sourcing Examples
|
||||
|
||||
The following are more realistic examples of building systems with active-active event sourcing.
|
||||
The following are more realistic examples of building systems with Replicated Event Sourcing.
|
||||
|
||||
## Auction
|
||||
|
||||
|
|
@ -16,21 +16,21 @@ We are building a small auction service. It has the following operations:
|
|||
We model those operations as commands to be sent to the auction actor:
|
||||
|
||||
Scala
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/AAAuctionExampleSpec.scala) { #commands }
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedAuctionExampleSpec.scala) { #commands }
|
||||
|
||||
The events:
|
||||
|
||||
Scala
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/AAAuctionExampleSpec.scala) { #events }
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedAuctionExampleSpec.scala) { #events }
|
||||
|
||||
The winner does not have to pay the highest bid but only enough to beat the second highest so the `highestCounterOffer` is in the `AuctionFinished` event.
|
||||
|
||||
Let's have a look at the auction entity that will handle incoming commands:
|
||||
|
||||
Scala
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/AAAuctionExampleSpec.scala) { #command-handler }
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedAuctionExampleSpec.scala) { #command-handler }
|
||||
|
||||
There is nothing specific to active-active about the command handler. It is the same as a command handler for a standard `EventSourcedBehavior`.
|
||||
There is nothing specific to Replicated Event Sourcing about the command handler. It is the same as a command handler for a standard `EventSourcedBehavior`.
|
||||
For `OfferBid` and `AuctionFinished` we do nothing more than to emit
|
||||
events corresponding to the command. For `GetHighestBid` we respond with details from the state. Note, that we overwrite the actual
|
||||
offer of the highest bid here with the amount of the `highestCounterOffer`. This is done to follow the popular auction style where
|
||||
|
|
@ -41,13 +41,13 @@ The initial state is taken from a `AuctionSetup` instance. The minimum bid is mo
|
|||
an `initialBid`.
|
||||
|
||||
Scala
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/AAAuctionExampleSpec.scala) { #setup }
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedAuctionExampleSpec.scala) { #setup }
|
||||
|
||||
|
||||
The auction moves through the following phases:
|
||||
|
||||
Scala
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/AAAuctionExampleSpec.scala) { #phase }
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedAuctionExampleSpec.scala) { #phase }
|
||||
|
||||
The closing and closed states are to model waiting for all replicas to see the result of the auction before
|
||||
actually closing the action.
|
||||
|
|
@ -56,7 +56,7 @@ Let's have a look at our state class, `AuctionState` which also represents the C
|
|||
|
||||
|
||||
Scala
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/AAAuctionExampleSpec.scala) { #state }
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedAuctionExampleSpec.scala) { #state }
|
||||
|
||||
The state consists of a flag that keeps track of whether the auction is still active, the currently highest bid,
|
||||
and the highest counter offer so far.
|
||||
|
|
@ -95,9 +95,9 @@ all replicas have seen all bids.
|
|||
In the event handler above, when recovery is not running, it calls `eventTriggers`.
|
||||
|
||||
Scala
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/AAAuctionExampleSpec.scala) { #event-triggers }
|
||||
: @@snip [AuctionExample](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedAuctionExampleSpec.scala) { #event-triggers }
|
||||
|
||||
The event trigger uses the `ActiveActiveContext` to decide when to trigger the Finish of the action.
|
||||
The event trigger uses the `ReplicationContext` to decide when to trigger the Finish of the action.
|
||||
When a replica saves the `AuctionFinished` event it checks whether it should close the auction.
|
||||
For the close to happen the replica must be the one designated to close and all replicas must have
|
||||
reported that they have finished.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Active-Active Event Sourcing
|
||||
# Replicated Event Sourcing
|
||||
|
||||
@@@ warning
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ warning or deprecation period. It is also not recommended to use this module in
|
|||
This restriction means that in the event of network partitions, and for a short time during rolling re-deploys, `EventSourcedBehaviors`s are unavailable.
|
||||
|
||||
|
||||
Active-active event sourcing enables running multiple replicas of each entity.
|
||||
Replicated Event Sourcing enables running multiple replicas of each entity.
|
||||
There is automatic replication of every event persisted to all replicas.
|
||||
|
||||
For instance, a replica can be run per:
|
||||
|
|
@ -27,27 +27,27 @@ The motivations are:
|
|||
* Serve requests from a location near the user to provide better responsiveness
|
||||
* Balance the load over many servers
|
||||
|
||||
However, the event handler must be able to **handle concurrent events** as when active-active is enabled
|
||||
However, the event handler must be able to **handle concurrent events** as when replication is enabled
|
||||
there is no longer the single writer principle as there is with a normal `EventSourcedBehavior`.
|
||||
|
||||
The state of an active-active `EventSourcedBehavior` is **eventually consistent**. Event replication may be delayed
|
||||
The state of a replicated `EventSourcedBehavior` is **eventually consistent**. Event replication may be delayed
|
||||
due to network partitions and outages and the event handler and those reading the state must be designed to handle this.
|
||||
|
||||
To be able to use active active the journal and snapshot store used is required to have specific support for the metadata that active active needs (see @ref[Journal Support](#journal-support))
|
||||
To be able to use Replicated Event Sourcing the journal and snapshot store used is required to have specific support for the metadata that the replication needs (see @ref[Journal Support](#journal-support))
|
||||
|
||||
## Relaxing the single writer principle for availability
|
||||
|
||||
Taking the example of using active-active to run a replica per data center.
|
||||
Taking the example of using Replicated Event Sourcing to run a replica per data center.
|
||||
|
||||
When there is no network partitions and no concurrent writes the events stored by an `EventSourcedBehavior` at one replica can be replicated and consumed by another (corresponding) replica in another data center without any concerns. Such replicated events can simply be applied to the local state.
|
||||
When there is no network partitions and no concurrent writes the events stored by a `EventSourcedBehavior` at one replica can be replicated and consumed by another (corresponding) replica in another data center without any concerns. Such replicated events can simply be applied to the local state.
|
||||
|
||||
|
||||
|
||||
The interesting part begins when there are concurrent writes by `EventSourcedBehavior`replicas. That is more likely to happen when there is a network partition, but it can also happen when there are no network issues. They simply write at the "same time" before the events from the other side have been replicated and consumed.
|
||||
The interesting part begins when there are concurrent writes by `EventSourcedBehavior` replicas. That is more likely to happen when there is a network partition, but it can also happen when there are no network issues. They simply write at the "same time" before the events from the other side have been replicated and consumed.
|
||||
|
||||
|
||||
|
||||
The event handler logic for applying events to the state of the entity must be aware of that such concurrent updates can occur and it must be modeled to handle such conflicts. This means that it should typically have the same characteristics as a Conflict Free Replicated Data Type (CRDT). With a CRDT there are by definition no conflicts and the events can just be applied. The library provides some general purpose CRDTs, but the logic of how to apply events can also be defined by an application specific function.
|
||||
The event handler logic for applying events to the state of the entity must be aware of that such concurrent updates can occur, and it must be modeled to handle such conflicts. This means that it should typically have the same characteristics as a Conflict Free Replicated Data Type (CRDT). With a CRDT there are by definition no conflicts, the events can always be applied. The library provides some general purpose CRDTs, but the logic of how to apply events can also be defined by an application specific function.
|
||||
|
||||
For example, sometimes it's enough to use application specific timestamps to decide which update should win.
|
||||
|
||||
|
|
@ -58,44 +58,44 @@ To assist in implementing the event handler active-active detects these conflict
|
|||
@scala[The same API as regular `EventSourcedBehavior`s]@java[A very similar API to the regular `EventSourcedBehavior`] is used to define the logic.
|
||||
|
||||
To enable an entity for active-active
|
||||
replication @java[let it extend `ActiveActiveEventSourcedBehavior` instead of `EventSourcedBehavior` and] use the factory methods on @apidoc[ActiveActiveEventSourcing].
|
||||
replication @java[let it extend `ReplicatedEventSourcedBehavior` instead of `EventSourcedBehavior` and] use the factory methods on @scala[`akka.persistence.typed.scaladsl.ReplicatedEventSourcing`]@java[`akka.persistence.typed.javadsl.ReplicatedEventSourcing`].
|
||||
|
||||
All replicas need to be known up front:
|
||||
|
||||
Scala
|
||||
: @@snip [ActiveActiveCompileOnlySpec.scala](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ActiveActiveCompileOnlySpec.scala) { #replicas }
|
||||
: @@snip [ReplicatedEventSourcingCompileOnlySpec.scala](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedEventSourcingCompileOnlySpec.scala) { #replicas }
|
||||
|
||||
Java
|
||||
: @@snip [ActiveActiveCompileOnlyTest.java](/akka-persistence-typed-tests/src/test/java/jdocs/akka/persistence/typed/ActiveActiveCompileOnlyTest.java) { #replicas }
|
||||
: @@snip [ReplicatedEventSourcingCompileOnlyTest.java](/akka-persistence-typed-tests/src/test/java/jdocs/akka/persistence/typed/ReplicatedEventSourcingCompileOnlyTest.java) { #replicas }
|
||||
|
||||
|
||||
Then to enable replication create the event sourced behavior with the factory method:
|
||||
|
||||
Scala
|
||||
: @@snip [ActiveActiveCompileOnlySpec.scala](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ActiveActiveCompileOnlySpec.scala) { #factory }
|
||||
: @@snip [ReplicatedEventSourcingCompileOnlySpec.scala](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedEventSourcingCompileOnlySpec.scala) { #factory }
|
||||
|
||||
Java
|
||||
: @@snip [ActiveActiveCompileOnlyTest.java](/akka-persistence-typed-tests/src/test/java/jdocs/akka/persistence/typed/ActiveActiveCompileOnlyTest.java) { #factory }
|
||||
: @@snip [ReplicatedEventSourcingCompileOnlyTest.java](/akka-persistence-typed-tests/src/test/java/jdocs/akka/persistence/typed/ReplicatedEventSourcingCompileOnlyTest.java) { #factory }
|
||||
|
||||
The factory takes in:
|
||||
|
||||
* EntityID: this will be used as part of the underlying persistenceId
|
||||
* Replica: Which replica this instance is
|
||||
* All Replicas and the query plugin used to read their events
|
||||
* A factory function to create an instance of the @scala[`EventSourcedBehavior`]@java[`ActiveActiveEventSourcedBehavior`]
|
||||
* A factory function to create an instance of the @scala[`EventSourcedBehavior`]@java[`ReplicatedEventSourcedBehavior`]
|
||||
|
||||
In this scenario each replica reads from each other's database effectively providing cross region replication for any database that has an Akka Persistence plugin. Alternatively if all the replicas use the same journal, e.g. for testing or if it is a distributed database such as Cassandra, the `withSharedJournal` factory can be used.
|
||||
|
||||
Scala
|
||||
: @@snip [ActiveActiveCompileOnlySpec.scala](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ActiveActiveCompileOnlySpec.scala) { #factory-shared}
|
||||
: @@snip [ReplicatedEventSourcingCompileOnlySpec.scala](/akka-persistence-typed-tests/src/test/scala/docs/akka/persistence/typed/ReplicatedEventSourcingCompileOnlySpec.scala) { #factory-shared}
|
||||
|
||||
Java
|
||||
: @@snip [ActiveActiveCompileOnlyTest.java](/akka-persistence-typed-tests/src/test/java/jdocs/akka/persistence/typed/ActiveActiveCompileOnlyTest.java) { #factory-shared }
|
||||
: @@snip [ReplicatedEventSourcingCompileOnlyTest.java](/akka-persistence-typed-tests/src/test/java/jdocs/akka/persistence/typed/ReplicatedEventSourcingCompileOnlyTest.java) { #factory-shared }
|
||||
|
||||
|
||||
@@@ div { .group-scala }
|
||||
|
||||
The function passed to both factory methods return an `EventSourcedBehavior` and provide access to the @apidoc[ActiveActiveContext] that has the following methods:
|
||||
The function passed to both factory methods return an `EventSourcedBehavior` and provide access to the @apidoc[ReplicationContext] that has the following methods:
|
||||
|
||||
* entityId
|
||||
* replicaId
|
||||
|
|
@ -108,8 +108,8 @@ As well as methods that **can only be** used in the event handler. The values th
|
|||
|
||||
@@@ div { .group-java }
|
||||
|
||||
The function passed to both factory methods is invoked with a special @apidoc[ActiveActiveContext] that needs to be passed to the
|
||||
concrete `ActiveActiveEventSourcedBehavior` and on to the super constructor.
|
||||
The function passed to both factory methods is invoked with a special @apidoc[ReplicationContext] that needs to be passed to the
|
||||
concrete `ReplicatedEventSourcedBehavior` and on to the super constructor.
|
||||
|
||||
The context gives access to:
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ The context gives access to:
|
|||
* allReplicas
|
||||
* persistenceId
|
||||
|
||||
As well as methods that **can only be** used in the event handler, accessed through `getActiveActiveContext`. The values these methods return relate to the event that is being processed.
|
||||
As well as methods that **can only be** used in the event handler, accessed through `getReplicationContext`. The values these methods return relate to the event that is being processed.
|
||||
|
||||
@@@
|
||||
|
||||
|
|
@ -190,9 +190,9 @@ There is no built in support for knowing an event has been replicated to all rep
|
|||
For some use cases you may need to trigger side effects after consuming replicated events. For example when an auction has been closed in
|
||||
all data centers and all bids have been replicated.
|
||||
|
||||
The @api[ActiveActiveContext] contains the current replica, the origin replica for the event processes, and if a recovery is running. These can be used to
|
||||
The @api[ReplicationContext] contains the current replica, the origin replica for the event processes, and if a recovery is running. These can be used to
|
||||
implement side effects that take place once events are fully replicated. If the side effect should happen only once then a particular replica can be
|
||||
designated to do it. The @ref[Auction example](./persistence-active-active-examples.md#auction) uses these techniques.
|
||||
designated to do it. The @ref[Auction example](./replicated-eventsourcing-examples.md#auction) uses these techniques.
|
||||
|
||||
|
||||
## How it works
|
||||
|
|
@ -203,7 +203,7 @@ You don’t have to read this section to be able to use the feature, but to use
|
|||
|
||||
Causal delivery order means that events persisted in one data center are read in the same order in other data centers. The order of concurrent events is undefined, which should be no problem
|
||||
when using [CRDT's](#conflict-free-replicated-data-types)
|
||||
and otherwise will be detected via the `ActiveActiveContext` concurrent method.
|
||||
and otherwise will be detected via the `ReplicationContext` concurrent method.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -231,7 +231,7 @@ A third data center may also see the events as either "e1, e3, e2" or as "e1, e2
|
|||
|
||||
### Concurrent updates
|
||||
|
||||
Active-active automatically tracks causality between events from different replias using [version vectors](https://en.wikipedia.org/wiki/Version_vector).
|
||||
Replicated Event Sourcing automatically tracks causality between events from different replicas using [version vectors](https://en.wikipedia.org/wiki/Version_vector).
|
||||
|
||||
|
||||
|
||||
|
|
@ -245,29 +245,29 @@ When comparing two version vectors `v1` and `v2`:
|
|||
* `v1`is CONCURRENT with `v2` otherwise
|
||||
|
||||
|
||||
## Sharded Active Active entities
|
||||
## Sharded Replicated Event Sourced entities
|
||||
|
||||
To simplify what probably are the most common use cases for how you will want to distribute the active active actors there is a minimal API for running multiple instances of @ref[Akka Cluster Sharding](cluster-sharding.md),
|
||||
To simplify what probably are the most common use cases for how you will want to distribute the replicated actors there is a minimal API for running multiple instances of @ref[Akka Cluster Sharding](cluster-sharding.md),
|
||||
each instance holding the entities for a single replica.
|
||||
|
||||
The distribution of the replicas can be controlled either through cluster roles or using the @ref[multi datacenter](cluster-dc.md) support in Akka Cluster.
|
||||
|
||||
The API consists of bootstrapping logic for starting the sharding instances through @apidoc[ActiveActiveShardingExtension] available from the
|
||||
The API consists of bootstrapping logic for starting the sharding instances through @apidoc[ReplicatedShardingExtension] available from the
|
||||
`akka-cluster-sharding-typed` module.
|
||||
|
||||
Scala
|
||||
: @@snip [ActiveActiveShardingSpec.scala](/akka-cluster-sharding-typed/src/test/scala/akka/cluster/sharding/typed/ActiveActiveShardingSpec.scala) { #bootstrap }
|
||||
: @@snip [ReplicatedShardingSpec.scala](/akka-cluster-sharding-typed/src/test/scala/akka/cluster/sharding/typed/ReplicatedShardingSpec.scala) { #bootstrap }
|
||||
|
||||
Java
|
||||
: @@snip [ActiveActiveShardingTest.java](/akka-cluster-sharding-typed/src/test/java/akka/cluster/sharding/typed/ActiveActiveShardingTest.java) { #bootstrap }
|
||||
: @@snip [ReplicatedShardingTest.java](/akka-cluster-sharding-typed/src/test/java/akka/cluster/sharding/typed/ReplicatedShardingTest.java) { #bootstrap }
|
||||
|
||||
`init` returns an @apidoc[ActiveActiveSharding] instance which gives access to @apidoc[EntityRef]s for each of the replicas for arbitrary routing logic:
|
||||
`init` returns an @apidoc[ReplicatedSharding] instance which gives access to @apidoc[EntityRef]s for each of the replicas for arbitrary routing logic:
|
||||
|
||||
Scala
|
||||
: @@snip [ActiveActiveShardingSpec.scala](/akka-cluster-sharding-typed/src/test/scala/akka/cluster/sharding/typed/ActiveActiveShardingSpec.scala) { #all-entity-refs }
|
||||
: @@snip [ReplicatedShardingSpec.scala](/akka-cluster-sharding-typed/src/test/scala/akka/cluster/sharding/typed/ReplicatedShardingSpec.scala) { #all-entity-refs }
|
||||
|
||||
Java
|
||||
: @@snip [ActiveActiveShardingTest.java](/akka-cluster-sharding-typed/src/test/java/akka/cluster/sharding/typed/ActiveActiveShardingTest.java) { #all-entity-refs }
|
||||
: @@snip [ReplicatedShardingTest.java](/akka-cluster-sharding-typed/src/test/java/akka/cluster/sharding/typed/ReplicatedShardingTest.java) { #all-entity-refs }
|
||||
|
||||
More advanced routing among the replicas is currently left as an exercise for the reader (or may be covered in a future release [#29281](https://github.com/akka/akka/issues/29281), [#29319](https://github.com/akka/akka/issues/29319)).
|
||||
|
||||
|
|
@ -275,24 +275,24 @@ More advanced routing among the replicas is currently left as an exercise for th
|
|||
## Direct Replication of Events
|
||||
|
||||
Normally an event has to be written in the journal and then picked up by the trailing read journal in the other replicas.
|
||||
As an optimization the active active events can be published across the Akka cluster to the replicas. The read side
|
||||
As an optimization the replicated events can be published across the Akka cluster to the replicas. The read side
|
||||
query is still needed as delivery is not guaranteed, but can be configured to poll the database less often since most
|
||||
events will arrive at the replicas through the cluster.
|
||||
|
||||
To enable this feature you first need to enable event publishing on the @scala[`EventSourcedBehavior`]@java[`ActiveActiveEventSourcedBehavior`] with `withEventPublishing`
|
||||
and then enable direct replication through `withDirectReplication()` on @apidoc[ActiveActiveShardingSettings] (if not using
|
||||
active active sharding the replication can be run standalone by starting the @apidoc[ActiveActiveShardingDirectReplication] actor).
|
||||
To enable this feature you first need to enable event publishing on the @scala[`EventSourcedBehavior`]@java[`ReplicatedEventSourcedBehavior`] with `withEventPublishing`
|
||||
and then enable direct replication through `withDirectReplication()` on @apidoc[ReplicatedShardingSettings] (if not using
|
||||
replicated sharding the replication can be run standalone by starting the @apidoc[ShardingDirectReplication] actor).
|
||||
|
||||
The "event publishing" feature publishes each event to the local system event bus as a side effect after it has been written,
|
||||
the `ActiveActiveShardingDirectReplication` actor subscribes to these events and forwards them to the replicas allowing them
|
||||
the @apidoc[ShardingDirectReplication] actor subscribes to these events and forwards them to the replicas allowing them
|
||||
to fast forward the stream of events for the origin replica. (With additional potential future support in journals for fast forwarding [#29311](https://github.com/akka/akka/issues/29311)).
|
||||
|
||||
## Journal Support
|
||||
|
||||
For a journal plugin to support active active it needs to store and read metadata for each event if it is defined in the @apiref[PersistentRepr]
|
||||
For a journal plugin to support replication it needs to store and read metadata for each event if it is defined in the @apiref[PersistentRepr]
|
||||
`metadata` field. To attach the metadata after writing it, `PersistentRepr.withMetadata` is used. The @apidoc[JournalSpec] in the Persistence TCK provides
|
||||
a capability flag `supportsMetadata` to toggle verification that metadata is handled correctly.
|
||||
|
||||
For a snapshot plugin to support active active it needs to store and read metadata for the snapshot if it is defined in the @apiref[akka.persistence.SnapshotMetadata] `metadata` field.
|
||||
For a snapshot plugin to support replication it needs to store and read metadata for the snapshot if it is defined in the @apiref[akka.persistence.SnapshotMetadata] `metadata` field.
|
||||
To attach the metadata when reading the snapshot the `akka.persistence.SnapshotMetadata.apply` factory overload taking a `metadata` parameter is used.
|
||||
The @apidoc[SnapshotStoreSpec] in the Persistence TCK provides a capability flag `supportsMetadata` to toggle verification that metadata is handled correctly.
|
||||
Loading…
Add table
Add a link
Reference in a new issue