Active-Active Redis applications
General information to keep in mind while developing applications for an Active-Active database.
| Redis Cloud |
|---|
Developing globally distributed applications can be challenging, as developers have to think about race conditions and complex combinations of events under geo-failovers and cross-region write conflicts. In Redis Cloud, Active-Active databases simplify developing such applications by directly using built-in smarts for handling conflicting writes based on the data type in use. Instead of depending on just simplistic "last-writer-wins" type conflict resolution, geo-distributed Active-Active databases combine techniques defined in CRDT (conflict-free replicated data types) research with Redis types to provide smart and automatic conflict resolution based on the data type's intent.
An Active-Active database is a globally distributed database that spans multiple cloud provider regions. Each Active-Active database can have many Active-Active database instances that come with added smarts for handling globally distributed writes using the proven CRDT approach. CRDT research describes a set of techniques for creating systems that can handle conflicting writes. CRDBs powered by Multi-Master Replication (MMR) provide a straightforward and effective way to replicate your data between regions and simplify development of complex applications that can maintain correctness under geo-failovers and concurrent cross-region writes to the same data.
Active-Active databases replicate data between multiple Redis Cloud provider regions. Common uses for Active-Active databases include disaster recovery, geographically redundant applications, and keeping data closer to your users' locations. MMR is always multi-directional amongst the regions configured in the Active-Active database. For unidirectional replication, see Active-Passive replication.
Example of synchronization
In the example below, database writes are concurrent at the points in time t1 and t2 and happen before a sync can communicate the changes. However, writes at times t4 and t6 are not concurrent as a sync happened in between.
| Time | CRDB Instance1 | CRDB Instance2 |
|---|---|---|
| t1 | SET key1 "a" | |
| t2 | SET key1 "b" | |
| t3 | — Sync — | — Sync — |
| t4 | SET key1 "c" | |
| t5 | — Sync — | — Sync — |
| t6 | SET key1 "d" |
Learn more about synchronization for each supported data type and how to develop applications with them on Redis Cloud.