pivotal-cf/redis-reference-architecture

Name: redis-reference-architecture

Owner: Pivotal Cloud Foundry

Description: null

Created: 2018-02-08 15:38:13.0

Updated: 2018-04-16 15:28:31.0

Pushed: 2018-04-16 15:28:30.0

Homepage: null

Size: 26983

Language: null

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

Redis Reference Architectures

The purpose of this repository is to make it easier to use the Pivotal Cloud Foundry Redis Tile Redis for PCF. The repository contains example Cloud Foundry Apps that demonstrate using Redis for PCF.

These example applications are written in Java and make use of the compatibility of Spring with Cloud Foundry bound services.

Pros and Cons of the Example Apps

Redis can be used for storing a wide range of data. No reference architecture is a good fit with all possible uses of Redis. Our existing examples focus on using redis as a cache. If you require that the data in Redis be stored in a specific structure, such as a specific list or set, this is likely not possible using Spring Cache. We do not yet have a reference architecture for you.

Example Apps:

1. Redis Cache Failure Handling

   This example architecture uses the Spring Cache framework with a single Redis service to cache calls to a java method.

2. Appropriate if you have a method that will benefit from caching:

   • the method is slow to run
   • the method always returns the same result for a given input (similar to a pure function, but may have idempotent side effects)
   • the method is called repeatedly with the same input

3. Appropriate if your App can handle a short period of time when the cache is unavailable

   • Redis for PCF service instances become unavailable for a few minutes during upgrades

4. Not appropriate if you require direct access and manipulation of the underlying Redis cache

5. Multiple Redis Cache Failure Handling

   This architecture extends the first example to use two Redis services to increase availability of the Redis cache in the event of downtime for one Redis service.

6. Appropriate if you have a method that will benefit from caching

7. Appropriate if having one cache available while another is down is important to your App

8. Not appropriate if you require direct access and manipulation of the underlying Redis cache