客户端分片(sharding)

在 redis 推出官方集群技术之前 , sharding方案被广泛的使用. 其主要的思想是客户端进行访问时 , 采用哈希算法将Redis数据的key进行散列 , 通过hash函数 , 将特定key的请求映射到特定的节点上 . 这样的话客户端在每一次请求的时候 , 就知道该访问哪一个节点。

Jedis客户端已经实现了客户端分片功能
1.Jedis客户端采用一致性哈希算法 , 将key和节点的name同时hashing , 然后进行映射匹配 , 采用的算法是murmur_hash . 采用一致性哈希主要的原因是 , 当增加或减少节点时 , 不会产生rehashing , 一致性哈希只影响相邻的两个节点 , 关于一致性哈希算法 , 我会在后面的文章里展开。
如下图示 , node1 , node2 , node3 , 是完全独立的三个实例 , 三个实例之间互不通讯

client_sharding

2.为了避免一致性哈希只影响相邻节点造成节点分配压力 , ShardedJedis会对Redis节点根据名字虚拟化出160个虚拟节点进行散列 .根据权重 weight , 也可虚拟化出160倍数的虚拟节点。用虚拟节点再做映射匹配 , 可以在增加或者减少Redis节点时 , key在各Redis节点移动再分配更均匀 , 而不是只有相邻节点受影响。

sharding + sentinel

通过上面的案例 , 我们成功的将对redis单个节点的访问 , 分散到了三个节点上面 , 但是每个节点依然可能存在单点故障问题.
当一个节点出现了故障的时候 , 我们的客户端就无法访问到这个节点内的数据 .

这个时候 , Redis为我们提供了Master-slave的主从复制功能 , 针对每一个主节点 , 提供一个从节点进行数据的复制 , 当主节点宕机的时候 , 我们可以进行主从节点的切换 , 以保障Redis服务的高可用 .

那么这个时候 , 我们是怎么进行主从的切换的呢 ? sentinel集群 与 Redis集群 , 是可以完全独立部署的 , 当一个主节点挂掉以后 ,

Redis 自身提供了主从复制的功能 ,

sentinel