并发问题出现
当我们在生成订单扣库存的时候，时常会遇到并发问题，即：当多个用户尝试读取并更新库存的 int 值时，会出现并发问题。
通常的解决办法是两把锁：
- 悲观锁 Pessimistic Lock
- 乐观锁 Optimistic Lock
悲观锁
悲观锁原理是更新值时，利用 数据库 提供的锁，将要更新的行给锁住不让其他用户更新，自己更新完成后，再释放锁。
- 优点：成功率高 重试代价低
- 缺点：笨重 代价比较高 不利于高并发
乐观锁
乐观锁通常需要一个 Concurrency Token 标识。当 Token 更改就意味着这一行数据已经更改。
原理是读取要更新的值时，读取 Token 标识，当更新完成要提交事务时，对比读取的 Token 和数据库的 Token，如果不一致，则表示数据已经被他人更改，本次提交作废。
最常用的 Token 是设置一个 version 版本号，每更新完就 version+1。还可以选用 TimeStamp。但是更好的选择是，选取已有列中的某一列设置为 Token。
- 优点：响应速度快 并发高
- 缺点：如果冲突频率大，乐观锁要作废重试多次，代价较高
EF Core 中的并发冲突
EF Core 采用的是 乐观 并发控制。
EF Core 实现 乐观并发控制，这意味着它将允许多个进程或用户独立进行更改而不产生同步或锁定的开销。 在理想情况下，这些更改将不会相互干扰，因此都能够成功。 在最坏的情况下，两个或更多进程将尝试进行冲突更改，其中只有一个进程应该成功。
- 采用 [ConcurrencyCheck] 注解，
与其对应的 Fluent API 书写方式是.IsConcurrencyToken()。 - 采用 [Timestamp] 注解，
与其对应的 Fluent API 书写方式是.IsRowVersion()。
配置为并发令牌的属性用于实现乐观并发控制：每当在 SaveChanges 期间执行更新或删除操作时，会将数据库上的并发令牌值与通过 EF Core 读取的原始值进行比较。
- 如果这些值匹配，则可以完成该操作。
- 如果这些值不匹配，EF Core 会假设另一个用户已执行冲突操作，并中止当前事务。
另一个用户已执行与当前操作冲突的操作的情况称为 并发冲突。
解决并发冲突
处理并发冲突的常规方法是：
- 在 SaveChanges 期间捕获 DbUpdateConcurrencyException。
- 使用 DbUpdateConcurrencyException.Entries 为受影响的实体准备一组新更改。
- 刷新并发令牌的原始值以反映数据库中的当前值。
- 重试该过程，直到不发生任何冲突。
