如果要实现Redis数据的分片，我们有三种方案。
第一种是在客户端实现相关的逻辑，例如用取模或者一致性哈希对key进行分片， 查询和修改都先判断key的路由。
第二种是把做分片处理的逻辑抽取出来，运行一个独立的代理服务，客户端连接到这个代理服务，代理服务做请求的转发。
第三种就是基于服务端实现。
客户端 Sharding
在我们用得非常多的Jedis客户端中，支持分片功能。它是Spring Boot 2.x版本之前默认的Redis客户端，RedisTemplate就是对Jedis的封装。
Sharded Jedis
Jedis有几种连接池，其中有一种支持分片。
比如这里一个连接到16、一个连接到Windows的Redis服务。
public class ShardingTest {
public static void main(String[] args) {
JedisPoolConfig poolConfig = new JedisPoolConfig();
// Redis服务器
JedisShardInfo shardInfo1 = new JedisShardInfo("127.0.0.1", 6379);
JedisShardInfo shardInfo2 = new JedisShardInfo("192.168.0.16", 6379);
//连接池
List<JedisShardInfo> infoList = Arrays.asList(shardInfo1, shardInfo2);
ShardedJedisPool jedisPool = new ShardedJedisPool(poolConfig, infoList);
ShardedJedis jedis = null;
try{
jedis = jedisPool.getResource();
for(int i=0; i<100; i++)(
jedis.set("k"+i, ""+i);
}
for(int i=0; i<100; i++){
System.out.println(jedis.get("k"+i));
}
} finally {
if(jedis!=null) {
jedis.close();
}
}
}
通过dbsize命令发现，一台服务器有44个key,—台服务器有56个key。
ShardedJedis是怎么做到的呢？
如果是希望数据分布相对均匀的话，我们首先可以考虑哈希后取模(因为key不一定是整数，所以先计算哈希)。
哈希后取模
例如，hash(key)%N,根据余数，决定映射到那一个节点。这种方式比较简单，属于静态的分片规则。但是一旦节点数量变化（新增或者减少），由于取模的N发生变化, 数据需要重新分布。
为了解决这个问题，我们又有了一致性哈希算法。ShardedJedis实际上用的就是一 致性哈希算法。
一致性哈希
一致性哈希的原理：
把所有的哈希值空间组织成一个虚拟的圆环（哈希环），整个空间按顺时与十方向组织。因为是环形空间，0和2^32-1是重叠的。
假设我们有四台机器要哈希环来实现映射（分布数据），我们先根据机器的名称或IP计算哈希值，然后分布到哈希环中（黄色圆圈）。
现在有4条数据或者4个访问请求，对key计算后，得到哈希环中的位置（绿色圆圈）。沿哈希环顺时针找到的第一个Node,就是数据存储的节点。
在这种情况下，新增了一个Node5节点，只影响一部分数据的分布。
删除了节点3顺延到下一个节点只影响其中一段
—致性哈希解决了动态增减节点时，所有数据都需要重新分布的问题，它只会影响到下一个相邻的节点，对其他节点没有影响。
但是这样的一致性哈希算法有一个缺点，因为节点不一定是均匀地分布的，特别是在节点数比较少的情况下，所以数据不能得到均匀分布。解决这个问题的办法是引入虚拟节点(Virtual Node)。
比如：2个节点，5条数据，只有1条分布到Node2，4条分布到Node1,不均匀。
Node1设置了两个虚拟节点，Node2也设置了两个虚拟节点（虚线圆圈）。这时候有3条数据分布到Node1, 2条数据分布到Node2。
—致性哈希在分布式系统中，负载均衡、分库分表等场景中都有应用，跟LRU—样, 是一个很基础的算法。
那这样一个一致性哈希算法，到底怎么实现呢？哈希环是一个什么数据结构？虚拟节点又怎么实现？
redis.clients.util.Sharded.initialize(), jedis 实例被放到了一颗红黑树 TreeMap 中。
private void initialize(List<S> shards) {
//创建一个红黑树
nodes = new TreeMap<Long, S>();
//把所有Redis节点放到红黑树中
for (int i = 0; i != shards.size(); ++i) {
final S shardlnfo = shards.get(i);
//为每个Redis节点创建160个虚拟节点，放到红黑树中
if (shardlnfo.getName() == null) for (int n = 0; n < 160 * shardlnfo.getWeight(); n++) (
nodes.put(this.algo.hash("SHARD-" + i + "-NODE-" +n), shardInfo);
}
else for (int n = 0; n < 160 * shardInfo.getWeight(); n++) {
//对名字计算哈希(MurmurHash),名称格式SHARD-0-NODE-0
nodes.put(this. algo. hash (shardinfo.getName() +"*"+ shardlnfo. getWeight() + n), shardlnfo);
}
//添加到map中，键为ShardInfo,值为redis实例
resources.put(shardlnfo, shardlnfo.createResource());
}
}
当存取键值对时，计算键的哈希值，然后从红黑树上摘下比该值大的第一个节点上的 JedisShardlnfo，随后从 resources 取出 Jedis。
public R getShard(String key) {
return resources.get(getShardInfo(key));
}
获取红黑树子集，找出比它大的第一个节点。
public S getShardInfo(byte[] key) {
//获取比当前key的哈希值要大的红黑树的子集
SortedMap<Long, S> tail = nodes.tailMap(algo.hash(key));
if (tail.isEmpty()) {
//没有比它大的了，直接从nodes中取出
return nodes.get(nodes.firstKey());
}
//返回第一个比它大的JedisShardlnfo
return tail.get(tail.firstKey());
}
使用ShardedJedis之类的客户端分片代码的优势是配置简单，不依赖于其他中间件，分区的逻辑可以自定义，比较灵活。但是基于客户端的方案，不能实现动态的服务增减，每个客户端需要自行维护分片策略，存在重复代码。
第二种思路就是把分片的代码抽取出来，做成一个公共服务，所有的客户端都连接到这个代理层。由代理层来实现请求和转发
代理proxy
典型的代理分区方案有Twitter开源的Twemproxy和国内的豌豆荚开源的Codis。
Twemproxy
Twemproxy的优点：比较稳定，可用性高。
不足:
1、出现故障不能自动转移，架构复杂，需要借助其他组件（LVS/HAProxy +Keepalived）实现 HA
2、扩缩容需要修改配置，不能实现平滑地扩缩容（需要重新分布数据）。
Codis
Codis是一个代理中间件，豌豆荚公司用GO语言开发的（快三年时间没有更新了）。跟数据库分库分表中间件的Mycat的工作层次是一样的。
功能：客户端连接Codis跟连接Redis没有区别。
| 功能特性 | Codis | Tewm proxy | Redis Cluster |
|---|---|---|---|
| 重新分片不需要重启 | Yes | No | Yes |
| pipeline | Yes | Yes | |
| 多 key 操作的 hash tags () | Yes | Yes | Yes |
| 重新分片时的多key操作 | Yes | — | No |
| 客户端支持 | 所有 | 所有 | 支持cluster协议的客户端 |
分片原理：Codis把所有的key分成了 N个槽（例如1024）,每个槽对应一个分组, 一个分组对应于一个或者一组Redis实例。Codis对key进行CRC32运算，得到一个 32位的数字，然后模以N （槽的个数），得到余数，这个就是key对应的槽，槽后面就
是Redis的实例（跟Mycat的先哈希后范围的算法思想类似）。比如4个槽:
Codis的槽位映射关系是保存在Proxy中的，如果要解决单点的问题，Codis也要做集群部署，多个Codis节点怎么同步槽和实例的关系呢？需要运行一个Zookeeper（或者etcd/本地文件）。
在新增节点的时候，可以为节点指定特定的槽位。Codis也提供了自动均衡策略。Codis不支持事务，其他的一些命令也不支持。
获取数据原理（mget）:在Redis中的各个实例里获取到符合的key,然后再汇总到Codis中。
Codis是第三方提供的分布式解决方案，在官网的集群功能稳定之前，Codis也得到了大量应用。
Redis Cluster
Redis Cluster是在Redis 3.0的版本正式推出的，用来解决分布式的需求，同时也可以实现高可用。跟Codis不一样，它是去中心化的，客户端可以连接到任意一个可用节点。
数据分片有几个关键的问题需要解决：
1、数据怎么相对均匀地分片
2、客户端怎么访问到相应的节点和数据
3、重新分片的过程，怎么保证正常服务
架构
Redis Cluster可以看成是由多个Redis实例组成的数据集合。客户端不需要关注数 据的子集到底存储在哪个节点，只需要关注这个集合整体。
以3主3从为例，节点之间两两交互，共享数据分片、节点状态等信息。
搭建
| 类型 | 命令 |
|---|---|
| 集群 | cluster info :打印集群的信息 cluster nodes :列出集群当前己知的所有节点(node),以及这些节点的相关信息。 |
| 节点 | cluster meet cluster forget <node_id> : 从集群中移除node_id指定的节点(保证空槽道)。 cluster replicate <node_id> : 将当前节点设置为node_id指定的节点的从节点。 cluster saveconfig : 将节点的配置文件保存到硬盘里面 |
| 槽(slot) | cluster addslots cluster delslots cluster flushslots :移除指派给当前节点的所有槽，让当前节点变成一个没有指派任何槽的节点。 cluster setslot cluster setslot cluster setslot cluster setslot |
| 键 | cluster keyslot cluster countkeysinslot cluster getkeysinslot |
问题：Cluster解决分片的问题，数据怎么分布？
数据分布
Redis既没有用哈希取模，也没有用一致性哈希，而是用虚拟槽来实现的。
Redis创建了 16384个槽(slot),每个节点负责一定区间的slot。比如Node1负责 0-5460, Node2 负责 5461-10922, Node3 负责 10923-16383。
对象分布到Redis节点上时，对key用CRC16算法计算再％16384,得到一个slot 的值，数据落到负责这个slot的Redis节点上。
Redis的每个master节点都会维护自己负责的slot。用一个bit序列实现，比如: 序列的第0位是1,就代表第一个slot是它负责；序列的第1位是0,代表第二个slot 不归它负责。
redis-cli -p 7291
redis-cli -p 7292
redis-cli -p 7293
查看key属于哪个slot:
redis> cluster keyslot snail
注意：key与slot的关系是永远不会变的，会变的只有slot和Redis节点的关系。
问题：怎么让相关的数据落到同一个节点上？
比如有些multi key操作是不能跨节点的，例如用户2673的基本信息和金融信息？ 在key里面加入{hash tag}即可。Redis在计算槽编号的时候只会获取{}之间的字符串进行槽编号计算，这样由于上面两个不同的键，{}里面的字符串是相同的，因此他们可以被计算出相同的槽。
user{2673}base=...
user{2673}fin=…
127.0.0.1:7293> set a(sn}a 1
OK
127.0.0.1:7293> set a(sn}b 1
OK
127.0.0.1:7293〉set a(sn}c 1
OK
127.0.0.1:7293〉set a(sn}d 1
OK
127.0.0.1:7293> set a{sn}e 1
OK
问题：客户端连接到哪一台服务器？访问的数据不在当前节点上，怎么办？
客户端重定向
比如在7291端口的Redis的redis-cli客户端操作：
127.0.0.1:7291> set sn 1
(error) MOVED 13724 127.0.0.1:7293
服务端返回MOVED,也就是根据key计算出来的slot不归7291端口管理，而是归7293端口管理，服务端返回MOVED告诉客户端去7293端口操作。
这个时候更换端口，用redis-cli-p 7293操作，才会返回OK。或者用./redis-cli -c -p port的命令。
这样客户端需要连接两次。Jedis等客户端会在本地维护一份slot——node的映射关系，大部分时候不需要重定向，所以叫做smart jedis （需要客户端支持）。
问题：新增或下线了 Master节点，数据怎么迁移（重新分配）？
数据迁移
因为key和slot的关系是永远不会变的，当新增了节点的时候，需要把原有的slot 分配给新的节点负责，并且把相关的数据迁移过来。
添加新节点（新增一个7297）:
redis-cli --cluster add-node 127.0.0.1:7291 127.0.0.1:7297
新增的节点没有哈希槽，不能分布数据，在原来的任意一个节点上执行:
redis-cli --cluster reshard 127.0.0.1:7291
输入需要分配的哈希槽的数量（比如500）,和哈希槽的来源节点（可以输入all或 者 id) 。
问题：只有主节点可以写，一个主节点挂了，从节点怎么变成主节点？
高可用和主从切换原理
当slave发现自己的master变为FAIL状态时，便尝试进行Failover,以期成为新 的master。由于挂掉的master可能会有多个slave,从而存在多个slave竞争成为master 节点的过程，其过程如下：
1 .slave发现自己的master变为FAIL
2.将自己记录的集群currentEpoch加1,并广播FAILOVER_AUTH_REQUEST信息
3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK,对每一个 epoch 只发送一次 ack
4.尝试 failover 的 slave 收集 FAILOVER_AUTH_ACK
5.超过半数后变成新Master
6广播Pong通知其他集群节点
总结：Redis Cluster既能够实现主从的角色分配，又能够实现主从切换，相当于集成了 Replication 和 Sentinel 的功能。
总结
Redis Cluster 特点：
1.无中心架构。
2.数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布。
3.可扩展性，可线性扩展到1000个节点（官方推荐不超过1000个），节点可动态添加或删除。
4.高可用性，部分节点不可用时，集群仍可用。通过增加Slave做standby数据副 本，能够实现故障自动failover,节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升。
5.降低运维成本，提高系统的扩展性和可用性。