Does TiKV have something similar to binlog to record the order of commits?

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 请问TiKV有没有类似于binlog的东西记录commit的顺序?

| username: TiDBer_2tTuI9A5

【TiDB Usage Environment】Production / Testing / Poc
【TiDB Version】v5.4.3
【Reproduction Path】What operations were performed when the issue occurred
【Encountered Issue: Issue Phenomenon and Impact】
【Resource Configuration】
【Attachments: Screenshots / Logs / Monitoring】

Dear experts, does TiKV have something similar to binlog that records the order of commits?
When writing online business for billing, I found that two different processes A and B might simultaneously trigger: TxnGet(K) → TxnDel(K) operations. The size field is recorded in V, but in reality, only one of A or B might actually delete (the other deletes a non-existent K and also returns a successful deletion), but the final deleted size is counted twice. Adding locks at the upper level would cause performance issues, so I want to know if there is any way to get the execution order of commits, or if it is possible to get the affected rows of TxnDel?

| username: xfworld | Original post link

It does not support strict serializability for transactions, so the order cannot be guaranteed.

There is no constraint on ACID semantics either.

For the commit order, according to your requirements, only a message queue can meet them. :sunflower::sunflower:

| username: 裤衩儿飞上天 | Original post link

Your requirement can be met by setting the transaction isolation level to SERIALIZABLE, but this will significantly degrade database performance, and TiDB does not support it :crazy_face:
Otherwise, you can use a message queue as suggested above.

| username: ealam_小羽 | Original post link

To ensure order, the message queue must be single-threaded, otherwise, there will still be issues.
I feel this is a business problem that needs to consider idempotency. Refer to this?