我正在为一个需要从小规模开始但具有高度可扩展性的应用程序进行早期设计。我特别担心用户数据库，在这种情况下，它会有很高的 INSERT 和 UPDATE 负载，并且不太可能在单个主服务器上存活很长时间。
（虽然我的问题与任何特定的 RDBMS 无关，但作为记录，我们将使用 MySQL，而 MySQL Cluster 并不能真正满足我们的需求，因此我们需要使用库存 MySQL + 在这个解决方案上推出我们自己的解决方案InnoDB。）
我正在考虑基于用户名的哈希在 MySQL 主服务器之间分配用户的策略（加上用户未知的盐，就像对任何有趣的游戏增加保险一样）。我以前曾成功使用过这样的解决方案，但我自己从未设计/实现过。
我想要一些输入的是：
1) 合适的散列算法。我希望 SHA-1 甚至 MD5 可以很好地解决这个问题，因为加密安全性确实不是目标，但我不确定是否有其他算法可能具有此类问题的理想属性。快一点的东西也可能很好。
2）任何人都可以想到的任何主要警告。（我已经非常清楚潜在的连接池问题，以及向池中添加新主节点和迁移受影响用户的乐趣。）
谢谢！
基于哈希的解决方案的问题是移动用户。考虑以下场景 - 您有 3 个用户和 3 个服务器。用户 A 有一个哈希，导致他们的连接被您的软件分配给服务器 A，用户 B 连接到服务器 B，用户 C 连接到服务器 C。如果服务器 B 出现故障，或者您想将用户 B 迁移到新服务器 D，因为服务器 B 超载 - 你不能，因为你的软件被编码为获取用户名的散列，并连接到基于该用户名的服务器。
此外，您还会遇到分配问题 - 用户 A、B 和 C 的哈希可能很好地解析到服务器 A，因此服务器 B 和 C 处于空闲状态。
我个人会在所有服务器之间复制用户数据库表，然后在启动时随机连接到服务器，找到他们实际的数据库服务器，然后继续。这样您就可以轻松地移动用户，并且如果您在至少两台服务器之间复制数据，那么如果一台服务器发生故障，您就有了冗余。
首先，我有责任告诉你，如果你足够认真地考虑设计，你可能不需要分片。分片是最后的手段。这是 Percona 的 Baron Swartz 谈论的（不要错过幻灯片的直接链接）：http ://www.percona.tv/performance/baron-schwartz-high-performance-mysql-from-a-boring-architecture-ppc -2009
到实际的建议。
要考虑的一件事是您将如何重新平衡您的应用程序。您从 3 个节点开始；在某些时候，您会添加第四个。如何迁移四分之一的数据？通过重新散列每个用户？可能是个坏主意。要考虑的一件事是划分为多个编号模式，并将模式编号散列到数据库机器。这样，您可以通过仅移动需要触及的模式进行迁移，而不是重新散列所有数据。由于模式的数量（数量级）大于机器的数量，因此您也不能依赖散列来查找数据库机器，而是使用可以为迁移更新的静态映射。这样你也可以在每台机器上使用非均匀的模式分布，
您仍然需要将用户映射到模式。我一直在阅读的一个有趣的方法不是散列到存储桶，而是使用2 个散列函数散列到 2 个存储桶，并选择负载最少的（按用户数、记录数或其他指标）两个作为你的目标。这会导致分布更加均匀，但是当您需要为用户取回数据时会产生检查它们的开销。这可以通过缓存来缓解，但仍然如此。不过，有些事情要考虑。
您可能想要考虑复制分片 - 可能是异步的，作为后台进程，用于热备份。
最后，您是否考虑过替代技术？各种 BigTable 克隆虽然不提供关系模型，但对于读取和写入都具有非常好的扩展特性。查看Cassandra和HBase。