分布式系统hash策略
分布式系统的hash策略，决定了数据的分布。传统的方式采用mod n的算法，非常简单，但是一旦节点发生变化，所有的数据都需要重组，代价非常大。一致性哈希(Consistent hash)很好的解决了这个问题，当节点发生变化时，只会影响到部分数据，而且永远可以找到一个提供服务的节点。
对于数据库Sharding的架构，Consistent hash并不十分适合，我们采用了一种新的hash策略，我将其称之为“Virtual Partition Hash”策略。
为了解决节点数量变化时，全部数据需要重组的问题，我们采用了预分区的策略，将整个系统分为很多个Virtual Partition，每个物理节点由多个Virtual Partition组成。比如整个系统分为128个VP，共有8个物理的服务器，每个服务器包含16个VP的数据，只要整个系统的物理节点小于128个，增加节点只需要移动部分VP就可以了，避免了数据重组的问题。另外，为了提高可用性，每个物理节点都有一套备机，如果节点失效则切换至备用节点。
新增一个物理节点：
只需要移动部分VP至新节点，不需要数据重组。
Virtual partition hash策略非常简单，实现也很容易，实际上它是Consistent hash策略的一个简化版本，Oracle hash分区也是类似的做法，尽可能的减少数据重组的代价，可以参考我以前的文章《Oracle hash分区的秘密》。
这个策略的另外一个好处是非常灵活，可以根据服务器压力的情况，通过移动VP的来达到负载均衡的目的。利用MySQL数据库复制的特性，移动VP是非常容易的，而且配合我们的分布式数据库架构，可以做到对应用透明。
这个方案的缺点是：每个节点都准备一台备机，硬件资源比较浪费。但是如果可以和读写分离架构配合起来，备机可以承担部分读的服务，那么这个缺点就不存在了。
“Simple but Incomplete Solutions Win！”
—EOF—
这一招我最早是在hibernate的sharding中看到的，想想确实管用，相比之下维护多一点的schema总比移动数据强
道理其实都是差不多的,,
将数据的单元打的足够小, 个别单元出问题, 迁移的代价就会小很多, 带来的问题是如何有效的管理这些单元(节点), 一致性散列(consistent hash)通过Ring来实现, 我们的sharding 方案是通过中央的mapping来实现, 或者也可以通过简单的配置策略来实现,,毕竟1024个节点也不会占用太多信息..
这可能也是为什么Google 的BigTable,Amazon的Dynamo一个集群节点总数基本上都在1024以内的部分原因吧..
呵呵，原理是差不多的，这个策略的特点是简单，实现容易。
consistent hash 无处不在