乐观与多版本并发控制 - 差异？
我想找出乐观并发控制（OCC）和多版本并发控制（MVCC）之间的区别是什么？
到目前为止我知道两者都是基于版本检查更新。
在 OCC 中，我读到了一些事务，这些事务不获取读访问锁，仅用于稍后的更新，如果在版本递增和版本检查失败之间，更新将会失败。在这种情况下，事务将被回滚。
在MVCC中，基本是一样的，还是不一样？差别在哪里呢？
I am trying to find out, what the difference between optimistic concurrency control (OCC) and multi version concurrency control (MVCC) is?
So far I know that both is based on version checking for updates.
In OCC, I read about transactions that acquire no locks for reading access, only for the later update which will fail if in between the version was incremented and version checking fails. In this case the transaction will be rolled back.
In MVCC, it is basically the same, or not? Where is the difference?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
直接回答问题，多版本并发控制（MVCC）是一种并发控制方法，（通常）属于乐观并发控制（OCC）范畴。
有两种主要的并发控制方法：
一种广为人知的悲观并发控制算法是两阶段锁定。
两种广为人知的乐观并发控制算法是：
这两种算法之间的主要区别如下。基于时间戳的算法为每个对象分配一个时间戳（更准确地说，为每种操作（读和写）分配一个时间戳），表示访问它的最后一个事务。因此，每个事务在操作期间都会检查是否与访问该对象的最后一个事务冲突。多版本方法维护每个对象的多个版本，每个版本对应一个事务。因此，多版本方法设法比第一种方法具有更少的中止，因为潜在冲突的事务可以写入新版本，而不是在某些情况下中止。然而，这是以所有版本都需要更多存储为代价实现的。
严格来说，MVCC 主要关注数据的存储方式，即每个数据项可以有多个物理版本。因此，理论上也可以将其与悲观方法（例如锁定）结合起来，但其多版本性质最好与乐观方法结合。
To directly reply to the question, multi version concurrency control (MVCC) is a concurrency control method, (typically) belonging in the category of optimistic concurrency control (OCC).
There are 2 main concurrency control approaches:
One widely known algorithm of pessimistic concurrency control is the 2-phase locking.
Two widely known algorithms of optimistic concurrency control are:
The main difference between these 2 algorithms is the following. The timestamp-based algorithm assigns a single (more correctly one for each kind of operation, read & write) timestamp to each object, denoting the last transaction that accessed it. So, each transaction checks during the operation, if it conflicts with the last transaction that accessed the object. The multi-version approach maintains multiple versions of each object, each one corresponding to a transaction. As a result, the multi-version approach manages to have fewer aborts than the first approach, since a potentially conflicting transaction can write a new version, instead of aborting in some cases. However, this is achieved at the cost of more storage required for all the versions.
Strictly speaking, MVCC is concerned mostly with how data are stored, i.e. the fact that there can be multiple physical versions for each data item. As a result, it is theoretically possible to combine it with pessimistic methods as well(e.g. locking), but its multi-version nature is best combined with optimistic methods.
我认为它们有时可以互换使用，如果事务只涉及一个对象，那么它们本质上是相同的，但 MVCC 是乐观并发（或其一个版本）的扩展，它在涉及多个对象时提供保证。
假设您有两个对象 A 和 B，它们之间必须保持某些不变性，例如，它们是两个数字，其总和为常数。现在，事务 T1 从 A 中减去 10 并将其加到 B，同时另一个事务 T2 正在读取这两个数字。
即使您乐观地独立更新 A 和 B（CAS 它们），T2 也可能会得到两个数字的不一致视图（例如，如果它在修改之前读取 A，但在修改之后读取 B）。 MVCC 将通过可能返回 A 和 B 的旧值来确保 T2 读取 A 和 B 的一致视图，即它必须保存旧版本。
综上所述，乐观锁（或乐观并发控制）是无锁同步的一般原则。 MVCC 是一种乐观技术，允许跨多个对象的隔离事务。
I think they are sometimes used interchangeably, and if the transaction only involves one object then they are essentially the same, but MVCC is an extension of optimistic concurrency (or a version of it) that provides guarantees when more than one object is involved.
Say that you have two objects, A and B, which must maintain some invariant between them, e.g. they are two numbers whose sum is constant. Now, a transaction T1 subtracts 10 from A and adds it to B, while, concurrently, another transaction T2 is reading the two numbers.
Even if you optimistically update A and B independently (CAS them), T2 could get an inconsistent view of the two numbers (say, if it reads A before it's modified but reads B after it's been modified). MVCC would ensure T2 reads a consistent view of A and B by possibly returning their old values, i.e., it must save the old versions.
To sum up, optimistic locking (or optimistic concurrency control), is a general principle for synchronization w/o locks. MVCC is an optimistic technique which allows isolated transactions which span multiple objects.
只是为了纠正 Dimos 的答案：基于时间戳的并发控制仍然是一种悲观的方法（它仍然可能在执行阶段中止/阻止事务）。
Just to rectify Dimos's answer: timestamp based concurrency control is still a pessimistic method (it may still abort/block transactions during their execution phase).