产生背景
随着我们业务规模的不断扩展，用户量膨胀，并发量持续提升。原有的redis的架构，兴许已经远远达不到我们的需求了，这时候应允产生的一些问题，比如：
- 单机的CPU、内存、连接数、计算力都是有极限的，不能无限制的承载流量的扩增。
- 超额的请求、大规模的数据计算，导致必然的慢响应。
当单机的吞吐无法承受持续扩增的流量的时候，存在常规的两种策略：横向（scale out） 和 纵向（scale up）扩展。
- 纵向扩展（scale up）：将单个实例的硬件资源做提升，比如 CPU核数量、内存容量、SSD容量。
- 横向扩展（scale out）：横向扩增 Redis 实例数，这样每个节点只负责一部分数据就可以，分担一下压力，典型的分治思维。
那么横向扩展和纵向扩展各有什么优缺点呢？
- scale up 虽然操作起来比较简易。但是没法解决Redis一些瓶颈问题，比如持久化（如轮式RDB快照还是AOF指令），遇到大数据量的时候，照样效率会很低，响应慢。另外，单台服务机硬件扩容也是有限制的，不可能无限操作。
- scale out 更容易扩展，分片的模式可以解决很多问题，包括单一实例节点的硬件扩容限制、成本限制，还可以分摊压力，精细化治理，精细化维护。当然同时也要面临分布式带来的一些问题。
现实情况下，在面对千万级甚至亿级别的流量的时候，很多大厂都是在千百台的实例节点组成的集群上进行流量调度、服务治理的。
也因此便需要进行适当的推进架构的演进，来满足发展的需要，集群模式也应运而生，使用集群模式，也是业内广泛采用的模式。
集群模式Cluster
集群模式，即Redis Cluster，是Redis 3.0开始引入的分布式存储方案，类似MySQL，Redis 集群也是一种分布式数据库方案，集群通过分片（sharding）模式来对数据进行管理，并具备分片间数据复制、故障转移和流量调度的能力。
Redis集群的做法是将数据划分为 16384（2的14次方）个哈希槽（slots），如果你有多个实例节点，那么每个实例节点将管理其中一部分的槽位，槽位的信息(集群的哈希槽分配情况以及映射信息)会存储在各自所归属的节点中。假设，集群有4个 Redis 节点，每个节点负责集群中的一部分数据，数据量可以不均匀。比如可以通过 addslots 命令指定哈希槽范围，这样性能好的实例节点可以多分担一些压力。
