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