CN104699712B - 对数据库中的库存记录信息进行更新的方法及装置 - Google Patents
对数据库中的库存记录信息进行更新的方法及装置 Download PDFInfo
- Publication number
- CN104699712B CN104699712B CN201310661789.0A CN201310661789A CN104699712B CN 104699712 B CN104699712 B CN 104699712B CN 201310661789 A CN201310661789 A CN 201310661789A CN 104699712 B CN104699712 B CN 104699712B
- Authority
- CN
- China
- Prior art keywords
- record
- sku
- inventory
- database
- change
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请公开了对数据库中的库存记录信息进行更新的方法及装置,所述方法包括:接收到应用发出的对指定商品对象的库存记录进行变更的请求时,确定待变更的SKU库存记录;对所述待变更的SKU库存记录进行修改,并将所述SKU库存记录的变更信息写入数据库的日志文件中;在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录;其中,所述最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录;根据所述最新变更记录,计算所述SKU库存记录变更前后的差值;读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新。本申请能够在提高系统响应效率的同时,保证数据的一致性。
Description
技术领域
本申请涉及数据库技术领域,特别是涉及对数据库中的库存记录信息进行更新的方法及装置。
背景技术
在一些数据库系统中,经常存在相互关联的数据,一般情况下,为了保证各种数据的正确性,需要对这些数据进行同步更新。例如,在电子商务交易平台中,针对具体的商品对象,数据库中需要维护其SKU(最小销售属性)库存以及总库存。假设商品对象为某手机,其SKU分为黑色和白色两种,库存数量各为50件,则反映到库存管理中的数据记录情况可以如表1所示:
表1
商品 | SKU | 库存数 | 备注 |
某手机 | N/A | 100 | 商品总库存 |
某手机 | 黑色 | 50 | SKU库存 |
某手机 | 白色 | 50 | SKU库存 |
可见,在上述表1中,只有SKU库存才会影响到交易流程,因为实际库存扣减是发生在具体的SKU库存记录上(买家用户在购买该手机时,一定会选择黑色或者白色)。之所以需要维护商品对象的总库存,是因为在商品详情页面一般会展示商品总库存,当用户选定SKU之后,才会获取SKU库存,或者,商品下架一般发生在商品总库存为0时,因为任何一个SKU有库存,都可以将该商品提供展示、交易,等等。
在现有技术中,当一个交易产生,需要扣减SKU库存时,需要同步扣减商品对象的总库存。例如,某用户购买了某SKU的商品对象,使得该SKU的库存记录从50件被扣减为49件。在现有技术中,在修改该SKU库存记录的同时,还需要将该商品对象的总库存记录由原来的假设500件,扣减案为499件,等等。但是,在锁机制的数据库存储中,单行记录每秒最大更新次数有限制。在交易减库存的场景下,如果为了维护商品总库存,同步更新SKU库存和商品总库存,则商品总库存记录将更新过热,并限制了该商品每秒的交易笔数。例如,一个商品对象有10个SKU时,每个SKU对应一行库存记录,总库存也对应一行库存记录;假定单行最高支持每秒100次更新,该商品对象每秒最多可以完成100笔交易,相当于每个SKU平均能完成5笔交易。这是因为每笔交易都需要对商品总库存进行同步更新,而商品总存库记录只有一条,因此同一商品对象的各条SKU记录只能进行串行的更新,只有等到更新完某一条SKU记录之后,才能对下一条SKU记录进行更新。但实际上,每个SKU上每秒产生的交易量可能是远大于5笔的,尤其是在参加一个促销活动,或者是在节假日等特殊的日期,单个SKU每秒产生的交易量会更多,因此,按照现有技术中的更新方法,会限制系统的处理效率。
发明内容
本申请提供了对数据库中的库存记录信息进行更新的方法及装置,能够在提高系统响应效率的同时,保证数据的一致性。
本申请提供了如下方案:
一种对数据库中的库存记录信息进行更新的方法,所述数据库中针对同一商品对象的多个最小销售属性SKU保存有多条库存记录,每个SKU对应一条SKU库存记录,所述数据库中还保存有同一商品对象的总库存记录,所述方法包括:
接收到应用发出的对指定商品对象的库存记录进行变更的请求时,确定待变更的SKU库存记录;
对所述待变更的SKU库存记录进行修改,并将所述SKU库存记录的变更信息写入数据库的日志文件中;
在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录;其中,所述最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录;
根据所述最新变更记录,计算所述SKU库存记录变更前后的差值;
读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新。
一种对数据库中的库存记录信息进行更新的装置,所述数据库中针对同一商品对象的多个最小销售属性SKU保存有多条库存记录,每个SKU对应一条SKU库存记录,所述数据库中还保存有同一商品对象的总库存记录,所述装置包括:
变更请求接收单元,用于接收到应用发出的对指定商品对象的库存记录进行变更的请求时,确定待变更的SKU库存记录;
数据修改单元,用于对所述待变更的SKU库存记录进行修改,并将所述SKU库存记录的变更信息写入数据库的日志文件中;
日志读取单元,用于在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录;其中,所述最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录;
计算单元,用于根据所述最新变更记录,计算所述SKU库存记录变更前后的差值;
更新单元,用于读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新。
根据本申请提供的具体实施例,本申请公开了以下技术效果:
通过本申请实施例,可以将SKU库存记录与总库存记录的更新过程进行分离,也就是说,在业务系统中的应用产生数据变更请求之后,可以仅对实际对应了可交易商品对象的SKU库存记录进行变更,而不用对商品对象的总库存记录进行同步更新。后续再根据日志文件中记录的变更信息对关联的总库存记录进行更新,这样就可以使得总库存记录也得到更新。并且由于日志文件中的变更记录与数据库中对各条SKU库存记录的更新操作是完全一致的,因此,还可以保证SKU库存记录与总库存记录之间的一致性。
当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的方法的流程图;
图2是本申请实施例提供的装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本申请保护的范围。
首先需要说明的是,本申请的发明人在实现本申请的过程发现,对于同一个商品对象而言,其总库存基于与其各个SKU库存记录之间具有一定的关联,但是,应用中产生的数据更新请求并不直接作用于这种总库存记录,而是作用于与之关联的SKU库存记录。因为当用户选择某商品对象时,都是基于某一SKU来进行选择的,只有SKU库存才对应了实际可以销售的商品对象。换言之,不需要由具体的应用来保证总库存记录的正确性,但是,SKU库存记录的变化也会引起总库存记录的变化。在现有技术中,总库存记录与关联的SKU库存记录是同步更新的,也即,当应用发出数据变更请求,使得SKU库存记录的值发生修改时,会在同一个事务中对总库存记录的值进行同步修改。对于针对同一商品对象的各条数据变更请求而言,只有等到总库存记录的取值也同步修改完成之后,才会响应下一条数据变更请求,这在高并发的情况下,会严重影响系统的效率。
而在本申请实施例中,对于总库存记录而言,可以采用异步更新的方式,也即,当应用发出了数据变更请求后,只对对应SKU库存记录的取值进行修改,而不用对总库存记录的取值进行同步修改,关于总库存记录的修改是在后续的过程中通过读取数据库的日志文件完成的。下面对具体的实现方式进行详细地介绍。
参见图1,本申请实施例首先提供了一种对数据库中的库存记录信息进行更新的方法,该方法可以包括以下步骤:
S101:接收到应用发出的对指定商品对象的库存记录进行变更的请求时,确定待变更的SKU库存记录;
这里需要说明的是,数据库是用于向具体的应用提供数据查询或者修改支持的,例如,在电子商务系统中,具体的应用可能包括查看商品对象详情页、生成订单等功能,在向用户显示某商品对象详情页时,应用就需要查询数据库,获取商品对象的各项数据,例如,其中就可能包括库存数量这一数据,等等。在用户购买了某商品对象时,应用会向数据库发出修改对应的SKU库存记录这一数据的请求。
在该步骤S101中,变更请求就是由具体的应用发出的数据库操作引起的。例如,前述例子中,当用户选择购买了某SKU下的商品之后,应用需要请求修改数据库中该商品对象的该SKU库存。或者,卖家用户对某商品的SKU库存进行编辑等等。总之,无论是库存编辑还是交易减库存,最终反映到数据库层面上,都是在接收到数据变更请求后,对SKU库存值从多少变为多少。因此,在本申请实施例中,在收到应用发出的数据变更请求后,可以首先确定出待变更的SKU库存记录,例如,判断需要对哪个商品对象的哪个SKU库存进行修改,等等。其中,具体实现时,各个SKU库存记录可以有各自的标识信息,具体的应用在发出数据变更请求时,会在请求信息中携带上待变更数据的标识信息,因此,可以直接根据请求中的标识确定待变更的SKU库存记录。例如,各个商品对象具有各自的商品id,各种SKU则可以通过具体的参数等来表示,因此,具体的应用在需要修改某商品对象在某SKU下的库存数量时,会在其请求信息中携带上商品id,以及用户选定的具体SKU参数,例如,对于某款手机而言,选定的SKU参数可以包括白色、16G等,这样,数据库在收到数据变更请求后,就可以确定出待变更的SKU库存记录是白色、16G的该手机的库存记录。
S102:对所述待变更的SKU库存记录进行修改,并将所述SKU库存记录的变更信息写入数据库的日志文件中;
在确定出待变更的SKU库存记录之后,就可以根据数据变更请求中携带的信息,对SKU库存记录的取值进行修改,修改完成之后,SKU库存记录的变更信息就会被写入到数据库的日志文件中。也就是说,虽然SKU库存记录发生变更之后,会引起对应商品对象的总库存记录的取值的变化,但是在本申请实施例中,并不需要在同一事务中对总库存记录进行同步变更。这样,仍假设一个商品有10个SKU时,假定单行最高支持每秒100次更新,则在本申请实施例的实现方式下,由于每个SKU库存记录都分别是一行独立的记录,并且不需要在每次修改SKU库存时都同步修改总库存记录,因此,相当于10行SKU库存记录都可以做到完全并行处理,每行最高支持100次更新,因此,该商品最多可支持每秒100*10=1000笔交易,相对于背景技术中介绍的的例子而言,性能提升了10倍。而且在SKU数越多的情况下,效果越明显。
在对SKU库存记录进行修改之后,在数据库的日志文件中会产生相应的变更记录,例如MySQL数据库的Binlog日志等,其中会记录下该SKU库存记录本身的标识信息,例如商品对象的ID、SKU ID等,另外还会记录下该SKU记录变更前以及变更后的取值分别是多少,以及各条变更记录产生的时间等信息。其中,每条SKU记录每次发生一次更新,都会在日志文件中产生一条变更记录,变更记录产生的时间是由SKU记录实际被更新的时间来决定的,因此,各条变更记录也会按照SKU记录实际被更新的顺序排列。
S103:在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录;其中,所述最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录;
由于总库存记录的取值实际上是可以根据SKU库存记录的变化计算出来的,例如,从数据层面来看,商品总库存是该商品下所有SKU库存的总和,理论上是可以由SKU库存在变更后相对于变更前的差值推导出来的。因此,在本申请实施例中,可以将商品总库存记录的更新进行异步化处理,并且保证总库存记录的准确性。具体在进行更新时,就可以以数据库的日志文件中的变更记录为依据来进行。
因此,首先需要读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录。具体实现时,可以预先设置更新总库存记录的条件,例如,可以是每隔预置的时间段进行一次总库存记录的更新,也就是说,可以按照预置的时间间隔,进行日志文件的读取。或者,还可以在数据库的日志文件中产生了预置条目的最新变更记录时,读取数据库的日志文件,进行一次对总库存记录的更新。总之,由于并不是每产生一条更新记录就读取一次,因此一次读取可能会从日志文件中读取到多条最新变更记录,也即,从上一读取时刻到当前读取时刻之间,数据库中有多条SKU库存记录发生了变更,或同一条SKU库存记录变更了多次;当然,一次读取还可能读取不到最新变更记录,也就是说,从上一读取时刻到当前读取时刻之间,数据库中没有SKU库存记录发生过变化。
S104:根据所述最新变更记录,计算所述SKU库存记录变更前后的差值;
具体地,在读取到最新变更记录后,由于其中记录了SKU库存记录变更前(before)的取值以及变更后(after)的取值,因此,就可以计算出该SKU库存记录变更前后的差值。例如,以某型号手机(例如为iPhone5)的“黑色”库存从50件变更到40件为例,Mysql的binlog日志的结构可以抽象成:
before:黑色iPhone5 50件
after:黑色iPhone5 40件
从上述binlog中,就可以得到,本次黑色iPhone5库存减少10件,商品总库存理应同步减少10件。因此,只需要把减少10件的这个事件应用到商品总库存记录上,即可保证总库存记录的准确性,为此,就需要在获取到最新变更记录之后,首先计算出SKU库存记录变更前后的差值,以便确定出如何对总库存记录进行相应的变更操作。当然,在此之前,还需要确定出与SKU库存记录关联的总库存记录是什么,具体实现时,就可以通过两种对应的同一商品对象信息关联起来。例如,如果SKU库存记录是某商品对象的SKU库存,则与该SKU库存记录关联的总库存记录就应该是该商品对象的总库存。
S105:读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新。
在计算出SKU库存记录变更前后的差值,之后,就可以利用该差值对与其关联的总库存记录的取值进行更新。由于在收到数据变更请求后,只要修改完SKU库存记录的取值后,不会直接对总库存记录进行更新,而是后续通过读取日志文件、计算差值等方式再对总库存记录的取值进行更新,因此,这属于一种异步的更新方式。
如前文所述库存记录的例子,由于在数据层面,SKU库存无论是因为增量修改、还是减库存,抑或全量编辑,最终体现到数据记录上都是库存值由某个值转化为另一个值,而且变更前后的差值是可以推算出来的,这样,只需要将这个差值附加到商品总库存记录上即可保证商品总库存记录的正确性。
例如,假设某商品对象的库存记录信息如表2所示:
表2
商品ID(ItemID) | SKU ID | 库存数(quantity) |
1234567 | 0 | 100 |
1234567 | 10001 | 80 |
1234567 | 10002 | 20 |
其中,第一行为商品对象的总库存,因此,SKU ID用0来表示。某时刻,数据库接收到了一条数据变更请求,将ID为10001的SKU库存数量减少5件,则变更之后的库存记录如表3所示:
表3
商品ID(ItemID) | SKU ID | 库存数(quantity) |
1234567 | 0 | 100 |
1234567 | 10001 | 75 |
1234567 | 10002 | 20 |
也就是说,在接收到变更请求时,仅修改当前SKU库存的数量,而总库存的数量则不会进行同步的变更。之后通过读取数据库的日志文件,发现该商品ID下,SKU ID为10001的SKU库存已经由80变为75。例如,在具体的变更日志中,会体现如下信息:
before:{itemid:1234567,skuid:10001,quantity:80}
after:{itemid:1234567,skuid:10001,quantity:75}
计算出变化前后的差值为5,之后就可以用该差值对该商品ID的总库存进行更新。更新后的值如表4所示。
表4
商品ID(ItemID) | SKU ID | 库存数(quantity) |
1234567 | 0 | 95 |
1234567 | 10001 | 75 |
1234567 | 10002 | 20 |
这样,变更完成后,商品总库存的数量仍然等于两个SKU库存数量之和。
需要说明的是,读取数据库日志文件的操作可以是一直在进行的,例如,每秒中读取一次等。如果一次读取到的变更记录为多条(可能是针对同一SKU库存记录的多次变更,还可能是针对多个SKU库存记录的变更,等等),由于在数据库的日志文件中,各条变更记录是按照实际在数据库中执行修改操作的时间进行顺序排列的,因此,可以按照各条变更记录产生的时间先后顺序,依次进行对应的总库存记录的变更。这样,相当于依据各个变更记录执行的更新操作之间是串行的,这样也保证了对总库存记录进行变更过程中数据的正确性(如果对总库存记录的更新顺序与SKU库存记录更新过程中数据更新的顺序不一致,则可能会导致更新的总库存记录的取值出错),并且这样也可以保证在低时延的情况下,达成SKU库存记录与总库存记录之间的一致性。
总之,在本申请实施例中,可以将SKU库存记录与总库存记录的更新过程进行分离,也就是说,在业务系统中的应用产生数据变更请求之后,可以仅对实际对应了可交易商品对象的SKU库存记录进行变更,而不用对商品对象的总库存记录进行同步更新。后续再根据日志文件中记录的变更信息对关联的总库存记录进行更新,这样就可以使得总库存记录也得到更新。并且由于日志文件中的变更记录与数据库中对各条SKU库存记录的更新操作是完全一致的,因此,还可以保证SKU库存记录与总库存记录之间的一致性。
需要说明的是,在实际应用中,可能出现计算系统宕机或者重启等现象。而如果是在进行更新的过程中,正好发生了计算系统的宕机或者重启,则可能会丢失一部分日志文件信息。例如,假设计算系统在t1时刻读取了日志文件中的最新变更记录,但是尚未完成对总库存记录的变更,计算系统就发生了重启,重启之后,在t2时刻,如果仅读取从t1时刻到t2时刻之前最新的变更记录,则会使得t1时刻读取到但尚未完成更新的变更记录被丢失,最终导致数据的一致性无法得到保证。
为了避免这种现象的发生,在发生宕机或者重启之后,可以回溯拉取一段关于SKU库存记录的变更记录,使得读取的最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录,以及上一读取时刻之前产生的预置条数的变更记录。例如,假设在t2时刻完成了重启,上次读取日志文件的时间是t1时刻,则此次读取日志文件时,可以读取从t1时刻之前的某时刻到当前t2时刻之间的变更记录,避免上次读取到的变更记录由于宕机或者重启的原因尚未完成对总库存记录的更新。当然,还可能存在的情况是,在发生宕机或重启之前,已经将上次读取到的变更记录更新到对应的总库存记录,此时,如果再重复进行更新,也会造成总库存记录与SKU库存记录不一致,从而发生错误。
因此,在本发明实施例中,可以进行以下处理:首先,在数据库中,可以为各个SKU库存记录增加“版本号”字段,SKU库存记录每产生一次变更,该SKU库存记录的版本号进行同步修改,例如增加1,同时,在数据库的变更日志中也对这种版本号信息进行记录,以便日志文件中的变更记录中带有SKU库存记录的版本号信息;并且,当利用某条最新变更记录对总库存记录进行更新后,更新程序可以保存此次更新过程所依据的变更记录到一个表格中(例如可以称为去重表),该去重表用于记录已经完成更新的SKU库存记录的标识(包括商品对象ID、SKU ID等)以及版本号信息。当然,总库存记录中也可以增加版本号字段,计算系统的更新程序在对总库存记录的取值进行更新的过程中,也同时修改总库存记录的版本号。例如,某次读取到的最新变更记录中,SKU库存记录的版本号是2,根据该变更记录对总库存记录进行更新完成后,则在去重表中增加一条记录,用于表明对总库存记录最近的更新是根据版本号为2的SKU库存记录的变更进行的。当然,如果这次更新完成之前,计算系统就发生了宕机,去重表中就不会产生该记录,这就证明,对于版本号为2的变更记录,尚未更新到对应的总库存记录中。例如,去重表中包含的信息可以如以下表5所示:
表5
字段 | 类型 | 是否可空 | 描述 |
item_id | bigint | 否 | 商品对象ID |
sku_id | bigint | 否 | SKU ID |
version | int | 否 | SKU库存修改当前的version |
gmt_create | datetime | 否 | 用于迁移历史数据 |
这样,在发生了宕机或者重启的情况下,对于回溯读取到的最新变更记录,可以首先尝试将读取到的最新变更记录插入到去重表中,该去重表可以具有唯一约束性,这样如果某条最新变更记录能够成功插入到给去重表中,则证明尚未利用该条变更记录对总库存记录进行更新过,因此,触发对利用该条变更记录对总库存记录进行更新的操作即可,也即根据该变更记录计算出SKU库存记录变更前后的差值,并利用该差值对商品对象总库粗记录的取值进行更新,以避免由于宕机或重新,造成变更记录丢失。但是,如果某条变更记录无法插入到去重表中,则证明去重表中已经存在该条变更记录,并且已经利用该条变更记录对总库存记录进行了更新,因此,可以跳过利用该条记录对总库存记录进行更新的操作,也即不再用该变更记录对总库存记录进行更新,防止重复更新造成数据出错。需要说明的是,为了保证正确性,对于各个SKU库存记录的版本号而言,一般可以是严格向上增加的。例如,对于表2至表4而言,在存在版本号的情况下,假设表2中的状态为初始状态,则表2可以如以下表6所示:
表6
商品ID(ItemID) | SKU ID | 库存数(quantity) | 版本号(version) |
1234567 | 0 | 100 | 0 |
1234567 | 10001 | 80 | 0 |
1234567 | 10002 | 20 | 0 |
也即,初始状态下,各条SKU库存记录的版本号均为初始值0。在表3的状态下,SKUID为10001的SKU库存发生了变化,因此,其版本号也可以递增为1,其他未发生变化的数据记录的版本号则不变。如表7所示:
表7
商品ID(ItemID) | SKU ID | 库存数(quantity) | 版本号(version) |
1234567 | 0 | 100 | 0 |
1234567 | 10001 | 75 | 1 |
1234567 | 10002 | 20 | 0 |
在将商品总库存完成更新之后,就可以对总库存的版本号也可以增加1,如表8所示:
表8
商品ID(ItemID) | SKU ID | 库存数(quantity) | 版本号(version) |
1234567 | 0 | 95 | 1 |
1234567 | 10001 | 75 | 1 |
1234567 | 10002 | 20 | 0 |
另外,在实际应用中,还有些SKU库存记录可能并不存在与之关联的总库存记录,此时,如果发现日志文件中有关于这种SKU库存记录的变更记录,则不需要基于这种SKU库存记录去查找总库存记录,更不需要对总库存记录进行更新操作。例如,部分商品不带有SKU(如某手机只有黑色、16G内存这样一种配置,无其他可选配置),这时候交易等环节操作的其实就直接是商品的总库存,不需要计算系统再操作一遍。具体实现时,对于这类变更记录,计算系统可以直接丢弃,避免浪费计算资源。为了便于计算系统对这种SKU库存记录进行识别,一般可以通过在SKU库存记录中增加特定标识,或者直接通过数据库中SKU总库存记录中的单独字段来进行标识,达到互斥更新的效果。
其中一种可行的方法可以是,在数据记录上加上互斥锁标识,例如库存表的flag字段(flag字段可以是二进制mask,也可以是boolean值)。例如,对于商品对象的库存记录而言,该互斥锁标识可以是在卖家用户编辑商品删除掉所有SKU,变成单独一个商品时,增加该标识。这样,更新程序在在通过读取数据库的日志文件获取到最新变更记录后,判断最新变更记录对应的SKU库存记录是否带有特定标识,如果存在,跳过利用该条最新变更记录对总库存记录进行更新的操作,例如,如果发现该flag字段进行了设置(例如flag=true),则直接放弃对该条记录的操作权。如果不存在该特定标识,则触发利用该条最新变更记录对总库存记录进行更新的操作。
与本申请实施例提供的对数据库中的库存记录信息进行更新的方法相对应,本申请实施例还提供了一种对数据库中的库存记录信息进行更新的装置,所述数据库中针对同一商品对象的多个最小销售属性SKU保存有多条库存记录,每个SKU对应一条SKU库存记录,所述数据库中还保存有同一商品对象的总库存记录,参见图2,该装置可以包括:
变更请求接收单元201,用于接收到应用发出的对指定商品对象的库存记录进行变更的请求时,确定待变更的SKU库存记录;
数据修改单元202,用于对所述待变更的SKU库存记录进行修改,并将所述SKU库存记录的变更信息写入数据库的日志文件中;
日志读取单元203,用于在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录;其中,所述最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录;
计算单元204,用于根据所述最新变更记录,计算所述SKU库存记录变更前后的差值;
更新单元205,用于读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新。
其中,从日志文件中读取到的最新变更记录包括同一商品对象的多条SKU库存记录变更产生的多条变更记录,更新单元205具体可以根据各条变更记录在所述日志文件中的先后顺序,对总库存记录的取值进行更新。
或者,从日志文件中读取到的最新变更记录也可以包括同一条SKU库存记录发生多次变更产生的多条变更记录,更新单元205具体可以根据各条变更记录在所述日志文件中的先后顺序,对总库存记录的取值进行更新。
具体实现时,SKU库存记录中包含版本号,所述数据修改单元202还用于对所述待变更的SKU库存记录的版本号进行同步修改,并将带有修改后的版本号信息的变更信息写入到数据库的日志文件中,以便所述日志文件中的变更记录中带有SKU库存记录的版本号信息;
所述装置还包括:
去重表写入单元,用于当利用某条最新变更记录对总库存记录进行更新后,将该最新变更记录写入到去重表中;其中,所述去重表用于记录已经完成更新的SKU库存记录的标识以及版本号信息。
其中,所述去重表具有唯一性约束,所述装置还包括:
回溯读取单元,用于当系统发生重启时,从日志文件中读取最新变更记录时,读取的最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录,以及上一读取时刻之前产生的预置条数的变更记录;
插入单元,用于将读取到的各条最新变更记录插入到所述去重表中;
第一更新单元,用于如果某条最新变更记录插入成功,则利用该最新变更记录对所述总库存记录的取值进行更新;
第二更新单元,用于如果插入不成功,则跳过利用该条最新变更记录对总库存记录的更新操作。
如果某商品对象仅存在一条SKU库存记录,则预先在数据库中为该SKU库存记录添加特定标识,所述装置还包括:
判断单元,用于在通过读取数据库的日志文件获取到最新变更记录后,判断最新变更记录对应的SKU库存记录是否带有所述特定标识;
触发单元,用于如果不存在,则触发利用该条最新变更记录对总库存记录进行更新的操作;
跳过操作单元,用于如果存在,则跳过利用该条最新变更记录对总库存记录进行更新的操作。
通过本申请实施例,可以将SKU库存记录与总库存记录的更新过程进行分离,也就是说,在业务系统中的应用产生数据变更请求之后,可以仅对实际对应了可交易商品对象的SKU库存记录进行变更,而不用对商品对象的总库存记录进行同步更新。后续再根据日志文件中记录的变更信息对关联的总库存记录进行更新,这样就可以使得总库存记录也得到更新。并且由于日志文件中的变更记录与数据库中对各条SKU库存记录的更新操作是完全一致的,因此,还可以保证SKU库存记录与总库存记录之间的一致性。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统或系统实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上对本申请所提供的数据更新方法及装置,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处。综上所述,本说明书内容不应理解为对本申请的限制。
Claims (12)
1.一种对数据库中的库存记录信息进行更新的方法,其特征在于,所述数据库中针对同一商品对象的多个最小销售属性SKU保存有多条库存记录,每个SKU对应一条SKU库存记录,所述数据库中还保存有同一商品对象的总库存记录,所述方法包括:
接收到应用发出的对指定商品对象的库存记录进行变更的请求时,确定待变更的SKU库存记录;
对所述待变更的SKU库存记录进行修改,并将所述SKU库存记录的变更信息写入数据库的日志文件中;
在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录;其中,所述最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录;
根据所述最新变更记录,计算所述SKU库存记录变更前后的差值;
读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新。
2.根据权利要求1所述的方法,其特征在于,从日志文件中读取到的最新变更记录包括同一商品对象的多条SKU库存记录变更产生的多条变更记录,所述读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新,包括:
根据各条变更记录在所述日志文件中的先后顺序,对总库存记录的取值进行更新。
3.根据权利要求1所述的方法,其特征在于,从日志文件中读取到的最新变更记录包括同一条SKU库存记录发生多次变更产生的多条变更记录,所述读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新,包括:
根据各条变更记录在所述日志文件中的先后顺序,对总库存记录的取值进行更新。
4.根据权利要求1所述的方法,其特征在于,SKU库存记录中包含版本号,所述对所述待变更的SKU库存记录进行修改时,还包括:
对所述待变更的SKU库存记录的版本号进行同步修改,并将带有修改后的版本号信息的变更信息写入到数据库的日志文件中,以便所述日志文件中的变更记录中带有SKU库存记录的版本号信息;
所述方法还包括:
当利用某条最新变更记录对总库存记录进行更新后,将该最新变更记录写入到去重表中;其中,所述去重表用于记录已经完成更新的SKU库存记录的标识以及版本号信息。
5.根据权利要求4所述的方法,其特征在于,所述去重表具有唯一性约束,所述方法还包括:
当系统发生重启时,从日志文件中读取最新变更记录时,读取的最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录,以及上一读取时刻之前产生的预置条数的变更记录;
将读取到的各条最新变更记录插入到所述去重表中;
如果某条最新变更记录插入成功,则利用该最新变更记录对所述总库存记录的取值进行更新;
如果插入不成功,则跳过利用该条最新变更记录对总库存记录的更新操作。
6.根据权利要求1所述的方法,其特征在于,如果某商品对象仅存在一条SKU库存记录,则预先在数据库中为该SKU库存记录添加特定标识,所述方法还包括:
在通过读取数据库的日志文件获取到最新变更记录后,判断最新变更记录对应的SKU库存记录是否带有所述特定标识;
如果不存在,则触发利用该条最新变更记录对总库存记录进行更新的操作;
如果存在,则跳过利用该条最新变更记录对总库存记录进行更新的操作。
7.根据权利要求1至6任一项所述的方法,其特征在于,所述在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录,包括:
按照预置的时间间隔,读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录。
8.根据权利要求1至6任一项所述的方法,其特征在于,所述在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录,包括:
当所述数据库的日志文件中产生了预置条目的最新变更记录时,读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录。
9.一种对数据库中的库存记录信息进行更新的装置,其特征在于,所述数据库中针对同一商品对象的多个最小销售属性SKU保存有多条库存记录,每个SKU对应一条SKU库存记录,所述数据库中还保存有同一商品对象的总库存记录,所述装置包括:
变更请求接收单元,用于接收到应用发出的对指定商品对象的库存记录进行变更的请求时,确定待变更的SKU库存记录;
数据修改单元,用于对所述待变更的SKU库存记录进行修改,并将所述SKU库存记录的变更信息写入数据库的日志文件中;
日志读取单元,用于在满足预置条件时,通过读取数据库的日志文件,获取数据库中关于SKU库存记录的最新变更记录;其中,所述最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录;
计算单元,用于根据所述最新变更记录,计算所述SKU库存记录变更前后的差值;
更新单元,用于读取数据库中所述指定商品对象的总库存记录,并根据所述差值对所述总库存记录的取值进行更新。
10.根据权利要求9所述的装置,其特征在于,SKU库存记录中包含版本号,所述数据修改单元还用于对所述待变更的SKU库存记录的版本号进行同步修改,并将带有修改后的版本号信息的变更信息写入到数据库的日志文件中,以便所述日志文件中的变更记录中带有SKU库存记录的版本号信息;
所述装置还包括:
去重表写入单元,用于当利用某条最新变更记录对总库存记录进行更新后,将该最新变更记录写入到去重表中;其中,所述去重表用于记录已经完成更新的SKU库存记录的标识以及版本号信息。
11.根据权利要求10所述的装置,其特征在于,所述去重表具有唯一性约束,所述装置还包括:
回溯读取单元,用于当系统发生重启时,从日志文件中读取最新变更记录时,读取的最新变更记录包括从上一读取时刻到当前读取时刻产生的变更记录,以及上一读取时刻之前产生的预置条数的变更记录;
插入单元,用于将读取到的各条最新变更记录插入到所述去重表中;
第一更新单元,用于如果某条最新变更记录插入成功,则利用该最新变更记录对所述总库存记录的取值进行更新;
第二更新单元,用于如果插入不成功,则跳过利用该条最新变更记录对总库存记录的更新操作。
12.根据权利要求9所述的装置,其特征在于,如果某商品对象仅存在一条SKU库存记录,则预先在数据库中为该SKU库存记录添加特定标识,所述装置还包括:
判断单元,用于在通过读取数据库的日志文件获取到最新变更记录后,判断最新变更记录对应的SKU库存记录是否带有所述特定标识;
触发单元,用于如果不存在,则触发利用该条最新变更记录对总库存记录进行更新的操作;
跳过操作单元,用于如果存在,则跳过利用该条最新变更记录对总库存记录进行更新的操作。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310661789.0A CN104699712B (zh) | 2013-12-09 | 2013-12-09 | 对数据库中的库存记录信息进行更新的方法及装置 |
HK15107026.6A HK1206459A1 (zh) | 2013-12-09 | 2015-07-23 | 對數據庫中的庫存記錄信息進行更新的方法及裝置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310661789.0A CN104699712B (zh) | 2013-12-09 | 2013-12-09 | 对数据库中的库存记录信息进行更新的方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104699712A CN104699712A (zh) | 2015-06-10 |
CN104699712B true CN104699712B (zh) | 2018-05-18 |
Family
ID=53346845
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310661789.0A Active CN104699712B (zh) | 2013-12-09 | 2013-12-09 | 对数据库中的库存记录信息进行更新的方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN104699712B (zh) |
HK (1) | HK1206459A1 (zh) |
Families Citing this family (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106372071B (zh) * | 2015-07-20 | 2019-07-12 | 阿里巴巴集团控股有限公司 | 数据仓库的信息获取方法和装置 |
CN106469391A (zh) * | 2015-08-18 | 2017-03-01 | 阿里巴巴集团控股有限公司 | 扣减库存数据的方法和装置 |
CN106557482B (zh) * | 2015-09-25 | 2020-09-25 | 阿里巴巴集团控股有限公司 | 一种库存系统数据更新方法及装置 |
CN106845881A (zh) * | 2015-12-04 | 2017-06-13 | 阿里巴巴集团控股有限公司 | 一种库存异常数据的检测方法、装置及电子设备 |
US10296418B2 (en) * | 2016-01-19 | 2019-05-21 | Microsoft Technology Licensing, Llc | Versioned records management using restart era |
CN107203544A (zh) * | 2016-03-17 | 2017-09-26 | 阿里巴巴集团控股有限公司 | 一种业务处理方法和装置 |
CN107220142B (zh) * | 2016-03-22 | 2020-10-09 | 阿里巴巴集团控股有限公司 | 执行数据恢复操作的方法及装置 |
CN106055432A (zh) * | 2016-05-31 | 2016-10-26 | 乐视控股(北京)有限公司 | 目标项的库存备份方法、执行模块及系统 |
CN106097104A (zh) * | 2016-06-07 | 2016-11-09 | 众安在线财产保险股份有限公司 | 一种判断分布式系统下互联网数据完整性的方法和系统 |
CN106341449B (zh) * | 2016-08-15 | 2019-05-14 | 腾讯科技(深圳)有限公司 | 数据同步方法及装置 |
CN106326470A (zh) * | 2016-08-31 | 2017-01-11 | 无锡雅座在线科技发展有限公司 | 流式大数据的处理方法和装置 |
CN106446239A (zh) * | 2016-10-11 | 2017-02-22 | 北京集奥聚合科技有限公司 | 一种基于binlog的数据实时处理方法及系统 |
CN108062323B (zh) * | 2016-11-08 | 2021-10-15 | 北京国双科技有限公司 | 一种日志读取方法及装置 |
CN108108378B (zh) * | 2016-11-24 | 2023-04-07 | 阿里巴巴集团控股有限公司 | 数据对象库存信息处理方法及装置 |
CN108268474A (zh) * | 2016-12-30 | 2018-07-10 | 苏宁云商集团股份有限公司 | 一种库存管理的方法及装置 |
CN108335163A (zh) * | 2017-01-19 | 2018-07-27 | 阿里巴巴集团控股有限公司 | 一种同步对象信息的方法和系统,及同步库存的方法 |
CN106997557B (zh) * | 2017-03-23 | 2021-06-29 | 深圳市创梦天地科技有限公司 | 订单信息采集方法及装置 |
CN107248052A (zh) * | 2017-05-16 | 2017-10-13 | 上海艾融软件股份有限公司 | 一种商品库存信息确定方法、装置及系统 |
CN109872172A (zh) * | 2017-12-04 | 2019-06-11 | 北京京东尚科信息技术有限公司 | 用于处理信息的方法和装置 |
CN109886764B (zh) * | 2017-12-06 | 2021-01-26 | 航天信息股份有限公司 | 一种基于物料组合的商品去重方法和系统 |
CN108595488B (zh) * | 2018-03-15 | 2021-02-23 | 北京雷石天地电子技术有限公司 | 数据迁移方法和装置 |
CN109144980A (zh) * | 2018-08-21 | 2019-01-04 | 成都四方伟业软件股份有限公司 | 元数据管理方法、装置及电子设备 |
CN111325494A (zh) * | 2018-12-14 | 2020-06-23 | 北京京东尚科信息技术有限公司 | 库存管理方法、装置、系统及存储介质 |
CN109815262A (zh) * | 2018-12-27 | 2019-05-28 | 四川驹马科技有限公司 | 一种基于wal模式的库存管理方法及其系统 |
CN109872100A (zh) * | 2018-12-28 | 2019-06-11 | 航天信息股份有限公司 | 一种成品油库存变更管理方法及系统 |
CN110059135B (zh) * | 2019-04-12 | 2024-05-17 | 创新先进技术有限公司 | 一种数据同步方法和装置 |
CN110173830B (zh) * | 2019-04-26 | 2022-03-25 | 平安科技(深圳)有限公司 | 空调运行数据的监控方法及相关设备 |
CN110188139B (zh) * | 2019-05-05 | 2021-10-22 | 苏宁易购集团股份有限公司 | 库存数目同步方法、装置、计算机设备和存储介质 |
CN110321356B (zh) * | 2019-05-22 | 2021-08-03 | 卓尔智联(武汉)研究院有限公司 | 数据更新方法及系统、计算机装置及可读存储介质 |
CN111177110A (zh) * | 2019-06-11 | 2020-05-19 | 腾讯科技(深圳)有限公司 | 库存数据的处理方法及装置 |
CN110515803B (zh) * | 2019-08-27 | 2021-04-13 | 联想(北京)有限公司 | 针对日志消息的处理方法、装置以及电子设备 |
CN112116302A (zh) * | 2020-09-28 | 2020-12-22 | 中国建设银行股份有限公司 | 一种库存数据处理方法、装置及存储介质 |
CN113763097A (zh) * | 2020-12-14 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | 一种物品信息更新的方法和装置 |
CN113672682B (zh) * | 2021-08-18 | 2022-04-01 | 广州有信科技有限公司 | 一种基于同步帧的数量同步方法及同步装置 |
CN114253944B (zh) * | 2021-12-16 | 2022-10-04 | 深圳壹账通科技服务有限公司 | 数据库双向同步方法、装置和电子设备 |
CN117240799B (zh) * | 2023-11-16 | 2024-02-02 | 北京中科网芯科技有限公司 | 用于汇聚分流设备的报文去重方法及其系统 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1615487A (zh) * | 2002-01-23 | 2005-05-11 | 雀巢技术公司 | 用于库存管理的系统和方法 |
CN1656488A (zh) * | 2001-08-17 | 2005-08-17 | 艾克斯佩迪亚公司 | 管理库存的系统和方法 |
CN1701328A (zh) * | 2002-08-15 | 2005-11-23 | 庄臣及庄臣视力保护公司 | 手持式库存跟踪以及自动定单传输系统 |
CN101008996A (zh) * | 2006-01-25 | 2007-08-01 | 英业达股份有限公司 | 订单数据管理系统及方法 |
CN101901419A (zh) * | 2001-08-17 | 2010-12-01 | 艾克斯佩迪亚公司 | 用于管理对一个或多个目录项目的预订请求的系统和方法 |
CN102486844A (zh) * | 2010-12-01 | 2012-06-06 | 金蝶软件(中国)有限公司 | 一种erp系统中并发数据的处理方法及装置 |
CN103154986A (zh) * | 2010-10-05 | 2013-06-12 | e2因特莱科迪伏有限公司 | 用于进行复合账单支付交易的系统和方法 |
CN103189855A (zh) * | 2010-06-14 | 2013-07-03 | 特鲁塔格科技公司 | 用于使用数据库验证包装中的物品的系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10181126B2 (en) * | 2012-03-13 | 2019-01-15 | American Express Travel Related Services Company, Inc. | Systems and methods for tailoring marketing |
-
2013
- 2013-12-09 CN CN201310661789.0A patent/CN104699712B/zh active Active
-
2015
- 2015-07-23 HK HK15107026.6A patent/HK1206459A1/zh unknown
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1656488A (zh) * | 2001-08-17 | 2005-08-17 | 艾克斯佩迪亚公司 | 管理库存的系统和方法 |
CN101901419A (zh) * | 2001-08-17 | 2010-12-01 | 艾克斯佩迪亚公司 | 用于管理对一个或多个目录项目的预订请求的系统和方法 |
CN1615487A (zh) * | 2002-01-23 | 2005-05-11 | 雀巢技术公司 | 用于库存管理的系统和方法 |
CN1701328A (zh) * | 2002-08-15 | 2005-11-23 | 庄臣及庄臣视力保护公司 | 手持式库存跟踪以及自动定单传输系统 |
CN101008996A (zh) * | 2006-01-25 | 2007-08-01 | 英业达股份有限公司 | 订单数据管理系统及方法 |
CN103189855A (zh) * | 2010-06-14 | 2013-07-03 | 特鲁塔格科技公司 | 用于使用数据库验证包装中的物品的系统 |
CN103154986A (zh) * | 2010-10-05 | 2013-06-12 | e2因特莱科迪伏有限公司 | 用于进行复合账单支付交易的系统和方法 |
CN102486844A (zh) * | 2010-12-01 | 2012-06-06 | 金蝶软件(中国)有限公司 | 一种erp系统中并发数据的处理方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
HK1206459A1 (zh) | 2016-01-08 |
CN104699712A (zh) | 2015-06-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104699712B (zh) | 对数据库中的库存记录信息进行更新的方法及装置 | |
TW522320B (en) | Apparatus and method for recovering a failed database data set | |
CN111752957B (zh) | 一种基于缓存化的销售锁定方法及系统 | |
CN104598459A (zh) | 数据库处理、数据访问方法及系统 | |
CN103092903A (zh) | 数据库日志并行化 | |
CN108446317B (zh) | 一种房产交易可视化数据同步方法及装置 | |
CN104516895A (zh) | 商品对象库存信息处理方法及系统 | |
CN107464151A (zh) | 高并发业务的订单数据处理方法及装置 | |
CN109409865B (zh) | 支付限额同步调整方法、装置、计算机设备和存储介质 | |
WO2019033741A1 (zh) | 投资产品的资源处理方法、装置、存储介质和计算机设备 | |
US9207966B2 (en) | Method and system for providing a high-availability application | |
CN107015876A (zh) | 一种业务请求处理方法及装置 | |
CN103019826A (zh) | 一种事务处理的方法和装置 | |
US8073813B2 (en) | Refresh and filter anchors | |
CN106034148B (zh) | 一种快速信息交互方法、本地服务器、异地服务器及系统 | |
CN110069499B (zh) | 数据管理方法、装置、系统及存储介质 | |
CN106021597A (zh) | 用于账务交易的数据表更新的方法及系统 | |
CN107688581B (zh) | 数据模型的处理方法及装置 | |
US20200184440A1 (en) | Distributed point of sale server system | |
CN112416952A (zh) | 管理及同步库存数据的方法、设备、可读存储介质 | |
CN102193986A (zh) | 图形数据库中联机事务的实现方法 | |
CN114693331A (zh) | 一种零售行业经销商返利、资本性支出管理方法 | |
KR101722445B1 (ko) | 상품 구매 패턴에 기초한 상품 구매자 예상 지원 장치 및 방법 | |
CN110782313A (zh) | 一种基于分库分表的数据库事务处理方法及装置 | |
CN109359914A (zh) | 线上批发仓库管理方法、系统、终端设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1206459 Country of ref document: HK |
|
GR01 | Patent grant | ||
GR01 | Patent grant |