关于Twitter或Instagram设计 基于UserID的分片：我们可以尝试将用户的所有数据存储在一台服务器上。在存储时，我们可以将UserID传递到哈希函数，该哈希函数会将用户映射到数据库服务器，在该服务器中我们将存储用户的所有推文，收藏夹，关注等。在查询用户的推文/关注/收藏夹时，我们可以问我们的哈希函数，我们在哪里可以找到用户的数据，然后从那里读取数据。这种方法有两个问题：
如果用户变热怎么办？拥有该用户的服务器上可能有很多查询。高负载将影响我们的服务性能。 随着时间的流逝，与其他用户相比，某些用户最终可能会存储很多推文或拥有大量关注。维持不断增长的用户数据的均匀分布非常困难。 为了从这些情况中恢复，我们必须重新分区/重新分配数据或使用 基于TweetID的分片：我们的哈希函数会将每个TweetID映射到随机服务器，我们将在其中存储该Tweet。要搜索推文，我们必须查询所有服务器，并且每个服务器都将返回一组推文。集中式服务器将汇总这些结果，以将其返回给用户。让我们看一下时间轴生成示例；这是我们的系统生成用户时间轴必须执行的步骤数：
我们的应用程序（app）服务器将找到用户关注的所有人员。 应用服务器会将查询发送到所有数据库服务器，以查找来自这些人的推文。 每个数据库服务器都将找到每个用户的推文，并按新近度对它们进行排序，然后返回最上面的推文。 应用服务器将合并所有结果，并再次对其进行排序，以将最重要的结果返回给用户。 这种方法解决了热用户的问题，但是与通过UserID进行分片相比，我们必须查询所有数据库分区以查找用户的tweet，这可能会导致更高的延迟。
我的问题是，一致性哈希在这里有何帮助？一致的哈希创建了一个环，并试图将具有虚拟副本的均匀分布的服务器放入服务器。一致的哈希对流行的tweetID或热门区域有何帮助？
答案 0 :(得分：0)
https://www.toptal.com/big-data/consistent-hashing
在添加和删除服务器而不重新散列所有数据库时，连续散列很有用，只是仅所需的映射部分将平均散列平均为k / n大小，其中k是数据键，n是服务器数。