java - Cassandra 删除操作有时无法在删除后选择数据

Question

我有两个表

CREATE TABLE IF NOT EXISTS QueueBucket (
    queueName   text,
    bucketId    int,
    scheduledMinute timestamp,
    scheduledTime timestamp,
    messageId   uuid,
    PRIMARY KEY ((queueName, bucketId, scheduledMinute), scheduledTime, messageId)
)  WITH compaction = { 'class' :  'LeveledCompactionStrategy'  } AND speculative_retry='NONE' ;

CREATE TABLE IF NOT EXISTS InDelivery (
    queueName       text,
    nodeId        uuid,
    dequeuedMinute    timestamp,
    messageId       uuid,
    bucketid        int,
    dequeuedTime    timestamp,
    PRIMARY KEY ((queueName, nodeId,bucketId, dequeuedMinute),dequeuedTime, messageId)
);

在代码中，我执行插入 QueueBucket 并批量删除未交付(已记录)。但是在负载测试期间，尽管插入到 QueueBucket 中是有效的，但有时如何从未交付中删除有时不起作用。为确认已应用读取未送达检查，如果 messageId 仍然存在，则立即读取已删除的 messageId 并打印 WARN 日志。

    queueDao.insertMsgInfo(queueName, bucketId, QueueUtils.getMinute(scheduledTime), scheduledTime, messageId);
    queuDao.deleteInDelivery(queueName, nodeId, bucketId, bucketMinute, dequeuedTime, messageId);
    if(queueServiceMetaDao.hasIndeliveryMessage(inDeliveryPK)) {
        log.warn("messageId  {} of queue {} bucket {} with node {} dequuedTime {} dequeud minute {} could not get deleted from indelivery.",
                messageId,queueName,bucketId, nodeId,QueueUtils.dateToString(dequeuedTime),QueueUtils.dateToString(bucketMinute));
        }

在 insertMsgInfo 和 deleteInDelivery 方法中，我正在重用准备好的语句。

"INSERT INTO queuebucket (queuename, bucketid , scheduledminute, scheduledtime, messageid ) VALUES ( ? , ? , ? , ? , ? );"
"DELETE FROM indelivery WHERE queuename = ? AND nodeId = ? AND bucketId=? AND dequeuedMinute=? AND dequeuedTime =? AND messageId=? ;"

在 hasIndeliveryMessage 中，我将相同的值传递到 inDeliveryPrimaryKey 中，因为我在 moveBackToQueueBucket 方法中删除了未送达数据。

"SELECT messageId FROM indelivery WHERE queuename = ? AND nodeId = ? AND bucketId=? AND dequeuedMinute=? AND dequeuedTime=? AND messageId=? ;"

我不知道为什么我会看到多个警告消息“无法从未送达中删除。” .请帮忙

I am using cassandra version 2.2.7 it is 6 node cassandra cluster with replication factor 5 and read and write consistency used is QUORUM.

我还浏览了链接 Cassandra - deleted data still there和 https://issues.apache.org/jira/browse/CASSANDRA-7810但是这个问题很久以前就已经修复了。在 2.0.11 中。

进一步更新 根据Cassandra - Delete not working我也运行了 nodetool repair 但问题仍然存在。我也应该运行 compact 吗？

进一步更新:我不再使用批处理，我只是简单地插入到 queuebucket 中并删除未交付的数据，然后读取数据，但问题仍然存在

添加一些日志:

2016-07-19 20:39:42,440[http-nio-8014-exec-12]INFO  QueueDaoImpl -deleting from indelivery queueName pac01_deferred nodeid 1349d57f-28f5-37d4-9fe1-dfa14dba4a9f bucketId 382 dequeuedMinute 20160719203900000 dequeuedTime 20160719203942310 messageId cc4fb158-f61e-345b-8dcf-3f842fe52d50:
2016-07-19 20:39:42,442[http-nio-8014-exec-12]INFO  QueueDaoImpl -Reading from indelivery : queue pac01_deferred nodeId 1349d57f-28f5-37d4-9fe1-dfa14dba4a9f dequeueMinute 20160719203900000 dequeueTime 20160719203942310 messageid cc4fb158-f61e-345b-8dcf-3f842fe52d50 bucketId 382 indeliveryRow Row[cc4fb158-f61e-345b-8dcf-3f842fe52d50]
2016-07-19 20:39:42,442[http-nio-8014-exec-12]WARN  QueueImpl -messageId  cc4fb158-f61e-345b-8dcf-3f842fe52d50 of queue pac01_deferred bucket 382 with node 1349d57f-28f5-37d4-9fe1-dfa14dba4a9f dequuedTime 20160719203942310 dequeud minute 20160719203900000 could not get deleted from indelivery .

