阅读目录

1. 背景
2. 虚拟桶(virtual buckets)
3. 实现
4. 总结

背景

关于数据分片讨论最多的是一致性hash，然而它并不是分布式设计中的银弹百试百灵。 在数据稳定性要求比较高的场景下它的缺点是不能容忍的。
比如在Redis分布式缓存设计中，使用一致性Hash进行key分片存储，通过虚拟节点最大化降低添加或删除节点带来的影响。这里强调降低二字，即是它还是有影响的，在一般情况下我们还可以接受。
但是某些场景下要求动态扩容无影响就无法满足了。

上次(探索c#之一致性Hash详解)提到过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<int, RedisGroup> RedisGroups;

private const ulong Slot = ;

 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, );

                var b = BitConverter.ToUInt64(data, );

                ulong hashCode = a ^ b;

                return hashCode;

            }

        }

总结

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

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

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