事件采购乐观并发
我试图了解事件采购的乐观并发性的想法。通常，乐观的并发旨在用于更新。但是，在事件采购的情况下，我们永远不会进行更新，而只会插入。
想象一下，我们有3个事件可以插入数据库。 我们检查当前的汇总版本与预期，然后插入。 但是随后，在版本检查后但在插入之前，汇总可能会更新。 为了处理它，我们需要将版本检查和插入交易中的语句插入，因此需要独家锁。
因此，问题是，如果我们使用锁，为什么仍然称其为乐观的并发？我想念什么吗？
I'm trying to understand the idea of optimistic concurrency for Event Sourcing. Typically, optimistic concurrency is intended to be used for updates. However, in case of event sourcing, we never do updates - only insert.
Imagine we have 3 events to insert into the database.
We check that current aggregate version is the same as expected and then do insert.
But then it's possible that the aggregate is updated after the version check, but before the insert.
To deal with it, we need to put version check and insert statement in transaction and therefore aquire exclusive lock.
So the question is, why is it still called optimistic concurrency, if we are using locks? Am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“悲观的”并发
“乐观”并发
我们正在下注的“乐观”，即我们在工作时不会出现矛盾的写作。如果我们失去了赌注，那么Compare_and_swap会失败，我们必须重新开始（或放弃）。从本质上讲，这使我们“第一作者赢得了”冲突。
请注意，乐观的并发策略限制了您的存储设计：您需要有有效的比较和交换操作。
"Pessimistic" concurrency
"Optimistic" concurrency
The "optimism" that we are making a bet that no conflicting writes will appear while we are working. If we lose that bet, then COMPARE_AND_SWAP fails, and we have to start over (or give up). This essentially gives us "first writer wins" conflict resolution.
Note that an optimistic concurrency strategy constrains your storage design: you need to have an effective compare and swap operation available.
在事件中，采购系统最终是一致的，因此，如果所有节点都收到了收敛到同一状态的实体的所有事件，则该实体并同时写信。
如果您将活动存储在数据库中，则无需锁定任何内容即可存储它们。事件流是蠕虫，只附加。只需添加记录事件即可。
您犯的错误是假设“我们检查当前的汇总版本与预期，然后插入。”
编写新事件的节点基于先前看到的事件检查其自己的内部状态，如果可以编写一个事件，则它会写下它。然后所有节点读取事件流并收敛到正确的状态。
In event sourcing the system is eventually consistent, so that if there are concurrent writes to the entity, once all nodes have received all the events for the entity they converge to the same state.
If you are storing your events in a database, you don't need to lock anything to store them. The event stream is WORM and append-only. Just add the events as they are recorded.
The mistake you're making is assuming "We check that current aggregate version is the same as expected and then do insert."
The node that's writing the new event checks its own internal state, based on previously seen events, and if it can write an event it writes it. All nodes then read the event stream and converge to the correct state.