一致性hash算法的特点
|
|-1.采用一致性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。
| 采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。
| 一致性哈希只影响相邻节点key分配，影响量小。
|
|-2.为了避免一致性哈希只影响相邻节点造成节点分配压力，
| ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。
| 根据权重weight，也可虚拟化出160倍数的虚拟节点。
| 用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。
|
|-3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，
| 这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。
虚拟节点
|
|-考量 Hash 算法的另一个指标是平衡性 (Balance) ,引入虚拟节点改善平衡性
|
|-一个实际节点对应了若干个“虚拟节点”，这个对应个数也成为“复制个数”，“虚拟节点”在 hash 空间中以 hash 值排列。
Redis Sharding采用客户端Sharding方式，服务端Redis还是一个个相对独立的Redis实例节点，没有做任何变动。
同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方法。
作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。
但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。
有没有其它手段改善这种情况？Redis作者给出了一个比较讨巧的办法–presharding.
presharding及主备模式
|
|-即预先根据系统规模尽量部署好多个Redis实例，这些实例占用系统资源很小，一台物理机可部署多个，让他们都参与sharding，
| 当需要扩容时，选中一个实例作为主节点，新加入的Redis节点作为从节点进行数据复制。
| 数据同步后，修改sharding配置，让指向原实例的Shard指向新机器上扩容后的Redis节点，同时调整新Redis节点为主节点，原实例可不再使用。
|
|-presharding是预先分配好足够的分片，扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。
| 参与sharding的分片没有改变，所以也就不存在key值从一个区转移到另一个分片区的现象，只是将属于同分片区的键值从原Redis实例同步到新Redis实例。
|
|-并不是只有增删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。
| 在《Redis持久化》一文中已提到，
| 为不影响Redis性能，尽量不开启AOF和RDB文件保存功能，可架构Redis主备模式，主Redis宕机，数据不会丢失，备Redis留有备份。
|
|-这样，我们的架构模式变成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。
| 主备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。
|
|-Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。