我们遇到了连续运行在Cassandra中更新计数器的java应用程序的问题。通过监视服务器的负载,我们看不到与负载的任何相关性。查询非常不变,因为它们仅在8个不同的表中更新值。 java应用程序每分钟都会触发数千个查询(可能是20k甚至50k查询),但偶尔会有一些查询失败。当发生这种情况时,我们将它们与异常消息一起写入文件。这条消息总是如此
Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
我们进行了一些谷歌搜索和故障排除,并采取了几项措施:
DefaultRetryPolicy
而不是FallthroughRetryPolicy
,以使客户端在失败时重试查询。 write_request_timeout_in_ms
设置从标准值2000
更改为4000
,然后更改为10000
。 这些操作减少了失败查询的数量,但仍然会发生。从每小时执行的数百万条查询中,我们可以看到在24小时内发生的大约2000次失败查询。所有都具有上面列出的相同例外,并且它们在不同时间发生。
当然,我们从日志中看到,当查询失败时,需要一段时间,因为它正在等待超时并执行重试。
一些事实:
session.executeAsync(statement);
),并通过添加成功和失败的回调来跟踪哪些查询。Java(TM) SE Runtime Environment (build 1.7.0_76-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
我们如何创建群集:
private Cluster createCluster() {
return Cluster.builder()
.addContactPoints(contactPoints)
.withRetryPolicy(DefaultRetryPolicy.INSTANCE)
.withLoadBalancingPolicy(getLoadBalancingPolicy())
.withReconnectionPolicy(new ConstantReconnectionPolicy(reconnectInterval))
.build();
}
private LoadBalancingPolicy getLoadBalancingPolicy() {
return DCAwareRoundRobinPolicy.builder()
.withUsedHostsPerRemoteDc(allowedRemoteDcHosts) // == 3
.build();
}
我们如何创建密钥空间:
CREATE KEYSPACE IF NOT EXISTS traffic WITH REPLICATION = { 'class': 'NetworkTopologyStrategy', 'AMS1': 2, 'WDC1': 2};
示例表(它们看起来都很相似)
CREATE TABLE IF NOT EXISTS traffic.per_node (
node text,
request_time timestamp,
bytes counter,
ssl_bytes counter,
hits counter,
ssl_hits counter,
PRIMARY KEY (edge, request_time)
) WITH CLUSTERING ORDER BY (request_time DESC)
AND compaction = {'class': 'DateTieredCompactionStrategy'};
答案 0 :(得分:2)
许多评论:
Cluster
配置,您应指定本地DC名称 write_request_timeout_in_ms
值。你只是在地毯下扫描问题,你真正的问题不是超时设置Every minute the java applications fires thousands of queries (can be 20k or even 50k queries)
- >简单的数学给出了每个节点~300次插入/秒,假设RF = 1。它不是那么大,但您的插入可能受到硬件的限制。什么是CPU配置(内核数)和磁盘类型(旋转磁盘或SSD)?