<p>Redis Cluster could be considered as an OOTB solution for the Scalability requirements. There is another interesting open source library known as Redis Shard for sharding implementations on Redis. Please find the <a href="https://github.com/zhihu/redis-shard" rel="nofollow noreferrer">GitHub repository here</a>.</p>

CC BY-SA 4.0
2021-02-06T16:40:27.890Z
2021-02-06T16:40:27.890Z
Gokul Alex
<p>Just for the sake of completeness: Redis documentation <a href="https://redislabs.com/ebook/part-3-next-steps/chapter-10-scaling-redis/" rel="nofollow noreferrer">https://redislabs.com/ebook/part-3-next-steps/chapter-10-scaling-redis/</a>
suggest a general rule of thumb - add replicas for reads, add shards for writes and memory capacity.  And it does make sense.</p>
<p>The replica can have a complete copy of its shard. The more shards the smaller they are. Also writing to one shard does not limit other ones.</p>
<p>If the only concern is reading, then replicas are the simplest solution.</p>
<p>If you need both, just combine.</p>

CC BY-SA 4.0
2021-03-30T11:14:41.210Z
2021-03-30T11:14:41.210Z
petrchpetr
<h1>Background</h1>

<p>last week we had a major outage, we identified the bottle neck to be redis number of connections:
<a href="https://i.sstatic.net/lig1O.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/lig1O.png" alt="enter image description here"></a></p>

<p>Our quick fix was to scale redis from cache.m4.4xlarge to chache.m4.10xlarge (vertical scaling)</p>

<p>However this scaling is quite expensive:
<a href="https://i.sstatic.net/jLqDW.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/jLqDW.png" alt="enter image description here"></a></p>

<p>we would like to scale horizontally:
<a href="https://i.sstatic.net/ieKvp.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ieKvp.png" alt="enter image description here"></a>
Unfortunately, the application code we are using now only allows us to either create a redis cluster with multiple shards, or using a single shard with multiple replicas (see discussion <a href="https://stackoverflow.com/questions/57761328/how-to-create-a-predis-client-that-does-both-clustering-and-replicatio">here</a>). </p>

<h1>Question</h1>

<p>considering that our bottle neck is the connection limit, would it be getter to scale by clustering and increasing the shard number, or by having a single shard and replicating it?</p>

CC BY-SA 4.0
2019-12-31T20:20:07.170Z
Does [this](https://stackoverflow.com/a/2322731/2777965) help?
030
CC BY-SA 4.0
2020-02-16T20:22:56.810Z
What did you end up doing? Article about [Partitioning](https://redis.io/topics/partitioning) may help as well.
Kyslik
CC BY-SA 4.0
2020-02-16T20:26:43.973Z
We found out that our application code was very inefficient. we optimized and redis stopped being a bottle neck
abbood
CC BY-SA 4.0
2021-02-01T21:50:58.120Z
software has lots of bottlenecks so starting there is always a good step.
Max N
<redis><scalability><cache>
if the bottle neck is the number of connections, is it better to scale redis by sharding or by replication?
abbood
# if the bottle neck is the number of connections, is it better to scale redis by sharding or by replication?

(Asked by: username_0 on 2019-09-03)

# Background

last week we had a major outage, we identified the bottle neck to be redis number of connections:
[![enter image description here](https://i.sstatic.net/lig1O.png)](https://i.sstatic.net/lig1O.png)

Our quick fix was to scale redis from cache.m4.4xlarge to chache.m4.10xlarge (vertical scaling)

However this scaling is quite expensive:
[![enter image description here](https://i.sstatic.net/jLqDW.png)](https://i.sstatic.net/jLqDW.png)

we would like to scale horizontally:
[![enter image description here](https://i.sstatic.net/ieKvp.png)](https://i.sstatic.net/ieKvp.png)
Unfortunately, the application code we are using now only allows us to either create a redis cluster with multiple shards, or using a single shard with multiple replicas (see discussion [here](https://stackoverflow.com/questions/57761328/how-to-create-a-predis-client-that-does-both-clustering-and-replicatio)).

# Question

considering that our bottle neck is the connection limit, would it be getter to scale by clustering and increasing the shard number, or by having a single shard and replicating it?

**Tags:** redis, scalability, cache

> **Comments:**
> **username_1**: Does [this](https://stackoverflow.com/a/2322731/2777965) help?  
> **username_2**: What did you end up doing? Article about [Partitioning](https://redis.io/topics/partitioning) may help as well.  
> **username_0**: We found out that our application code was very inefficient. we optimized and redis stopped being a bottle neck  
> **username_3**: software has lots of bottlenecks so starting there is always a good step.  

---

## 2 answers

### Answer by username_4 on 2021-02-06. Score: 1

Redis Cluster could be considered as an OOTB solution for the Scalability requirements. There is another interesting open source library known as Redis Shard for sharding implementations on Redis. Please find the [GitHub repository here](https://github.com/zhihu/redis-shard).


---

### Answer by username_5 on 2021-03-30. Score: 0

Just for the sake of completeness: Redis documentation <https://redislabs.com/ebook/part-3-next-steps/chapter-10-scaling-redis/>
suggest a general rule of thumb - add replicas for reads, add shards for writes and memory capacity. And it does make sense.

The replica can have a complete copy of its shard. The more shards the smaller they are. Also writing to one shard does not limit other ones.

If the only concern is reading, then replicas are the simplest solution.

If you need both, just combine.


---

