更实际的一点是，在更新分布式系统时，DB中的乐观锁定可能不足以在分布式系统的所有部分之间提供所需的一致性。

例如，在AWS上构建的应用程序中，数据通常同时存在于DB(例如DynamoDB)和存储(例如S3)中。如果一个更新同时涉及DynamoDB和S3, DynamoDB中的乐观锁定仍然可能使S3中的数据不一致。在这种情况下，使用在DynamoDB中持有的悲观锁可能更安全，直到S3更新完成。事实上，AWS为此目的提供了一个锁定库。

关于乐观锁定和悲观锁定，上面已经说了很多好的东西。 需要考虑的一个重要问题如下:

在使用乐观锁定时，我们需要注意应用程序如何从这些故障中恢复。

特别是在异步消息驱动的体系结构中，这可能导致消息处理无序或更新丢失。

需要仔细考虑失败场景。

乐观锁定是一种策略，你读取一条记录，记下版本号(其他方法包括日期、时间戳或校验和/哈希)，并在写回记录之前检查版本是否没有改变。当您写回记录时，您过滤了版本上的更新，以确保它是原子的。(即在你检查版本和将记录写入磁盘之间没有更新)和一次更新版本。

如果记录是脏的(即不同于你的版本)，你中止事务，用户可以重新启动它。

这种策略最适用于大容量系统和三层体系结构，在这些体系结构中，您不必为会话维护到数据库的连接。在这种情况下，客户端实际上无法维护数据库锁，因为连接来自一个池，并且您可能不会在一次访问到下一次访问时使用相同的连接。

悲观锁定是指将记录锁定为专属使用，直到使用完毕为止。它比乐观锁具有更好的完整性，但要求您在应用程序设计时要小心，以避免死锁。要使用悲观锁定，您需要一个到数据库的直接连接(在两层客户端服务器应用程序中通常是这样)，或者一个可以独立于连接使用的外部可用事务ID。

在后一种情况下，使用TxID打开事务，然后使用该ID重新连接。DBMS维护锁，并允许您通过TxID恢复会话。这就是使用两阶段提交协议(如XA或COM+事务)的分布式事务的工作方式。

乐观锁定用于不期望发生太多冲突的情况。进行正常操作的成本较低，但如果碰撞确实发生，您将支付更高的代价来解决它，因为交易被中止。

悲观锁定在预期发生碰撞时使用。会违反同步的事务被简单地阻塞。

为了选择合适的锁定机制，您必须估计读取和写入的量并相应地进行计划。

乐观锁定的一个用例是让应用程序使用数据库允许其中一个线程/主机“声明”任务。这是一个经常为我派上用场的技巧。

我能想到的最好的例子是使用数据库实现的任务队列，多个线程同时声明任务。如果一个任务有状态'Available'， 'Claimed'， 'Completed'， db查询可以这样说:Set status='Claimed' where status='Available'。如果多个线程试图以这种方式改变状态，那么除了第一个线程之外，其他线程都会因为脏数据而失败。

注意，这是一个只涉及乐观锁定的用例。因此，作为“乐观锁定用于不期望有太多冲突的情况”的替代说法，它也可以用于您期望有冲突但只希望一个事务成功的情况。

乐观锁定意味着在读取一行时不使用排他锁，因此不会防止丢失更新或写倾斜。所以，使用乐观锁定:

如果没有发生丢失的更新或写倾斜。 或者，即使发生更新丢失或写倾斜也没有问题。

悲观锁定意味着在读取一行时使用排他锁定，从而防止丢失更新或写倾斜。所以，使用悲观锁定:

如果发生更新丢失或写倾斜。 或者出现丢失更新或写倾斜等问题。

在MySQL和PostgreSQL中，SELECT FOR UPDATE可以使用排他锁。

你可以检查我丢失更新的答案，并在MySQL中使用乐观锁定(不使用SELECT FOR update)和悲观锁定(使用SELECT FOR update)编写倾斜示例。