一年前——未来两年，系统预估总订单量将达到1亿左右。按单张Mysql表存储500万条记录计算，暂时不用分库。单库30个分表是比较合适的水平分表方案。于是，小惠设计了这样一个分表逻辑：订单表在单个数据库中创建30个分表，将用户ID和30取模，取模的结果决定记录存放在哪个分表中查询时需要用户ID作为条件，根据取模的结果确定查询哪个分表和分表如下图（为了描述方便，简化为5个分表）：两个月后——半年多后——小灰的记忆告一段落——1.首先，我们将全缓存空间看成一个环形存储结构。环形空间一共分为2^32个缓存区，在Redis中，缓存键分配到16384个槽位。2、每个缓存key可以通过Hash算法转化为一个32位的二进制数，对应于环空间中的某个缓存区域。我们将所有缓存键映射到环空间中的不同位置。3、我们每个缓存节点（Shard）也遵循同样的Hash算法，比如用IP做Hash，映射到环空间。4、如何让key对应到节点？很简单，每个key顺时针方向最近的节点就是key所属的存储节点。因此图中，key1存放在node1中，key2，key3存放在node2中，key4存放在node3中。1.增加节点当缓存集群中的节点数量增加时，整个环空间的映射仍会保持一致性哈希的顺时针规则，因此会影响少量key的归属。哪些键会受到影响？图中新增了一个节点node4，它位于node1和node2之间。按照顺时针规则，node1和node4之间的缓存不再属于node2，而是属于新的节点node4。所以受影响的键只有key2。最后将key2的缓存数据从node2迁移到node4，形成新的符合一致性哈希规则的缓存结构。2.删除节点当缓存集群中的某个节点需要删除时（例如节点挂掉），整个环空间的映射也会保持一致性哈希的顺时针规则，少数节点的归属键也会受到影响。哪些键会受到影响？图中删除了原来的节点node3。按照顺时针规则，原本属于node3的缓存数据需要“委托”给node3的顺时针后继节点node1。所以受影响的键只有key4。最后将key4的缓存数据从node3迁移到node1，形成新的符合一致性哈希规则的缓存结构。如上图，如果node1的ip是192.168.1.109，那么原node1节点在环空间中的位置就是hash("192.168.1.109")。我们在node1的基础上搭建两个虚拟节点，node1-1和node1-2。可以使用（IP+后缀）计算出虚拟节点在环空间中的位置，例如：hash("192.168.1.109#1"),hash("192.168.1.109#2")此时，有环空间中没有物理节点node1、node2，只有虚拟节点node1-1、node1-2、node2-1、node2-2。由于虚拟节点数量众多，缓存键和虚拟节点之间的映射关系变得相对平衡。
