[发明专利]一种实现库存管理的方法、系统及存储介质

说明书

本发明公开了一种实现库存管理的方法、系统及存储介质。该方法包括步骤：S1，接收用户下单请求，读取此时的库存数据及库存版本号；S2，接收订单提交请求；S3，对所有订单提交请求执行redis分布式锁操作，每个订单提交请求作为一个事务存放在事务队列中，按照事务队列中存放的顺序依次对每个订单提交请求执行步骤S4；S4，判断订单提交请求是否可以处理成功，并在订单提交请求处理成功后使用乐观锁机制更新库存数据及库存版本号。本发明的库存管理不需要频繁访问数据库商品库存还有多少、不阻塞其他用户、实现安全扣减库存量、内存访问库存数量，减少数据库交互。

技术领域

本发明属于互联网技术领域，更具体地，涉及一种实现库存管理的方法、系统及存储介质。

背景技术

近年来订餐和外卖系统在互联网领域发展迅速，用户通过手机或者网站选择菜品来预订个人订餐服务。随着用户量的增多，多并发订餐对菜品的库存控制要求越来越高，同一个用户或者多个用户同时下单预订同一个菜品的时候，要如何做到并发安全减扣库存成为一个必须考虑的问题。针对多并发订餐的菜品的库存控制，普遍的做法是，有的厂家采用排他锁和共享锁，有的厂家采用悲观锁或者同步锁。

排他锁(Exclusive Locks)，又称为写锁、独占锁，在数据库管理上，是锁的基本类型之一。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。

共享锁又称为读锁，若事务T对数据对象A加上S锁，则事务T只能读A；其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

悲观锁(Pessimistic Lock)，是指每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。它指的是对数据被外界(包括系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制，只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在系统中实现了加锁机制，也无法保证外部系统不会修改数据)。

乐观锁(Optimistic Lock)，是指每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于写条件(write_condition)机制的其实都是提供的乐观锁。

但是上述这些解决方案都会对系统性能造成一定的影响，严重的情况可能造成死锁，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行

发明内容

针对现有技术的至少一个缺陷或改进需求，本发明提供了一种实现库存管理的方法、系统及存储介质，不需要频繁访问数据库商品库存还有多少、不阻塞其他用户、实现安全扣减库存量、内存访问库存数量，减少数据库交互。

为实现上述目的，按照本发明的第一方面，提供了一种实现库存管理的方法，包括步骤：

S1，接收用户下单请求，读取此时的库存数据及库存版本号；

S2，接收订单提交请求并将步骤S1读取的库存版本号添加到订单提交请求，订单提交请求中还包括下单数量；

S3，对所有订单提交请求执行redis分布式锁操作，每个订单提交请求作为一个事务存放在事务队列中，按照事务队列中存放的顺序依次对每个订单提交请求执行步骤S4；

S4，判断订单提交请求是否可以处理成功，并在订单提交请求处理成功后使用乐观锁机制更新库存数据及库存版本号。