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

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

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

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

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

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

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

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

需要仔细考虑失败场景。

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

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

我还会想到另外一种情况，悲观锁定会是更好的选择。

对于乐观锁，数据修改的每个参与者都必须同意使用这种锁。但是如果有人修改数据而不考虑版本列，这将破坏乐观锁定的整个思想。

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

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

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

乐观假设你读的时候什么都不会改变。

悲观的人认为某件事会发生，所以锁定它。

如果数据被完全读取不是必要的，请使用乐观。你可能会得到奇怪的“肮脏”解读——但它不太可能导致死锁或类似的情况。

大多数web应用程序都可以接受脏读——在极少数情况下，下一次重新加载时数据不完全一致。

对于精确的数据操作(如在许多金融交易中)使用悲观。准确读取数据非常重要，没有未显示的更改——额外的锁定开销是值得的。

对了，Microsoft SQL server默认为页面锁定——基本上就是你正在读的那一行和两边的几行。行锁定更准确，但速度要慢得多。通常值得将事务设置为读提交或无锁，以避免读取时发生死锁。