Redis在3.0版本前只支持单实例模式，虽然现在的服务器内存可以到100GB、200GB的规模，但是单实例模式限制了Redis没法满足业务的需求（例如新浪微博就曾经用Redis存储了超过1TB的数据）。Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。

下面介绍Redis的集群方案  :客户端分片、Twemproxy、Redis cluster

一、客户端分片

　　客户端分片是把分片的逻辑放在Redis客户端实现，通过Redis客户端预先定义好的路由规则，把对Key的访问转发到不同的Redis实例中，最后把返回结果汇集。这种方案的模式如图1所示。

优点：

1简单，性能高。

客户端分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。开发人员清楚怎么实现分片、路由的规则，不用担心踩坑。

缺点：

1. 不支持动态增删节点，这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。

2. 可运维性差，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本。

3.业务逻辑与数据存储逻辑耦合，在不同的客户端程序中，维护相同的分片逻辑成本巨大。例如，系统中有两套业务系统共用一套Redis集群，一套业务系统用Java实现，另一套业务系统用PHP实现。为了保证分片逻辑的一致性，在Java客户端中实现的分片逻辑也需要在PHP客户端实现一次。相同的逻辑在不同的系统中分别实现，这种设计本来就非常糟糕，而且需要耗费巨大的开发成本保证两套业务系统分片逻辑的一致性。

二、Twemproxy

　　Twemproxy是由Twitter开源的Redis代理，其基本原理是：Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。

　　Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

　　Twemproxy集群架构如图2所示。

优点：

1.不需要改任何的代码逻辑，客户端像连接Redis实例一样连接Twemproxy。

2.支持无效Redis实例的自动删除。

3.轻量级、保持长连接。减少了客户端与Redis实例的连接数，Twemproxy与Redis实例保持连接。

4. 自动在多台缓存服务器间共享数据；

不足：

1. 无法平滑地增加Redis实例。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。（最大的问题）

2. 运维不友好，甚至没有控制面板；

3. 本身也是单点，需要用Keepalived做高可用方案；

4. 性能一般，不如Redis cluster和Codis，由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。

三、Redis cluster

基于smart client和无中心的设计，client必须按key的哈希将请求直接发送到对应的节点。

Redis Cluster没有使用一致性hash, 而是引入了虚拟槽的概念.

Redis Cluster有16384个虚拟槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽。

优点：

1. 高性能

2. 官方支持

3. 支持动态扩容，对业务透明

4. 搭建简单

缺点：

1. 要求客户端必须支持cluster协议；

2. client不能直接像单机一样使用pipeline；

3. 相对于单机Redis，功能上有一些限制：

（1）key批量操作支持有限；

（2）只支持多key在同一节点上的事务操作，当多个key分布在不同节点时，不支持事务操作；

（3）key作为数据分区的最小粒度，不能将一个大的键值对象如hash, list等映射到不同的节点；

（4）不支持多数据空间；

（5）复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构；

https://www.sohu.com/a/160594030_505901

https://blog.csdn.net/sanpo/article/details/52839044