TIDB事务测试

灰太狼 2022-05-28 04:54 219阅读 0赞

测试用表如下及下图1：

drop table ttt;

create table ttt (id1 int NOT NULLAUTO\_INCREMENT  , id2 int ,PRIMARYkey(id1));

INSERT into ttt   VALUES (1,100);

show variables like '%iso%';

![70][]

（图1）

使用python脚本 session\_AA及session\_BB（两个脚本完全一致，详细代码文章末尾session\_AA.py）来做两个会话关于tidb事务的测试。

Session\_AA 输出结果如下

![70 1][]

Session\_BB 输出结果如下

![70 2][]

注意上面两图里两个会话的调度时间差（红色框框内），在python脚本里，使用了time  sleep 10s，来保证session\_bb在调度时，session\_aa还没有正常提交

![70 3][]

在两个会话执行完成后：表ttt结果为-100

![70 4][]

且所连接的tidb服务器 tidb.log如下图以及如下文字

cd /u01/tidata/log

cat tidb.log

![70 5][]

2018/03/24 16:23:03.203 server.go:118: \[info\]\[17\] new connection 192.168.121.84:60111

2018/03/24 16:23:03.213 set.go:157: \[info\]\[17\] set system variable autocommit = 0

2018/03/24 16:23:05.844 server.go:118:\[info\] \[18\] new connection 192.168.121.84:60113

2018/03/24 16:23:05.865 set.go:157: \[info\]\[18\] set system variable autocommit = 0

2018/03/24 16:23:13.222 metrics.go:355:\[warning\] \[EXPENSIVE\_QUERY\] select \* from ttt

2018/03/24 16:23:13.251 server.go:278:\[info\] \[17\] close connection

2018/03/24 16:23:15.872 metrics.go:355:\[warning\] \[EXPENSIVE\_QUERY\] select \* from ttt

2018/03/24 16:23:15.880 session.go:335:\[warning\] \[18\] retryable error: \[try again later\]: tikv restarts txn:Txn(Mvcc(WriteConflict \{ start\_ts: 398951654575570949, conflict\_ts:398951656502591489, key: \[116, 128, 0, 0, 0, 0, 0, 4, 255, 145, 95, 114, 128,0, 0, 0, 0, 255, 0, 0, 1, 0, 0, 0, 0, 0, 250\], primary: \[116, 128, 0, 0, 0, 0,0, 4, 145, 95, 114, 128, 0, 0, 0, 0, 0, 0, 1\] \})), txn: <nil>

2018/03/24 16:23:15.880 session.go:455:\[warning\] \[18\] Retry \[0\] query \[0\] update ttt a set a.id2 = id2-100 where a.id1= 1

2018/03/24 16:23:15.880 2pc.go:576: \[info\]2PC clean up done, tid: 398951654575570949

2018/03/24 16:23:15.884 session.go:455:\[warning\] \[18\] Retry \[0\] query \[1\] COMMIT

2018/03/24 16:23:15.904 server.go:278: \[info\]\[18\] close connection

官方文档事务定义：

![70 6][]

从tidb 服务器的 tidb.log日志来看，的确在session\_BB commit了检测了冲突并做了重试。

但是根据实际业务场景：假设存在这种同一用户并发的情况，tidb的事务重试机制可能会产生一些错误数据

待解决问题：综合以上比如在并发情况下账户提现的测试，该如何规避以上错误数据问题。

队列？

关闭tidb重试？

业务层多app端，只能单点在线，或者能同时在线，pc端与app端只能有一端可以操作对数据正确性要求较高的业务模块？

欢迎感兴趣同仁讨论。

测试脚本session\_AA.py：

#!/usr/bin/python
    # -*- coding: UTF-8 -*-
    #####################################
    ##    created by basededato        ##
    ##    2018-03-24                   ##
    #####################################
    
    import pymysql
    import time
    # 脚本执行时间，以保证session_BB 与 session_AA  的输出时间差小于  下面的sleep time
    print(time.asctime( time.localtime(time.time()) ))
    
    conn= pymysql.connect(
                host        = '192.168.121.217',
                port        = 5919,
                user        = 'root',
                passwd      = 'root',
                db          = 'uat_exue',
                cursorclass = pymysql.cursors.DictCursor
               )
    cur = conn.cursor()
    
    #cur.execute('update ttt a set a.id2 = id2-100 where a.id1 = 1')
    cur.execute('insert into  ttt values (1,100)')
    # 休眠时间，以保证 session_BB 在调度时，session_AA 还未提交
    time.sleep(10)
    reslut=cur.execute('select * from ttt where id1 = 1')
    msg = cur.fetchmany(reslut)
    for output in msg:
        print(output['id2'])
        if output['id2'] < 0:
            conn.rollback()
            print('事务回退')
        else:
            conn.commit()
            print('事务提交')
    
    cur.close()
    conn.close()

[70]: /images/20220528/95d2caddd50b46fc881d114fa698c604.png
[70 1]: /images/20220528/f00c2ff36204449b89b7771ecd188654.png
[70 2]: /images/20220528/0e99f9e06fd14542b4ec8ba6c73bae46.png
[70 3]: /images/20220528/bd3a3c8f1f5747148cafa89de20c265d.png
[70 4]: /images/20220528/ff23168a8cd34cfabccce9047842844a.png
[70 5]: /images/20220528/6a526a763d184587b2bd586428e9a0dc.png
[70 6]: /images/20220528/b82a7f51f62d4647bbcdb0ffa8d3f0c5.png