阅读目录

背景

关于数据分片讨论最多的是一致性hash，然而它并不是分布式设计中的银弹百试百灵。 在数据稳定性要求比较高的场景下它的缺点是不能容忍的。

比如在Redis分布式缓存设计中，使用一致性Hash进行key分片存储，通过虚拟节点最大化降低添加或删除节点带来的影响。这里强调降低二字，即是它还是有影响的，在一般情况下我们还可以接受。

但是某些场景下要求动态扩容无影响就无法满足了。

上次()提到过Hash取模的分片算法，是把数据mod后直接映射到真实节点上面，这造成节点个数和数据的紧密关联、后期缺乏灵活扩展。

而一致性Hash分片算法多增加一层虚拟映射层，数据与虚拟节点映射、虚拟节点与真实节点再映射。

虚拟桶(virtual buckets)

虚拟桶是取模和一致性hash二者的折中办法。

• 采用固定节点数量，来避免取模的不灵活性。
• 采用可配置映射节点，来避免一致性hash的部分影响。

其运行机制如下：

key对虚拟桶层

虚拟桶层采用预设固定数量，比如楼主在项目中预设N=1024。意味之后这个分布式集群最大扩容到1024个节点，带来的好处就是mod后的值是不变的(非常重要)，这保证了第一层映射挖宝去不受实际节点变化的影响。 关于最大数量，可根据实现需要预先定义好即可，比如Redis官方的糟最大65000个节点，豌豆荚的codis默认也是1024个节点。 当然如果数据量超过1024节点存储时，可以再起另外个集群应对。

虚拟桶对实际节点

举个例子，项目刚开始使用时配置节点映射：

Redis Server1对应桶的编号为0到500。

Redis Server2对应桶的编号为500到1024。

缓存数据量增长后需要增加新节点，在加之前需要重新分配节点对应虚拟桶的编号。 比如增加server3并配置对应桶的编号400到600，这时对于key映射虚拟桶层完全无影响。  实际上mod 400到600的真实数据还在另外两台节点上，请求过来后还会发生无法命中的影响。

这就要求在增加新节点前，需要在后台把另外二台的400到600编号数据拷贝到新节点上面，完成后再添加配置到映射上面。 因为新来请求会命中到新节点，所以另外2台的400到600编号数据就无用了，需要进行删除。这种做法就能最大限度(100%)的保证动态扩容后，对缓存系统无影响。

实现

算法实现这块比较简单，数据迁移、配置等这块需要单独的系统来做。

private Dictionary
     
       RedisGroups;private const ulong Slot = 1024; public RedisGroup GetGroup(string key)        {            var longVal = Md5Hash(key);            var index = (int) (longVal%Slot);            return RedisGroups[index];        }        public ulong Md5Hash(string key)        {            using (var hash = System.Security.Cryptography.MD5.Create())            {                byte[] data = hash.ComputeHash(Encoding.UTF8.GetBytes(key));                var a = BitConverter.ToUInt64(data, 0);                var b = BitConverter.ToUInt64(data, 8);                ulong hashCode = a ^ b;                return hashCode;            }        }
     

总结

采取虚拟桶这种预分片的算法，可以避免一致性hash扩容时引起的缓存不命中。文中使用1024个实例作为最大节点数量，实际中是完全足够用的。如果以后可能超过这个数量，可以部署另外一套1024节点的集群，最后形成一个超大规模的redis集群。

关于Redis的整套解决方案可以参考使用豌豆荚的codis。

分享了项目中一些使用经验，希望对大家有所帮助。