Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 03176449 2022-09-22
SALES LOCKING METHOD AND SYSTEM BASED ON CACHING
BACKGROUND OF THE INVENTION
Technical Field
[0001] The present invention relates to the field of computer software
technology, and more
particularly to a sales locking method based on caching, and a corresponding
system.
Description of Related Art
[0002] With the development of the internet, traditional stores are gradually
being replaced with
online shopping platforms. While more and more users choose online shopping,
in order
to attract users, online shopping platforms stage variegated sales promotional
activities,
such as "seckill", rush-purchase, and shopping-together, etc. High concurrency
is
instantaneously generated by such sales promotional activities, and a very
high demand
is put on the processing efficiency of the entire transaction link, in which
maintenance of
the stock quantity is a core segment, and highly efficient processing is also
of great
importance.
[0003] In the currently available stock deducting methods, sales locking
(temporary lock +
formal lock) and delivery locking (logistic delivery) are employed to maintain
stock
quantities based on the scheme of database + application lock technology, and
processing
of businesses is embodied as the serial processing mode, whereby processing
efficiency
is so extremely low that current business scenarios cannot be satisfied.
Particularly under
the rush-purchase scenario, sales locking requests of the same and single
commodity
appear highly concurrently, when the same commodity is concurrently requested,
the
request that obtains the lock first is firstly executed, and the following
requests are
sequentially executed only after having waited for the processing result to
have been
1
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
returned from the stock management system. Interaction with the database is
carried out
for several times during the entire process, a great deal of network time
delay is consumed;
moreover, the TPS processing capability of DB (database) is also limited, with
the
increase in quantity of data stored in DB (database), the TPS processing
capability also
gradually lowers, so that the processing time of the database is also
prolonged. The
purchasing interface of the user would be always in the waiting status, and
this greatly
lowers the online shopping experience of the customer.
[0004] In summary, the currently available stock deducting methods are
problematic as specified
below:
[0005] 1. The use of serial processing mode achieves low processing efficiency
in the case of
high concurrency;
[0006] 2. The same commodities are stored in a single database, while the
sales locking TPS for
the single DB to process the same commodities usually does not exceed 200, so
a high
demand is put on the performance of the database server. Moreover, several
tens of DBs
can only support over one thousand TPSs, the performance falls far short of
satisfying
such promotional businesses as seckill and rush-phase of hotspot commodities,
whereby
user experiences are rendered not good.
SUMMARY OF THE INVENTION
[0007] In order to solve problems pending in the state of the art, embodiments
of the present
invention provide a sales locking method based on caching, and a corresponding
system,
so as to address such prior-art problems in which the DB performance is
bottlenecked
during high concurrency processing in sales locking, the TPS processing
capability is low
during sales promotion and system stock is simple in structure, business
requirements
cannot be satisfied, and activities should be maintained in advance, and so
on.
[0008] In order to address one or more of the above technical problem(s), the
present invention
2
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
employs the following technical solutions.
[0009] According to the first aspect, there is provided a sales locking method
based on caching,
and the method comprises:
[0010] Si ¨modulo dividing commodity information into plural pieces according
to commodity
codes, and respectively storing the same information in cache libraries
correspondingly
coded by Redis according to a preset rule;
[0011] S2¨ obtaining and parsing a sales locking request of the commodities,
and obtaining a
request list;
[0012] S3 ¨ recording an inventory change intermediate sheet within the same
business
according to the request list, and thereafter updating the commodity
information in the
cache libraries correspondingly coded by Redis; and
[0013] S4¨ employing second-grade JOB to asynchronously update the commodity
information
in a database according to the inventory change intermediate sheet.
[0014] Further, step S3 specifically includes:
[0015] S3.1 ¨ choosing to start a multi-threads processing request or a single
thread processing
request according to number of piece(s) in the request list;
[0016] S3.2¨ traversing requests in the request list, verifying contents of
the requests, executing
step S3.3 if verification is passed, otherwise packaging any request not
passing the
verification, and continuously verifying remaining requests in the request
list;
[0017] S3.3¨ enquiring whether a given request is in a sales locking sheet, if
not, executing step
S3.4 after having newly added the request to the sales locking sheet,
otherwise directly
executing step S3.4; and
[0018] S3.4 ¨ recording the inventory change intermediate sheet, and updating
the commodity
information in the cache libraries correspondingly coded by Redis.
[0019] Further, the step of updating the commodity information in the cache
libraries
correspondingly coded by Redis specifically includes:
3
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
[0020] employing a Lua script to atomically manipulate a Redis cache,
calculating whether a
stock of commodities to which the request corresponds satisfies the request,
if yes,
modifying a stock quantity in the commodity information, otherwise returning
failure.
[0021] Further, step S4 specifically includes:
[0022] S4.1 ¨ enquiring whether there is data in the inventory change
intermediate sheet, if yes,
starting a DB business, and updating the commodity information in the
database,
otherwise performing no processing;
[0023] S4.2 ¨ judging whether the DB business operation is successful, if yes,
submitting the
DB business operation, otherwise executing step S4.3 after rollback; and
[0024] S4.3 ¨ executing the DB business operation anew according to the data
of the inventory
change intermediate sheet until execution succeeds.
[0025] Further, prior to the step of updating the commodity information in the
cache libraries
correspondingly coded by Redis according to the request list, the method
further
comprises:
[0026] setting grayscale statuses of commodities as in grayscale, out of
grayscale, and in
switching; and
[0027] judging the grayscale status of commodities to which a given request in
the request list
corresponds, and directly returning processing failure in the case that the
grayscale status
is in switching.
[0028] According to another aspect, there is provided a sales locking system
based on caching,
and the system comprises:
[0029] a dividing module, for modulo dividing commodity information into
plural pieces
according to commodity codes, and respectively storing the same information in
cache
libraries correspondingly coded by Redis according to a preset rule;
[0030] a parsing module, for obtaining and parsing a sales locking request of
the commodities,
and obtaining a request list;
4
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
[0031] a first updating module, for recording an inventory change intermediate
sheet within the
same business according to the request list, and thereafter updating the
commodity
information in the cache libraries correspondingly coded by Redis; and
[0032] a second updating module, for employing second-grade JOB to
asynchronously update
the commodity information in a database according to the inventory change
intermediate
sheet.
[0033] Further, the first updating module includes:
[0034] a first judging unit, for choosing to start a multi-threads processing
request or a single
thread processing request according to number of piece(s) in the request list;
[0035] a verifying unit, for traversing requests in the request list, and
verifying contents of the
requests;
[0036] a first enquiring unit, for enquiring whether a given request is in a
sales locking sheet;
and
[0037] a first updating unit, for recording the inventory change intermediate
sheet, and updating
the commodity information in the cache libraries correspondingly coded by
Redis.
[0038] Further, the first updating unit is specifically employed for:
[0039] employing a Lua script to atomically manipulate a Redis cache,
calculating whether a
stock of commodities to which the request corresponds satisfies the request,
if yes,
modifying a stock quantity in the commodity information, otherwise returning
failure.
[0040] Further, the second updating module includes:
[0041] a second enquiring unit, for enquiring whether there is data in the
inventory change
intermediate sheet;
[0042] a second judging unit, for judging whether a DB business operation is
successful, if yes,
submitting the DB business operation, otherwise executing the DB business
operation
anew according to data of the inventory change intermediate sheet after
rollback; and
[0043] a second updating unit, for starting a DB business, and updating the
commodity
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
information in the database.
[0044] Moreover, the system further comprises:
[0045] a setting module, for setting grayscale statuses of commodities as in
grayscale, out of
grayscale, and in switching; and
[0046] a judging module, for judging the grayscale status of commodities to
which a given
request in the request list corresponds, and directly returning processing
failure in the
case that the grayscale status is in switching.
[0047] The technical solutions provided by the embodiments of the present
invention bring about
the following advantageous effects.
[0048] The sales locking method and device based on caching provided by the
embodiments of
the present invention modulo divide commodity information into plural pieces
according
to commodity codes, and respectively store the same information in cache
libraries
correspondingly coded by Redis according to a preset rule, whereby is avoided
the use of
a single Redis cache library to store great quantities of data, and enquiring
efficiency is
enhanced.
[0049] In the sales locking method and device based on caching provided by the
embodiments
of the present invention, consistency of data is ensured by employing the
atomicity of
LUA scripts in replace of database businesses, and single-thread
characteristics of Redis
are made use of to perform concurrent control of the stock.
[0050] In the sales locking method and device based on caching provided by the
embodiments
of the present invention, processing efficiency is enhanced by placing the
complicated
data structure in cache (Redis cache libraries), and then employing LUA to
perform
enquiring calculation and deduction of stock quantity; moreover, the database
is
asynchronously updated through second-grade JOB, and the second-grade JOB is
set and
6
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
a retry mechanism is employed to finally ensure consistency between the cache
and data
in the database.
[0051] In the sales locking method and device based on caching provided by the
embodiments
of the present invention, three statuses as in grayscale, out of grayscale,
and in switching
are used to judge the location of data and to thereafter maintain the data,
and grayscale
statuses are employed to solve the problem concerning inconsistency between
cache and
database data caused by the processing of data when there is an incoming
request during
the process in which the data is switched to the cache.
BRIEF DESCRIPTION OF THE DRAWINGS
[0052] To describe the technical solutions in the embodiments of the present
invention more
clearly, drawings required to be used in the description of the embodiments
will be briefly
introduced below. Apparently, the drawings introduced below are merely
directed to some
embodiments of the present invention, while it is possible for persons
ordinarily skilled
in the art to acquire other drawings based on these drawings without spending
any
creative effort in the process.
[0053] Fig. 1 is a flowchart illustrating the sales locking method based on
caching according to
an exemplary embodiment;
[0054] Fig. 2 is a flowchart illustrating updating commodity information in
the cache libraries
correspondingly coded by Redis and recording the same information in the
inventory
change intermediate sheet according to the request list in an exemplary
embodiment;
[0055] Fig. 3 is a flowchart illustrating employing second-grade JOB to
asynchronously update
commodity information in the database according to the inventory change
intermediate
sheet according to an exemplary embodiment; and
7
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
[0056] Fig. 4 is a view schematically illustrating the structure of the sales
locking device based
on caching according to an exemplary embodiment.
DETAILED DESCRIPTION OF THE INVENTION
[0057] To make more lucid and clear the objectives, technical solutions and
advantages of the
present invention, the technical solutions in the embodiments of the present
invention will
be clearly and comprehensively described below with reference to the drawings
in the
embodiments of the present invention. Apparently, the embodiments as described
are
merely partial, rather than the entire, embodiments of the present invention.
All other
embodiments obtainable by persons ordinarily skilled in the art on the basis
of the
embodiments in the present invention and without spending any creative effort
shall all
be covered by the protection scope of the present invention.
[0058] In the sales locking method and device based on caching provided by the
embodiments
of the present invention, the stock is cached, and stock change in the cache
libraries are
synchronized with stock quantity in the DB (database) in an asynchronizing
mode
through the second-grade JOB, thus ensuring that the quantity in the cache
libraries and
the quantity in the DB are maintained consistent. When such a sales
promotional activity
as seckill or rush-purchase is carried out, the business of deducting stock is
no longer a
direct operation on the DB, but only an operation on the cache by deducting
the stock in
the cache, and a successful purchase is directly returned to the user if the
operation
succeeds. Data in the cache libraries is thereafter synchronized with data in
the DB in an
asynchronous mode, whereby processing efficiency is not only enhanced, but
bottleneck
of the database is also excellently dealt with, and purchasing experiences of
users are
enhanced at the same time.
[0059] Fig. 1 is a flowchart illustrating the sales locking method based on
caching according to
8
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
an exemplary embodiment. With reference to what is shown in Fig. 1, the method
comprises the following steps.
[0060] Si ¨modulo dividing commodity information into plural pieces according
to commodity
codes, and respectively storing the same information in cache libraries
correspondingly
coded by Redis according to a preset rule.
[0061] Specifically, a Redis cache library supports sixteen cache libraries by
default, as an
example, in the embodiments of the present invention, the commodity
information is
modulo (commodity codes usually consist of numerals, because the commodity
codes are
equally divided into sixteen pieces here, it is possible to multiply the
numerals (namely
the commodity codes) with %16, and the resultant data are precisely 0-15)
divided into
sixteen pieces according to commodity codes, and these are then respectively
stored in
Redis cache libraries coded 0-15 according to a preset rule (for instance, the
commodity
codes are multiplied with %16, whose result is 0 it is placed in library 0,
whose result is
1 it is placed in library 1, so on and so forth, whose result is 15 it is
placed in library 15).
Such setting makes it possible that the data are stored in the sixteen
libraries as far as
practically possible, and it is avoided to use a single Redis cache library to
store great
quantities of data to thereby render it problematic that the enquiring speed
is low, that is
to say, the pressure on the single library is reduced, and the enquiring
efficiency is
enhanced. As should be noted here, the Redis cache library being set as
sixteen cache
libraries is merely by way of example, as it is possible for the user to
modify the number
of cache libraries supported by Redis through configuration parameters
databases
according to specific requirements, and to divide the commodity information
into pieces
identical with the number of cache libraries supported by Redis.
[0062] S2 ¨ obtaining and parsing a sales locking request of the commodities,
and obtaining a
request list.
9
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
[0063] Specifically, after the sales locking request of commodities has been
obtained from a
peripheral system (an e-commerce sales platform here), the sales locking
request is firstly
processed by being parsed, and operation is performed after a request list has
been
obtained by successful parsing, if parsing fails, failure is directly
returned. The request at
least includes the sales phase such as deduction of the stock of the
commodities, the
peripheral system can newly add sales locking records, modify stock quantity
of the Redis
cache libraries, and record the inventory change intermediate table by
invoking a real-
time locking interface, and the result is thereafter returned to the
peripheral system.
[0064] S3 ¨ recording an inventory change intermediate sheet within the same
business
according to the request list, and thereafter updating the commodity
information in the
cache libraries correspondingly coded by Redis.
[0065] Specifically, updating the commodity information in the cache libraries
correspondingly
coded by Redis includes to modify stock quantity of corresponding commodities
in the
Redis cache libraries. In the embodiments of the present invention, the
complicated data
structure is placed in cache, enquiring calculation and deduction are then
performed on
the stock quantity in the cache, whereby interaction with the database is
reduced, and
processing efficiency is enhanced. As should be noted here, the placements of
DB
operation (namely to record the inventory change intermediate sheet) and cache
operation
in the business of DB, and the preferential processing of the DB operation and
the
subsequent processing of the cache at least achieve the following advantages:
(1) direct
rollback is made in the case DB operation fails, while the cache is not
operated; (2) in the
case DB operation succeeds and cache fails, DB will also be rolled back; (3)
in the case
DB operation and cache operation both succeed, the operation can be counted as
successful, and the problem is avoided in which it is difficult to roll back
cache in the
case DB operation fails. If change occurs to this sequence (i.e., cache is
preferentially
processed, and DB operation is subsequently processed), there will be the
circumstance
in which cache operation succeeds but DB operation fails, DB can be normally
rolled
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
back, but Redis has already been successfully operated, then artificial
rollback is required,
but rollback of Redis is rather complicated, and tends to cause the
probability of error.
[0066] S4 ¨ employing second-grade JOB to asynchronously update the commodity
information
in a database according to the inventory change intermediate sheet.
[0067] Specifically, commodity information (stock quantity, etc.) of
corresponding commodities
in the database is updated through the second-grade JOB asynchronously
according to
modification records in the inventory change intermediate sheet. In the
embodiments of
the present invention, the second-grade JOB employs the retry and manually
processing
mechanisms, should error occur in the synchronizing process, automatic retry
will be
made, should it still fail after a certain number of retries, the process will
stop
synchronizing the current piece of data, and the remaining data is
subsequently executed;
data failed to be processed can be manually maintained to the database, and
data (such as
stock quantity) in the database is finally made consistent with data of the
Redis cache
libraries.
[0068] Fig. 2 is a flowchart illustrating updating commodity information in
the cache libraries
correspondingly coded by Redis and recording the same information in the
inventory
change intermediate sheet according to the request list in an exemplary
embodiment, with
reference to what is shown in Fig. 2, as a preferred mode of execution in the
embodiments
of the present invention, step S3 specifically includes the following.
[0069] S3.1 ¨ choosing to start a multi-threads processing request or a single
thread processing
request according to number of piece(s) in the request list.
[0070] Specifically, the number of piece(s) of request(s) in the request list
is enquired to judge
whether to start multi-threads processing, if the number of piece(s) of
request(s) satisfies
the condition of multi-threads processing, a multi-threads processing request
is started,
11
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
otherwise a single thread processing request is started. As a preferred mode
of execution
in the embodiments of the present invention, a threshold can be set in
advance, and the
number of piece(s) of request(s) is compared with the preset threshold, if the
number of
piece(s) of request(s) is greater than the threshold, the multi-threads
processing request is
started, otherwise the single thread processing request is started. As should
be noted here,
the threshold can be set according to practical requirements of the user.
[0071] S3.2 ¨ traversing requests in the request list, verifying contents of
the requests, executing
step S3.3 if verification is passed, otherwise packaging any request not
passing the
verification, and continuously verifying remaining requests in the request
list.
[0072] Specifically, requests in the request list are cyclically processed,
before any request is
processed, the content of the request should be verified, execution is
continued (namely
executing step S3.3) if verification is passed, if verification is not passed,
the request not
passing the verification is packaged, and remaining requests in the request
list are
continuously verified.
[0073] S3.3¨ enquiring whether a given request is in a sales locking sheet, if
not, executing step
S3.4 after having newly added the request to the sales locking sheet,
otherwise directly
executing step S3.4.
[0074] Specifically, after verification of the request has succeeded, it is
enquired whether the
current request is already in the sales locking sheet, if yes, the next step
is continuously
executed (namely executing step S3.4), otherwise it is required to firstly
newly add the
request to the sales locking sheet, and thereafter to continuously execute the
next step
(namely executing step S3.4). Newly adding the request to the sales locking
sheet can be
carried out by invoking a sales component newly adding process. The procedure
of
invoking a sales component newly adding process includes: storing sales record
to which
this request corresponds in the database, and recording the sales record in
the inventory
12
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
change intermediate sheet.
[0075] S3.4 ¨ recording the inventory change intermediate sheet, and updating
the commodity
information in the cache libraries correspondingly coded by Redis.
[0076] Specifically, the sales record to which the request corresponds is
firstly recorded in the
inventory change intermediate sheet according to the sales record to which the
request
corresponds, and the corresponding commodity information in the cache
libraries
correspondingly coded by Redis is then updated, updating of the commodity
information
includes modifying the stock quantity, etc. Consistency of data in the Redis
cache libraries
and in the database is ensured.
[0077] As a preferred mode of execution in the embodiments of the present
invention, the step
of updating the commodity information in the cache libraries correspondingly
coded by
Redis specifically includes:
[0078] employing a Lua script to atomically manipulate a Redis cache,
calculating whether a
stock of commodities to which the request corresponds satisfies the request,
if yes,
modifying a stock quantity in the commodity information, otherwise returning
failure.
[0079] Specifically, in the embodiments of the present invention, atomicity of
the LUA script is
employed in place of the Redis distributed lock to perform stock concurrent
control. The
complicated data structure (such data as the commodity sales record) is placed
in cache,
the LUA script is then employed to perform enquiring calculation on the stock
quantity
(to calculate whether a stock of commodities to which the request corresponds
satisfies
the request), if yes, the following requests are continuously processed after
the stock
quantity in the commodity information has been modified, otherwise failure is
returned.
The LUA script is used to merge together the two operations of selecting the
Redis library
and operating the Redis library, and it is further possible to ensure the
correctness of
selecting the Redis library and operating the Redis library under the
concurrent
13
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
circumstance, that is to say, it is ensured that the Redis library can be
correctly selected
and the data can be correctly operated each time.
[0080] Fig. 3 is a flowchart illustrating employing second-grade JOB to
asynchronously update
commodity information in the database according to the inventory change
intermediate
sheet according to an exemplary embodiment, with reference to what is shown in
Fig. 3,
as a preferred mode of execution in the embodiments of the present invention,
step S4
specifically includes the following.
[0081] S4.1 ¨ enquiring whether there is data in the inventory change
intermediate sheet, if yes,
starting a DB business, and updating the commodity information in the
database,
otherwise performing no processing.
[0082] Specifically, it is firstly enquired whether there is data in the
inventory change
intermediate sheet, if yes, this indicates that the commodity information in
the cache
libraries correspondingly coded by Redis has been updated, the DB business is
started at
this time, and the commodity information in the database is updated according
to the
inventory change intermediate sheet; if not, this indicates that the commodity
information
in the cache libraries correspondingly coded by Redis has not been updated, no
processing
is performed at this time, and the process is directly terminated. The DB
business includes
such operations as modifying quantity in a corresponding commodity stock
quantity sheet,
storing flow, storing commodity status, and storing and dispatching the
intermediate sheet,
etc.
[0083] S4.2 ¨ judging whether the DB business operation is successful, if yes,
submitting the
DB business operation, otherwise executing step S4.3 after rollback.
[0084] Specifically, after the DB business operation has been completed, it is
further required to
judge whether the DB business operation this time is successful, if yes, the
DB business
14
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
operation is submitted, otherwise the next step is executed (namely executing
step S4.3)
after rollback. Such operation can prevent the database from being
superficially updated
but actually not updated, thus effectively ensuring consistency of data in the
cache
libraries and in the database.
[0085] S4.3 ¨ executing the DB business operation anew according to the data
of the inventory
change intermediate sheet until execution succeeds.
[0086] Specifically, in the embodiments of the present invention, the second-
grade JOB starts
the retry mechanism, in the case of rollback, data is executed again until
execution
succeeds. As should be noted here, in the embodiments of the present
invention, the
second-grade JOB further employs the manually processing mechanism, and a
threshold
of number of retries is set in advance. If error occurs in the synchronizing
process, retry
will be automatically carried out, once the threshold of number of retries is
exceeded, the
process stops synchronizing the current piece of data, and continues to
execute the
remaining data, the data failed to be processed is maintained to the database
through
manual processing (human operation), and the data in the stock quantity sheet
and the
data of the Redis cache are maintained consistent.
[0087] As a preferred mode of execution in the embodiments of the present
invention, prior to
the step of updating the commodity information in the cache libraries
correspondingly
coded by Redis according to the request list, the method further comprises:
[0088] setting grayscale statuses of commodities as in grayscale, out of
grayscale, and in
switching; and
[0089] judging the grayscale status of commodities to which a given request in
the request list
corresponds, and directly returning processing failure in the case that the
grayscale status
is in switching.
[0090] Specifically, the grayscale status of the commodities is set as three
statuses of in grayscale,
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
out of grayscale, and in switching, the location of the data is judged by
means of the three
statuses of in grayscale, out of grayscale, and in switching, and the data is
thereafter
maintained. When there is data requested to be maintained, it is required to
firstly judge
the grayscale status of the current commodity, if the grayscale status is in
switching,
processing failure is directly returned. After the cache stock quantity has
been maintained,
it is required to check the grayscale status of the current data again, if the
grayscale status
is in switching, processing failure is returned, and data in the cache is
rolled back
according to the procedural flow to avoid modifying data in the data switching
process to
cause the problem of inconsistency between data of the cache and data of the
database.
[0091] Fig. 4 is a view schematically illustrating the structure of the sales
locking device based
on caching according to an exemplary embodiment, with reference to Fig. 4, the
device
comprises:
[0092] a dividing module, for modulo dividing commodity information into
plural pieces
according to commodity codes, and respectively storing the same information in
cache
libraries correspondingly coded by Redis according to a preset rule;
[0093] a parsing module, for obtaining and parsing a sales locking request of
the commodities,
and obtaining a request list;
[0094] a first updating module, for recording an inventory change intermediate
sheet within the
same business according to the request list, and thereafter updating the
commodity
information in the cache libraries correspondingly coded by Redis; and
[0095] a second updating module, for employing second-grade JOB to
asynchronously update
the commodity information in a database according to the inventory change
intermediate
sheet.
[0096] As a preferred mode of execution in the embodiments of the present
invention, the first
updating module includes:
[0097] a first judging unit, for choosing to start a multi-threads processing
request or a single
thread processing request according to number of piece(s) in the request list;
16
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
[0098] a verifying unit, for traversing requests in the request list, and
verifying contents of the
requests;
[0099] specifically, the next step is executed if verification is passed,
namely to enquire whether
the request is in the sales locking sheet; if verification is not passed, the
request not
passing the verification is packaged, and the remaining requests in the
request list are
continuously verified;
[0100] a first enquiring unit, for enquiring whether a given request is in a
sales locking sheet;
[0101] specifically, if the request is not in the sales locking sheet, the
next step is executed
(updating the commodity information in the cache libraries correspondingly
coded by
Redis, and generating an inventory change intermediate sheet) after the
request has been
newly added to the sales locking sheet, otherwise the next step is directly
executed
(updating the commodity information in the cache libraries correspondingly
coded by
Redis, and generating an inventory change intermediate sheet);
[0102] a first updating unit, for recording the inventory change intermediate
sheet, and updating
the commodity information in the cache libraries correspondingly coded by
Redis.
[0103] As a preferred mode of execution in the embodiments of the present
invention, the first
updating unit is specifically employed for:
[0104] employing a Lua script to atomically manipulate a Redis cache,
calculating whether a
stock of commodities to which the request corresponds satisfies the request,
if yes,
modifying a stock quantity in the commodity information, otherwise returning
failure.
[0105] As a preferred mode of execution in the embodiments of the present
invention, the second
updating module includes:
[0106] a second enquiring unit, for enquiring whether there is data in the
inventory change
intermediate sheet;
[0107] a second judging unit, for judging whether a DB business operation is
successful, if yes,
submitting the DB business operation, otherwise executing the DB business
operation
anew according to data of the inventory change intermediate sheet after
rollback; and
17
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
[0108] a second updating unit, for starting a DB business, and updating the
commodity
information in the database.
[0109] As a preferred mode of execution in the embodiments of the present
invention, the device
further comprises:
[0110] a setting module, for setting grayscale statuses of commodities as in
grayscale, out of
grayscale, and in switching; and
[0111] a judging module, for judging the grayscale status of commodities to
which a given
request in the request list corresponds, and directly returning processing
failure in the
case that the grayscale status is in switching.
[0112] In summary, the technical solutions provided by the embodiments of the
present invention
bring about the following advantageous effects.
[011311. The sales locking method and device based on caching provided by the
embodiments
of the present invention modulo divide commodity information into plural
pieces
according to commodity codes, and respectively store the same information in
cache
libraries correspondingly coded by Redis according to a preset rule, whereby
is avoided
the use of a single Redis cache library to store great quantities of data, and
enquiring
efficiency is enhanced.
[0114] 2. In the sales locking method and device based on caching provided by
the embodiments
of the present invention, consistency of data is ensured by employing the
atomicity of
LUA scripts in replace of database businesses, and single-thread
characteristics of Redis
are made use of to perform concurrent control of the stock.
[0115] 3. In the sales locking method and device based on caching provided by
the embodiments
of the present invention, processing efficiency is enhanced by placing the
complicated
data structure in cache (Redis cache libraries), and then employing LUA to
perform
18
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
enquiring calculation and deduction of stock quantity; moreover, the database
is
asynchronously updated through second-grade JOB, and the second-grade JOB is
set and
a retry mechanism is employed to finally ensure consistency between the cache
and data
in the database.
[0116] 4. In the sales locking method and device based on caching provided by
the embodiments
of the present invention, three statuses as in grayscale, out of grayscale,
and in switching
are used to judge the location of data and to thereafter maintain the data,
and grayscale
statuses are employed to solve the problem concerning inconsistency between
cache and
database data caused by the processing of data when there is an incoming
request during
the process in which the data is switched to the cache.
[0117] As should be noted, when the sales locking device based on caching
provided by the
aforementioned embodiment triggers a sales locking business, the division into
the
aforementioned various functional modules is merely by way of example, while
it is
possible, in actual application, to assign the functions based on requirements
to different
functional modules for completion, that is to say, to divide the internal
structure of the
device into different functional modules to complete the entire or partial
functions
described above. In addition, the sales locking device based on caching
provided by the
aforementioned embodiment pertains to the same conception as the sales locking
method
based on caching provided by the method embodiment, that is to say, the device
is based
on the sales locking method based on caching ¨ see the corresponding method
embodiment for its specific realization process, while no repetition will be
made in this
context.
[0118] As understandable by persons ordinarily skilled in the art, realization
of the entire or
partial steps of the aforementioned embodiments can be completed by hardware,
or by a
program instructing relevant hardware, the program can be stored in a computer-
readable
storage medium, and the storage medium can be a read-only memory, a magnetic
disk, or
19
Date Regue/Date Received 2022-09-22
CA 03176449 2022-09-22
an optical disk, etc.
[0119] What is described above is merely directed to preferred embodiments of
the present
invention, and is not meant to restrict the present invention. Any
modification, equivalent
substitution, and improvement makeable within the spirit and principle of the
present
invention shall all be covered by the protection scope of the present
invention.
Date Regue/Date Received 2022-09-22
