事务错误处理

本章介绍使用事务时可能会遇到的错误和处理办法。

死锁

如果应用程序遇到下面错误时，说明遇到了死锁问题：

ERROR 1213: Deadlock found when trying to get lock; try restarting transaction

当两个及以上的事务，双方都在等待对方释放已经持有的锁或因为加锁顺序不一致，造成循环等待锁资源，就会出现“死锁”。这里以 bookshop 数据库中的 books 表为示例演示死锁：

先给 books 表中写入 2 条数据：

INSERT INTO books (id, title, stock, published_at) VALUES (1, 'book-1', 10, now()), (2, 'book-2', 10, now());

在 TiDB 悲观事务模式下，用 2 个客户端分别执行以下语句，就会遇到死锁：

客户端-A客户端-B
BEGIN;
BEGIN;
UPDATE books SET stock=stock-1 WHERE id=1;
UPDATE books SET stock=stock-1 WHERE id=2;
UPDATE books SET stock=stock-1 WHERE id=2; -- 执行会被阻塞
UPDATE books SET stock=stock-1 WHERE id=1; -- 遇到 Deadlock 错误

在客户端-B 遇到死锁错误后，TiDB 会自动 ROLLBACK 客户端-B 中的事务，然后客户端-A 中购买 id=2 的操作就会执行成功，再执行 COMMIT 即可完成购买的事务流程。

解决方案 1：避免死锁

为了应用程序有更好的性能，可以通过调整业务逻辑或者 Schema 设计，尽量从应用层面避免死锁。例如上面示例中，如果客户端-B 也和客户端-A 用同样的购买顺序，即都先买 id=1 的书，再买 id=2 的书，就可以避免死锁了：

客户端-A客户端-B
BEGIN;
BEGIN;
UPDATE books SET stock=stock-1 WHERE id=1;
UPDATE books SET stock=stock-1 WHERE id=1; -- 执行会被阻塞，当事务 A 完成后再继续执行
UPDATE books SET stock=stock-1 WHERE id=2;
UPDATE books SET stock=stock-1 WHERE id=2;
COMMIT;
COMMIT;

或者直接用 1 条 SQL 购买 2 本书，也能避免死锁，而且执行效率更高：

UPDATE books SET stock=stock-1 WHERE id IN (1, 2);

解决方案 2：减小事务粒度

如果每次购书都是一个单独的事务，也能避免死锁。但需要权衡的是，事务粒度太小不符合性能上的最佳实践。

解决方案 3：使用乐观事务

乐观事务模型下，并不会有死锁问题，但应用端需要加上乐观事务在失败后的重试逻辑，具体重试逻辑见 应用端重试和错误处理。

解决方案 4：重试

正如错误信息中提示的那样，在应用代码中加入重试逻辑即可。具体重试逻辑见 应用端重试和错误处理。

应用端重试和错误处理

尽管 TiDB 尽可能地与 MySQL 兼容，但其分布式系统的性质导致了某些差异，其中之一就是事务模型。

开发者用来与数据库通信的 Adapter 和 ORM 都是为 MySQL 和 Oracle 等传统数据库量身定制的，在这些数据库中，提交很少在默认隔离级别失败，因此不需要重试机制。对于这些客户端，当提交失败时，它们会因错误而中止，因为这在这些数据库中被呈现为罕见的异常。

与 MySQL 等传统数据库不同的是，在 TiDB 中，如果采用乐观事务模型，想要避免提交失败，需要在自己的应用程序的业务逻辑中添加机制来处理相关的异常。

下面的类似 Python 的伪代码展示了如何实现应用程序级的重试。 它不要求您的驱动程序或 ORM 来实现高级重试处理逻辑，因此可以在任何编程语言或环境中使用。

特别是，您的重试逻辑必须：

  • 如果失败重试的次数达到 max_retries 限制，则抛出错误
  • 使用 try ... catch ... 语句捕获 SQL 执行异常，当遇到下面这些错误时进行失败重试，遇到其它错误则进行回滚。详细信息请参考：错误码与故障诊断。
    • Error 8002: can not retry select for update statement：SELECT FOR UPDATE 写入冲突报错。
    • Error 8022: Error: KV error safe to retry：事务提交失败报错。
    • Error 8028: Information schema is changed during the execution of the statement：表的 Schema 结构因为完成了 DDL 变更，导致事务提交时报错。
    • Error 9007: Write conflict：写冲突报错，一般是采用乐观事务模式时，多个事务都对同一行数据进行修改时遇到的写冲突报错。
  • 在 try 块结束时使用 COMMIT 提交事务：
while True:
    n++
    if n == max_retries:
        raise("did not succeed within #{n} retries")
    try:
        connection.execute("your sql statement here")
        connection.exec('COMMIT')
        break
    catch error:
        if (error.code != "9007" && error.code != "8028" && error.code != "8002" && error.code != "8022"):
            raise error
        else:
            connnection.exec('ROLLBACK');

            # Capture the error types that require application-side retry,
            # wait for a short period of time,
            # and exponentially increase the wait time for each transaction failure
            sleep_ms = int(((1.5 ** n) + rand) * 100)
            sleep(sleep_ms) # make sure your sleep() takes milliseconds

注意：

如果你经常遇到 Error 9007: Write conflict 错误，你可能需要进一步评估你的 Schema 设计和数据存取模型，找到冲突的根源并从设计上避免冲突。 关于如何定位和解决事务冲突，请参考TiDB 锁冲突问题处理。

推荐阅读

下载 PDF修改本文
本页导航
文档内容是否有帮助？