数据密集型应用系统设计 pdf_设计数据密集型应用程序：写操作竞争条件

在上一篇文章中，我们探讨了两种形式的弱隔离： 读取已提交和快照隔离。 我们通过多个示例来说明应用程序在读取可能反映或可能不反映系统真实状态的数据时可能遇到的问题。

在进入更强大的隔离形式之前，我们将扩展该主题。 在上一篇文章中，我们仅关注客户端去读取数据时可能发生的竞争情况。 在本文中，我们将重点介绍客户写入数据时涉及的一些麻烦问题。

丢失更新问题

这可能是最著名的比赛条件； 两个客户端同时读取一些数据，对其进行修改，然后将其写回到数据库中。 修改之一将丢失，因为当两个客户端都执行更新时，它们将不会由另一个客户端执行修改。

例如，采用当前设置为5的连续递增计数器值。

客户端A和客户端B都从数据库中读取该值，将其递增1，然后同时将其写回。 该计数器的真实值应为7，因为两个独立的客户端已决定将计数器同时增加1。 因为他们都在5时读取计数器，所以他们都不知道对方打算将计数器加1。因此，一个更新将被另一个更新所破坏。 历史几乎被删除了。 实际发生的事情-两个客户将值更新为1，以前是5-在我们的系统中未反映。 相反，因为一个写入阻塞了另一个写入，因此系统认为该值应设置为6，而应为7。

许多数据库提供了原子更新，如上所述，它不需要读-修改-写周期。 执行原子更新的SQL语句就像

Update Counter SET Value =Value + 1 WHERE Key=" foo"

诸如此类的原子操作通常是通过锁定数据库尝试修改的对象来实现的，因此，其他任何请求都无法读取或干扰该过程的发生。

显式锁定

通过使用FOR UPDATE子句在事务中执行读-修改-写操作时