一致性哈希 分布式扩容问题

最近公司打算把一个项目用的数据库换成OceanBase（之前用的是Oracle，成本太高）。和OB的技术同学对接的时候，讨论到ObServer集群扩容的问题，如果要新增Group会涉及到数据的整体迁移，因为节点数量变了，分表的Hash值会重新计算，数据就会有一定的流转。这个时间段内是无法对外提供服务的。

这个问题其实和HashMap扩容是一样的，都属于一致性哈希扩容问题。

所以我就在想这种情况真的没有好的解决方案么，于是上网一顿学习，发现没有完美解决方案（即扩容不影响服务）。但是有相对好一些的解决方案，不能说好一些，是好很多。下面我们来看一看：

先简单说一下原理，再举个例子。

• 原理：
  本质就是设置一个很大的底数，这个底数是根据业务量预估的，要求最大业务量的情况下节点数也不会超过底数。比如你的业务目前24个数据库节点就足以支撑了，但是要考虑以后业务不断增长，可以设置一个很大的数，比如1024，不够大就继续，比如3w。
  为什么要设置一个足够大的底数呢，就是因为这个底数一旦设置是不能变的。说到这，相信聪明的小伙伴已经猜个八九不离十了。因为这个底数不会变，所以我们的集群不存在扩容问题，所以数据不存在迁移。是的，如果你部署的节点数就是这个底数的话，那确实如此。但是因为底数是我们预估的一个很大的值，如果放这个多节点在那，那么资源浪费太严重了。
  我们该怎么做呢？
  底数还是不变，但是我们的节点数可以变。一个节点可以对应多个底数。

• 举个例子：
  假设我只有3台服务器，我的底数是3w。我算hash的时候依旧取模3W，然后，0-1W分一台，1-2W分一台，2-3W分一台 （一致性哈希算法）
  扩容的时候，我把0-5000分给新的机器，5000-1W给原来的机器。加入这台机子以后大部分服务(1-2w和2-3w的两个节点)是可用的。只有0-5000的节点短时间内无法查询和写入，只有等加入的机制同步完成0-5000的数据才能使用，影响小了很多。

• 总结：
  没错，扩容还是得要重新计算hash并迁移数据，但是影响小了很多，原有的大部分节点还是可以正常提供服务的。