我是 Cassandra 的新手。我正在阅读 cassandra.yml 文件中虚拟节点的 num_tokens 参数。我认为我不太了解这是在做什么或如何分配令牌/分区。这里到底发生了什么？
如果我们真的在谈论令牌/节点的数量，那么默认值 256 没有任何意义。 num_tokens 真的是 num_token_partitions/node 吗？
让我们首先选择 2 个节点 A 和 B，添加第 3 个节点 C，然后尝试解释事情是如何工作的。首先，每个节点都配置了 256 个 num_tokens。现在，当 A 和 B 出现时
为了大家的利益，有没有好心人详细说明一下？
【问题讨论】：
4) 分区范围是通过授予每个节点从其可用令牌到下一个指定令牌的范围来确定的。
2) 数据通过八卦进行交换，详细说明哪些节点拥有哪些令牌。该元数据允许每个节点知道哪些节点负责哪些范围。 Keyspace/Replication 设置也会改变数据的实际保存位置。
示例： 1)A 获得 256 个范围 B 获得 256 个范围。但为了简单起见，让我们给他们每人 2 个标记，并假设标记范围是 0 到 30
给定代币：A 10,15 和 B 3,11 节点负责以下范围
(3-9:B)(10:A)(11-14:B)(15-30,0-2:A)
3)如果 C 也加入 2 个标记 20,5 节点现在将负责以下范围
(3-4:B)(5-9:C)(10:A)(11-14:B)(15-19:A)(20-30,0-2:C)
Vnodes 很强大，因为现在当 C 加入集群时，它从多个节点（B 的 5-9 和 A 的 20-30,0-2）获取数据，在这些机器之间分担负载。在这个玩具示例中，您可以看到只有 2 个令牌允许一些节点托管大部分数据，而其他节点几乎没有。随着 Vnode 数量的增加，节点之间的平衡随着范围变得越来越随机细分而增加。在 256 个节点上，您极有可能向集群中的每个节点分发了均匀数量的数据。
更多信息 虚拟节点：http://www.datastax.com/dev/blog/virtual-nodes-in-cassandra-1-2
【讨论】：
(0-7:A)(8-15:B)(16-23:A)(24-30:B)。谢谢！
RussS 的答案也是正确的，我认为这很难理解。
这个想法不是令牌分配，因为这是 Cassandra 用于分配数据访问权概念的技术手段。
重要的是复制因子和环以了解其意义。
复制的工作方式是通过将一个节点的数据复制到接下来的两个上。因此，如果您在节点 A 上，分配给 A 的数据会复制到 B 和 C。分配给 B 的数据会复制到 C 和 D，依此类推。
如果您只有 3 个节点和 3 个副本，则没有任何区别。
如果您有 100 个节点，即 3 个和num_tokens: 1 的复制，那么恰好有 3 个节点复制分配给它们的数据，并且这始终是一个节点的整个数据集。在上面的示例中，这意味着分配给 A 的所有数据都可以从 A、B 或 C 读取，并且只能从这三个节点读取。因此，如果您尝试经常加载特定数据而其余的数据不经常加载，那么您的集群将相当不平衡。
使用 v-nodes，数据在子分区中被分解。一台计算机代表许多虚拟节点。所以旧计算机 A 现在可以代表 A、D、G、J、M 假设 num_tokens: 5。
接下来是戒指。构建环时，计算机将相互连接，以使同一台计算机不会连接到自身（A 不会直接与 D 对话，反之亦然。）
现在，这意味着一台物理计算机将连接到num_tokens × replication_factor - 1 其他计算机。因此，num_tokens 设置为 5，复制为 3，您将连接到其他 10 台计算机。这意味着负载将在 10 台计算机而不是 3 台计算机之间共享（因为复制因子会暗示。）
所以对于 16 个节点，num_tokens: 256 和 replication: 3，这将是一个奇怪的设置，因为这意味着所有节点彼此之间连接了 512 次。话虽如此，稍后必须更改num_tokens 可能需要一些时间让集群适应新值。特别是如果您有大型安装。因此，如果您预计会有大量节点，那么从一开始就使用相当大的 num_tokens 是个好主意。
作为副作用，它还会在每个节点上的各种表（文件）之间分发数据。这也有助于更快地查找数据。实际上，建议您在创建 Elassandra 集群时使用更大数量的实例（16 到 64 个）以简化搜索。
【讨论】：
在 256 个节点上，您极有可能向集群中的每个节点分配了均匀数量的数据。
除非当然不是。随机 Vnode 令牌范围分配与负载均衡无关。平衡负载是令牌范围 ENGINEERED 被平衡，而不是猜测。
然后是令牌范围分配中的错误 CASSANDRA-6388 和 CASSANDRA-7032 目前在生产中运行的任何集群中都没有修复。然后是 256 个 VNODE 集群的主要问题，并试图重建或备份它们，从字面上看，这是不可能的。
重建和恢复需要数周时间。只需尝试在生产中针对 vnode 运行 hadoop。放弃为 VNODE 设计的令牌范围集群，后果自负。
【讨论】：