tikv raw api del put操作希望得到更多的执行反馈信息

我们系统想使用tikv集群存储元数据,想了解下tikv能不能跟踪写请求(RawDelete、RawPut)的执行顺序?

现在有个需求是希望客户端对 相同的KEY 调用RawDelete或RawPut接口的时候不仅能知道执行结果,也想知道内部执行的顺序。

我们的业务场景是这样的:
对同一个key操作后是以多版本保留的,假如操作顺序是put keya -> del keya -> put keya后多版本状态为:
version = 1,keya put
version = 2,keya del
version = 3,keya put
所以为保持tikv存储的数据状态和多版本的最终状态(最大version)一致需要tikv返回具体的执行序列号,将序列号做为业务版本(version)排序后能保持数据版本内外一致(tikv内部和业务)。

看了部分tikv的代码了解到有可能支持这一需求的是将raft阶段对应的 commit index或apply index返回给客户端,raft是顺序执行的,commit index或apply index应该就代表了请求的执行顺序,我是这么理解的,当然还要考虑region分裂的问题。

这样做是否有可行性或该怎么做,望指教:pray:

请问一下
keya put version = 1
keya del version = 2
keya put version = 3
这个中的 version 是你们业务上的版本还是你理解的 TiKV 中存储会带上 version?
通过 raw api 往 TiKV 写入数据的时候,是不会涉及到获取 tso 以及 mvcc 的,所以 TiKV 是没有存储版本信息的。

所以集群内只有一条 keya 的记录。

业务上的version,我们希望的就是TIKV能返回实际执行的序列号,最终把这个序列号作为业务的版本,RAW API是没有版本概念,所以在想是否可以改造下TIKV将实际执行的时候的序列带回给客户端。

集群最终只有最后执行的那条操作,假如这个序列号能返回,业务上也按序列号排序,最终存储下来的和TIKV集群中的就一致了,是为了达到这一目的。

谢谢

目前没有这个功能,可能需要业务上去实现 version 版本的功能。

使用Raw API,并发执行的话,业务上没办法知道TIKV最终执行是什么,现在也是现讨论下可行性或者有什么其他建议。

可以考虑使用 txn api ,那样在写入数据的时候会去获取 tso 作为版本号。
如果要使用 raw api 的话,可以参考 PD 获取 tso 的机制,在写入数据的时候,获取全局递增序列,并将序列值写入到 key 代替 version 的功能。

请教下,在tikv raft阶段,如果将region_id、region_epoch、term、apply_index、req_batch_seq(请求在vec中的序号)返回给客户端,这些字段组合在一起能保证后执行的操作组合值是递增的吗?我理解region分裂regionid是递增,重新选举term递增,apply_index也是递增,组合在一起能保证值递增?

应该是的,但是 kv 请求不会返回这些内容吧

嗯,没有,所以我们改了tikv代码和协议,增加返回这些内容

了解了