我们系统想使用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分裂的问题。
这样做是否有可行性或该怎么做，望指教
请问一下
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也是递增，组合在一起能保证值递增？
嗯，没有，所以我们改了tikv代码和协议，增加返回这些内容