From 713493aa5e418c871018422f5d2470a9deb454ec Mon Sep 17 00:00:00 2001 From: Zhaoyang Date: Mon, 13 Dec 2021 22:02:58 +0800 Subject: [PATCH] Update ch7.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 更新错误 --- ch7.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch7.md b/ch7.md index 911ee3c..1881320 100644 --- a/ch7.md +++ b/ch7.md @@ -204,7 +204,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true 尽管重试一个中止的事务是一个简单而有效的错误处理机制，但它并不完美： -- 如果事务实际上成功了，但是在服务器试图向客户端确认提交成功时网络发生故障（所以客户端认为提交失败了），那么重试事务会导致事务被执行两次——除非你有一个额外的应用级除重机制。 +- 如果事务实际上成功了，但是在服务器试图向客户端确认提交成功时网络发生故障（所以客户端认为提交失败了），那么重试事务会导致事务被执行两次——除非你有一个额外的应用级去重机制。 - 如果错误是由于负载过大造成的，则重试事务将使问题变得更糟，而不是更好。为了避免这种正反馈循环，可以限制重试次数，使用指数退避算法，并单独处理与过载相关的错误（如果允许）。 - 仅在临时性错误（例如，由于死锁，异常情况，临时性网络中断和故障切换）后才值得重试。在发生永久性错误（例如，违反约束）之后重试是毫无意义的。 - 如果事务在数据库之外也有副作用，即使事务被中止，也可能发生这些副作用。例如，如果你正在发送电子邮件，那你肯定不希望每次重试事务时都重新发送电子邮件。如果你想确保几个不同的系统一起提交或放弃，**两阶段提交（2PC, two-phase commit）** 可以提供帮助（“[原子提交与两阶段提交](ch9.md#原子提交与两阶段提交)”中将讨论这个问题）。