我应该尝试将 cosnsistency ALL 吗？？？

Answer 1

首先，使用 Cassandra 支持队列或类似队列的结构是一种已知的反模式。如果您的队列处理高吞吐量，您将与墓碑作斗争并降低查询性能。

至于您的实际问题，我以前曾在使用时间戳作为键的模型中看到过这种情况。您如何为 dequeuedMinute 和 dequeuedTime 创建时间戳值？

如果您自己将时间戳放在一起，那么删除它们应该很容易。但是，如果您使用 dateOf(now()) 或 Java.Util.Date 创建它们，那么您的时间戳将存储毫秒数。尽管 cqlsh 会向您掩盖这一点:

INSERT INTO InDelivery (queuename, nodeid, bucketid , dequeuedMinute, dequeuedTime, messageid )
VALUES ('test1',uuid(),2112,dateof(now()),dateof(now()),uuid());

INSERT INTO InDelivery (queuename, nodeid, bucketid , dequeuedMinute, dequeuedTime, messageid )
VALUES ('test1',a24e056a-94fa-4aee-b3a7-a8df6060091a,2112,'2016-07-19 09:57:16-0500','2016-07-19 09:57:16-0500',uuid());

SELECT queuename,nodeid,dequeuedMinute,blobasbigint(timestampasblob(dequeuedMinute)),             
dequeuedTime,blobasbigint(timestampasblob(dequeuedTime)),messageid
FROM InDelivery;

 queuename | nodeid                               | dequeuedMinute                | blobasbigint(timestampasblob(dequeuedMinute)) | dequeuedTime             | blobasbigint(timestampasblob(dequeuedTime)) | messageid
-----------|--------------------------------------+-------------------------------+-----------------------------------------------+--------------------------+--------------------------------------+---------------------------------------------
     test1 | a24e056a-94fa-4aee-b3a7-a8df6060091a | 2112 2016-07-19 09:57:16-0500 |                                 1468940236000 | 2016-07-19 09:57:16-0500 |                               1468940236000 | 7ca1f676-9034-45ba-bb3f-377ba74cc5c0
     test1 | a24e056a-94fa-4aee-b3a7-a8df6060091a | 2112 2016-07-19 09:57:16-0500 |                                 1468940236641 | 2016-07-19 09:57:16-0500 |                               1468940236641 | 9721d96e-d6f5-43a7-9ba4-18ef4d54ab8a
(2 rows)

那些时间戳看起来一样，对吧？但是应用 blobasbigint(timestampasblob( 嵌套函数揭示了差异(000 与 641 毫秒)。

请注意，如果我更改我的 SELECT 以过滤 641 毫秒(blobasbigint(timestampasblob( 列中的最后 3 位数字)我得到具有毫秒的行.

SELECT queuename,nodeid,dequeuedMinute,blobasbigint(timestampasblob(dequeuedMinute)),             
dequeuedTime,blobasbigint(timestampasblob(dequeuedTime)),messageid
FROM InDelivery
WHERE queuename='test1' AND bucketid=2112 
AND nodeid=a24e056a-94fa-4aee-b3a7-a8df6060091a
AND dequeuedMinute='2016-07-19 09:57:16.641-0500';

 queuename | nodeid                               | dequeuedMinute                | blobasbigint(timestampasblob(dequeuedMinute)) | dequeuedTime             | blobasbigint(timestampasblob(dequeuedTime)) | messageid
-----------|--------------------------------------+-------------------------------+-----------------------------------------------+--------------------------+--------------------------------------+---------------------------------------------
     test1 | a24e056a-94fa-4aee-b3a7-a8df6060091a | 2112 2016-07-19 09:57:16-0500 |                                 1468940236641 | 2016-07-19 09:57:16-0500 |                               1468940236641 | 9721d96e-d6f5-43a7-9ba4-18ef4d54ab8a
(1 rows)

底线是，如果您要使用时间戳键存储毫秒数，那么您还需要在通过这些键SELECT/DELETE 时包含它们。同样，如果您没有在您的时间戳键上存储毫秒，那么您不能在您通过这些键SELECT/DELETE时包含它们。