AWS ElastiCache - Redis

Giriş

Açıklaması şöyle. Yani Memcached veya Redis olabilir. Memcached artık kaybolmaya başladığı için bunu Redis kabul etmek lazım

There are two types of in-memory caching engines:

1. Memcached — designed for simplicity, so used with you need the simplest model possible.

2. Redis — works for a wide range of use cases and have multi AZ. You can also complete backups/restores of redis.

Redis

Redis'in pahalı olduğu söyleniyor. ElastiCache kullanmadan önce Amazon Elastic Compute Cloud (EC2) üzerinde denenebilir. Açıklaması şöyle

Run a Docker redis in ec2 for a while first. Make sure it serves your purposes. Figure out how the sizing works for you. Remember redis is meant to hold ephemeral data in memory, so please don’t treat it as a DB. It’s best to design your system assuming that redis may or may not lose whatever is inside. Clustering or HA via Sentinel, can all come later when you know you need it!

Redis Kullanımı

İki şekilde kullanılabilir. Cluster mode enabled veya disabled olarak. Kısaca 

1 Redis-CME

2.Redis-CMD

Açıklaması şöyle

Elasticache provides two flavors of Redis, Cluster Mode Enabled (Redis-CME) and Cluster Mode Disabled(Redis-CMD). 

Redis-CMD

Açıklaması şöyle. Tek bir cluster ve tek bir shard var. Cluster'da primary ve replica düğümler var.

Broadly speaking, for Redis-CMD, there is only one shard. The shard comprises the primary node along with the read replicas. Read replicas maintain a copy of the data from the cluster’s primary node.

Redis-CME

Açıklaması şöyle. Tek bir cluster var ancal bu sefer 250 taneye kadar shard olabiliyor. Her bir shard için primary ve replica düğümler var.

For Redis-CME, Elasticache allows up to 250 shards for a Redis cluster. Each shard has a primary node and read replicas. Elasticache distributes the keyspace evenly across all the shards. When reading or writing data to the cluster, the client itself determines which shard to use based on the keyspace. This design pushes the work to the client and avoids any potential single points of failure.

Redis-CME Problemi

Açıklaması şöyle. Yani bir object graph gibi bir şeye ihtiyaç varsa, CME iyi olmayabilir

When we started using Redis, we soon realized use-cases where we wanted to fetch multiple Redis keys at once (think Friends of Friends) and to avoid multiple network round trips, we thought of using mget call in Redis which allows us to do so.

...

The caveat here was the sharded nature of our setup. This meant that essentially the keys that we were trying to fetch in one-go, could be distributed across multiple shards, i.e. across multiple nodes, defeating our fetch all-at-once requirement.

Bu problem için Redis Hashtags kullanılabilir. Açıklaması şöyle. Ancak bunu yapınca veri tüm shardlara eşit şekilde dağılmayabilir

To solve this, we started using Redis Hashtags which helped us localize all related data on a single Redis node. Redis Cluster provides the concept of hashtags, according to which, if there is a substring between {} brackets in a key, only what is inside the string is hashed. An example of this in our application would be {RELATED_STOCKS}_AAPL. By surrounding the RELATED_STOCKS section of each key in curly braces, we are effectively storing them in the same slot. This means that we can store an entire group by calling MSET once and fetch related stocks for multiple stocks at once using MGET. This usage pattern became more and more prevalent across our application. For example, all related stocks for all the stocks were now mapped to the same hash key in Redis because of {RELATED_STOCKS} hashtag, and hence same hash slot and shard on Redis, making keys distributed less evenly across nodes, which can cause certain nodes to use more memory than others.