Consistency and Durability

    Redis Enterprise Software (RS) comes with the ability to replicate data to another slave for high availability and persist in-memory data on disk permanently for durability. With the new WAIT command, you can control the consistency and durability guarantees for the replicated and persisted database in RS. Any updates that are issued to the database are typically performed with the following flow shown below; Application issues a write, Proxy communicates with the correct master "shard" in the system that contains the given key, The acknowledgment is sent to proxy once the write operation completes The proxy sends the acknowledgment back to the application.

    Database Persistence with Redis Enterprise Software

    All data is stored and managed exclusively in either RAM or RAM + Flash Memory (Redis on Flash) and therefore, is at risk of being lost upon a process or server failure. As Redis Enterprise Software is not just a caching solution, but also a full-fledged database, persistence to disk is critical. Therefore, Redis Enterprise Software supports persisting data to disk on a per-database basis and in multiple ways.

    Discovery Service

    The Discovery Service provides an IP-based connection management service used when connecting to Redis Enterprise Software databases. When used in conjunction with Redis Enterprise Software's other high availability features, the Discovery Service assists an application cope with topology changes such as adding, removing of nodes, node failovers and so on. It does this by providing your application with the ability to easily discover which node hosts the database endpoint. The API used for discovery service is compliant with the Redis Sentinel API.

    OSS Cluster API Architecture

    The Redis OSS Cluster API support in Redis Enterprise Software (RS) provides a simple mechanism for cluster-aware Redis clients to learn and know the cluster topology. This enables clients to connect directly to an RS proxy on the node hosting the master shard for the data being operated on. The result is that for all but the initial call to get the cluster topology or the call to reacquire the location of the master shard, the client connects to the RS endpoint proxy where the master shard is located.