并发编程中的一致性 在大数据高并发环境下应该怎么保证库存或者下单同步？
在大数据高并发环境下应该怎么保证库存或者下单同步？
在互联网开发中，如果在大数据、高并发的环境下，很多人下单，如何保证库存的抵扣永远正确？
将库存加载到缓存中，如r
DB读写分离情况下，如何解决缓存和数据库不一致性问题？
说明:连续写数据库和缓存，但是在操作过程中，存在并发，数据不一致。
通常，高速缓存和数据库按以下顺序更新:
l先更新数据库，再更新缓存。
l先删除缓存，再更新数据库。
l首先更新数据库，然后删除缓存。
看看这三种的优缺点:
请在更新缓存之前更新数据库。
这样做的问题是，当同时有两个更新数据的请求时，如果您不 不要使用分布式锁，你不会 不能控制最后缓存的值是什么。就是并发写的时候有问题。
请在更新数据库之前删除缓存。
这样做的问题是，如果客户端在删除缓存后读取数据，它可能会读取旧数据并将其设置在缓存中，导致缓存中的数据总是旧数据。
有两种解决方案:
我使用 "双重删除 "，即删除或删除。删除的最后一步是异步操作，这是为了防止旧值在客户端读取时被设置。
我用队列。当这个键不存在时，将它放入队列中并顺序执行。你可以 直到数据库更新后才能读取数据。
总的来说比较麻烦。
请在删除缓存之前更新数据库。
这实际上是一个常见的方案，但许多人不 我不知道。我在这里介绍一下。It 我们称之为缓存备用模式，是外国人发明的。如果首先更新数据库，然后删除缓存，那么将显示更新次数。根据数据库，以前有瞬时数据不是很及时。
同时，如果更新前缓存刚好失效，读客户端可能会读取旧值，然后在写客户端删除后重新设置旧值，这是非常巧合的。
有两个前提条件:写之前缓存无效，同时写客户端删除操作之后旧数据放置——也就是读比写慢。一些写操作也会锁定表。
所以，这很难出现，但如果出现了呢？使用双重删除！！！记录更新期间客户端是否读取数据库，如果是，则在更新数据库后执行延迟删除。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
