Token Aware Astyanax 连接池在节点上连接而不在节点上分配连接答案

【问题标题】：Token Aware Astyanax Connection pool connecting on nodes without distributing connections over nodesToken Aware Astyanax 连接池在节点上连接而不在节点上分配连接
【发布时间】：2014-01-05 22:47:38
【问题描述】：

我使用 astyanax 连接池定义如下：

ipSeeds = "LOAD_BALANCER_HOST:9160";
conPool.setSeeds(ipSeeds)
.setDiscoveryType(NodeDiscoveryType.TOKEN_AWARE)
.setConnectionPoolType(ConnectionPoolType.TOKEN_AWARE);

但是，我的集群有 4 个节点，并且有 8 台客户端计算机连接在上面。 LOAD_BALANCER_HOST 将请求转发到我的四个节点之一。

在客户端节点上，我有：

$netstat -an | grep 9160 | awk '{print $5}' | sort |uniq -c
    235 node1:9160
    680 node2:9160
      4 node3:9160
      4 node4:9160

因此，虽然 ConnectionPoolType 是 TOKEN_AWARE，但我的客户端似乎主要连接到 node2，有时连接到 node1，但几乎从不连接到节点 3 和 4。
问题是：为什么会这样？令牌感知连接池不应该在环中查询节点列表并使用循环算法连接到所有活动节点吗？

【问题讨论】：

您为密钥空间配置了哪些复制因子？您选择了哪种复制策略？您确定您的客户正在访问范围广泛的行键，还是他们主要关注您的测试中的一两个？
我正在使用复制因子 2 和复制策略网络。
我确定我使用了广泛的行键，但是行的存储位置应该与连接无关，对吧？还是我错了？
“令牌感知”策略应尝试仅联系实际存储数据的节点。您使用的是 RF=2，因此对于任何给定的令牌（行键的哈希），您的四 (4) 个节点中有两 (2) 个保存该令牌的数据。对于任何给定的请求，客户端上正确运行的令牌感知策略只会联系这两个节点之一。令牌感知与简单的循环不同。
之前我没问你用的是什么分区器；这也很重要。 Cassandra 开箱即用，使用分区器根据行键的哈希值在环周围随机存储数据。如果您确实在访问范围广泛的行键，我通常希望负载在集群中保持平衡。但是，如果您配置了一个保留顺序的分区器，那么您的行将不会均匀分布，并且您会出现热点。

标签： cassandra astyanax amazon-elb cassandra-2.0

【解决方案1】：

William Price 是完全正确的：事实上您使用的是 TokenAwarePolicy 并且可能是默认的 Partitioner 意味着 - 首先，您的数据将有偏差地存储在您的节点上，并且 - 然后在查询LoadbalancingPolicy 时让您的驱动程序记住要请求的正确节点

您可以通过使用一些偏差或自定义分区器来平均分配您的数据来提高集群的性能。要随机查询节点，请使用

RoundRobinPolicy (http://www.datastax.com/doc-source/developer/java-apidocs/com/datastax/driver/core/policies/RoundRobinPolicy.html) 或
DatacenterAwareRoundRobinPolicy (http://www.datastax.com/doc-source/developer/java-apidocs/com/datastax/driver/core/policies/DCAwareRoundRobinPolicy.html)。

当然，后者需要在您的密钥空间中定义数据中心。

如果没有任何进一步的信息，我建议将分区器更改为 TokenAware 负载平衡策略通常是一个好主意。主要负载最终将在这些节点上结束 - TokenAware 策略让您更快地找到正确的协调器。

【讨论】：