Data processing method and related device

Abstract

The invention provides a data processing method and a related device, and relates to the technical field of data processing. After primary screening is carried out through an addition limiting condition of a first target playlist, a target distributed lock matched with the payment type of the first target playlist is configured for a target audio by utilizing an atomization script, and whether the target audio is configured with at least one distributed lock conflicting with a playlist processing request or not is judged; only under the condition that the target audio is not configured with at least one distributed lock conflicting with the playlist processing request, the operation of adding the target audio into the first target playlist can be executed, and it is ensured that only one user performs the playlist adding operation on the same target audio at the same moment; the problems that the binding service rule of the audio and the playlist is violated and the reliability of the association relationship operation is reduced due to the fact that multiple users carry out the playlist adding operation on the same target audio at the same moment are avoided, and the operation accuracy of the association relationship of the audio and the playlist is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a data processing method and related devices. Background Art

[0002] A playlist is a tool for classifying and managing PUGC (Professional User Generated Content) audio and video. It is mainly used to organize and display multiple PUGC audio and video according to specific themes or categories.

[0003] In actual scenarios, during operation, the audio content management platform faces the situation where a large number of users initiate operations on the association relationship between audio and playlists almost simultaneously (including but not limited to adding, removing, converting free playlists to paid playlists, and converting paid playlists to free playlists, etc.). At this time, how to ensure the accuracy of the operations on the association relationship between audio and playlists is a technical problem that technical personnel in this field urgently need to solve. Summary of the Invention

[0004] In view of the above problems, this application provides a data processing method and related devices to achieve the purpose of improving the accuracy of the association between audio and playlists. The specific solution is as follows:

[0005] The first aspect of the present application provides a data processing method, comprising:

[0006] Get the user's playlist processing request;

[0007] In a case where the playlist processing request is used to add the target audio to the first target playlist, determining whether the target audio meets the addition restriction condition of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist;

[0008] If the inclusion restriction condition of the first target playlist is not met, a target distributed lock matching the payment type of the first target playlist is configured for the target audio using a distributed lock configuration method matching the payment type of the first target playlist based on a preset atomization script in the remote dictionary service Redis;

[0009] Determining whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; wherein, before performing an operation on the target audio, configuring a distributed lock corresponding to the operation for the target audio;

[0010] If the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request, performing an operation of adding the target audio to the first target playlist;

[0011] Release the target distributed lock;

[0012] If the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, an operation conflict prompt message is output and the target distributed lock is released.

[0013] In a possible implementation, determining whether the target audio meets the inclusion restriction condition of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist includes:

[0014] Querying the payment type of the first target playlist in the playlist configuration information, and querying the payment type of the target audio in the audio configuration information;

[0015] When the payment type of the target audio is the first type, determining that the target audio meets the joining restriction condition of the first target playlist;

[0016] In the case where the payment type of the target audio is the second type, if the payment type of the first target playlist is the second type, it is determined that the target audio does not meet the joining restriction conditions of the first target playlist, or, if the payment type of the first target playlist is the first type and the target audio has been added to other playlists, it is determined that the target audio meets the joining restriction conditions of the first target playlist, or, if the payment type of the first target playlist is the first type and the target audio has not been added to other playlists, it is determined that the target audio does not meet the joining restriction conditions of the first target playlist.

[0017] In a possible implementation, configuring a target distributed lock that matches the payment type of the first target playlist for the target audio using a distributed lock configuration method that matches the payment type of the first target playlist includes:

[0018] In a case where the payment type of the first target playlist is the first type, a target distributed lock corresponding to the first type is configured for the target audio using a conditional distributed lock configuration method;

[0019] In the case that the payment type of the first target playlist is the second type, a target distributed lock corresponding to the second type is configured for the target audio using a distributed lock configuration method without conditions.

[0020] In one possible implementation, determining whether the target audio is configured with at least one distributed lock that conflicts with the playlist processing request includes:

[0021] In a case where the payment type of the first target playlist is the second type, determining whether the target audio has been configured with a distributed lock corresponding to the first type;

[0022] If a distributed lock corresponding to the first type has been configured, it is determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request;

[0023] If the distributed lock corresponding to the first type is not configured, determining whether the target audio has been configured with a distributed lock corresponding to the payment type conversion operation;

[0024] If a distributed lock corresponding to the payment type conversion operation has been configured, it is determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request;

[0025] In a case where the payment type of the first target playlist is the first type, determining whether the target audio has been configured with a distributed lock corresponding to the second type;

[0026] If a distributed lock corresponding to the second type has been configured, it is determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request.

[0027] In a possible implementation, releasing the target distributed lock includes:

[0028] Obtaining the reception time of the playlist processing request;

[0029] Using the reception time to determine whether the user is a distributed lock holder;

[0030] If so, the target distributed lock is released.

[0031] In a possible implementation, the method further includes:

[0032] In the case where the playlist processing request is used to change the payment type of the second target playlist, a producer module is used to construct a structured message of the playlist processing request, and the structured message is stored in a preset message queue;

[0033] In a case where the payment type of the second target playlist is changed from the first type to the second type, the consumer module is used to obtain the structured message from the preset message queue, and the payment type of each audio in the second target playlist is changed from the first type to the second type;

[0034] In the case where the payment type of the second target playlist is changed from the second type to the first type, the consumer module is used to obtain the structured message from the preset message queue, and a distributed lock corresponding to the payment type conversion operation is set for each audio in the second target playlist, and the payment type of each audio in the second target playlist is changed from the second type to the first type.

[0035] In a possible implementation, the method further includes:

[0036] Use hash algorithm to store the distributed locks corresponding to each operation.

[0037] A second aspect of the present application provides a data processing device, including:

[0038] Request acquisition module, used to obtain the user's playlist processing request;

[0039] a determination module configured to, when the playlist processing request is for adding the target audio to the first target playlist, determine whether the target audio satisfies a restriction condition for adding the target audio to the first target playlist based on a payment type of the target audio and a payment type of the first target playlist;

[0040] a configuration module configured to, if the inclusion restriction condition of the first target playlist is not met, configure a target distributed lock for the target audio that matches the payment type of the first target playlist using a distributed lock configuration method that matches the payment type of the first target playlist based on a preset atomization script in the remote dictionary service Redis;

[0041] a determination module, configured to determine whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; wherein, before performing an operation on the target audio, a distributed lock corresponding to the operation is configured for the target audio;

[0042] an operation execution module, configured to, if the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request, execute an operation of adding the target audio to the first target playlist;

[0043] A release module, configured to release the target distributed lock;

[0044] an output module, configured to output an operation conflict prompt message if the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request;

[0045] The release module is further configured to release the target distributed lock after the output module outputs the operation conflict prompt information.

[0046] A third aspect of the present application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0047] The memory is used to store computer programs;

[0048] The processor is used to execute the computer program so that the electronic device can implement the above-mentioned data processing method.

[0049] In a fourth aspect, the present application provides a computer storage medium, which carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement the above-mentioned data processing method.

[0050] By means of the above technical solution, the present application provides a data processing method and related devices. In the present application, after a screening is performed by the joining restriction conditions of the first target playlist, a target distributed lock matching the payment type of the first target playlist is configured for the target audio, and it is determined whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request. If the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, an operation conflict prompt message is output. Only when the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request will the operation of adding the target audio to the first target playlist be executed, ensuring that at the same time, only one user performs a playlist joining operation on the same target audio, avoiding the violation of the business rules for binding audio and playlists caused by multiple users performing playlist joining operations on the same target audio at the same time, reducing the reliability of the association operation, and improving the accuracy of the operation of the association relationship between audio and playlists. In addition, the present application can also release the target distributed lock to ensure that other users can normally perform the association operation between audio and playlists. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The above and other features, advantages, and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that the originals and elements are not necessarily drawn to scale.

[0052] Figure 1 A flowchart of a data processing method provided in an embodiment of the present application;

[0053] Figure 2 A schematic diagram of conflict determination provided in an embodiment of the present application;

[0054] Figure 3A flowchart of audio playlist association constraints provided in an embodiment of the present application;

[0055] Figure 4 A flowchart of a playlist type change provided in an embodiment of the present application;

[0056] Figure 5 A flowchart of asynchronous cascading update of a payment type provided in an embodiment of the present application;

[0057] Figure 6 A schematic diagram of the structure of a data processing device provided in an embodiment of the present application;

[0058] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] The following describes the embodiments of the present application in conjunction with the accompanying drawings. The terms used in the implementation methods of the present application are only used to explain the specific embodiments of the present application and are not intended to limit the present application.

[0060] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0061] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, and this is merely a way of distinguishing the objects of the same attributes when describing them in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0062] In order to enable those skilled in the art to have a clearer understanding of the present application, the professional terms in the present application are now explained.

[0063] PUGC audio: audio produced by professional users, non-copyrighted audio.

[0064] Playlist: A tool for classifying and managing PUGC audio and video, mainly used to organize and display multiple PUGC audio and video according to specific themes or categories.

[0065] Playlist-associated audio: Add approved PUGC audio to the designated playlist in a certain order and include it in the playlist distribution sequence.

[0066] High concurrency: This refers to a technical scenario in which, during operation, the audio content management platform faces a large number of users almost simultaneously initiating operations on the relationship between audio and playlists (including but not limited to adding, removing, converting free playlists to paid playlists, and converting paid playlists to free playlists).

[0067] Lua scripts are code snippets written in the Lua scripting language, a lightweight, embeddable programming language. In the Redis (Remote Dictionary Server) database system, these scripts are executed atomically using the EVAL or SCRIPTLOAD commands.

[0068] Redis HashTag: refers to a data routing rule in a Redis sharded cluster (Cluster mode). It uses curly braces {} to wrap specific substrings in the key name, forcing keys with the same hash tag HashTag to be assigned to the same shard node.

[0069] To improve user experience and content distribution efficiency, audio content management systems (CMSs) typically categorize, aggregate, and recommend audio content through playlists (also known as albums, songlists, etc.). A key operation in playlist management is adding audio content to a specific playlist. However, this operation involves more than simply linking data; it often requires compliance with a series of business rules, such as content permissions, payment attributes, and association restrictions.

[0070] In one implementation, a relational database can be used for real-time data query to complete a series of precondition verifications and add audio content to a specified playlist. Using mutually exclusive restrictions and binding rules as business rules and "adding audio to a playlist" as an example, the detailed process is as follows:

[0071] 1. Audio attribute verification: Query the target audio information from the audio table audioinfo. If the audio is paid, association is not allowed and the process ends; otherwise, if it is free, proceed to the next step.

[0072] 2. Playlist attribute verification: Query the target playlist information from the playlist table broadlist. If the playlist is free, the association is allowed and the process ends; otherwise, if the playlist is paid, proceed to the next step.

[0073] 3. Audio playlist association check: Query the playlist audio relationship table broadlistAudio to see if the target audio already exists in other playlists. If the audio is already associated with other playlists, the addition operation is not allowed and the process ends; otherwise, if there is no association, the addition is allowed and the operation is completed.

[0074] The above operations work well in low-concurrency scenarios. However, in high-concurrency scenarios, a large number of users initiate operations on the association between audio and playlists almost simultaneously. At this time, the lack of a concurrency control mechanism can easily lead to the violation of business rules and the inability to guarantee the accuracy of the operations on the association between audio and playlists.

[0075] To this end, the present application provides a data processing method and related devices. In the present application, after a screening through the joining restriction conditions of the first target playlist, the preset atomic script based on Redis is used to configure a target distributed lock that matches the payment type of the first target playlist for the target audio and determine whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request. If the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, an operation conflict prompt message is output. Only when the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request will the operation of adding the target audio to the first target playlist be executed, ensuring that at the same time, only one user performs a playlist joining operation on the same target audio, avoiding the violation of the business rules for binding audio and playlists caused by multiple users performing playlist joining operations on the same target audio at the same time, reducing the reliability of the association operation, and improving the accuracy of the operation of the association relationship between audio and playlists. In addition, the present application can also release the target distributed lock to ensure that other users can perform the association operation of audio and playlists normally.

[0076] Based on the above content, an embodiment of the present application provides a data processing method, the execution subject can be a server, processor and other devices. Figure 1 , a data processing method may include:

[0077] S11. Obtain the user's playlist processing request.

[0078] In practice, users can generate playlist processing requests through operations on the user interface. These requests can include: a user or operator adding an audio track to a paid playlist, an operator changing a playlist from free to paid, and so on. For example, an operator can add audio track A to playlist 1 or change the payment type of playlist 2 from paid to free through the user interface.

[0079] S12. Determine whether the target audio meets the inclusion restriction conditions of the first target playlist; if not, execute step S13.

[0080] Specifically, when the playlist processing request is used to add the target audio to the first target playlist, based on the payment type of the target audio and the payment type of the first target playlist, it is determined whether the target audio meets the addition restriction conditions of the first target playlist.

[0081] In specific implementation, if the user adds the target audio to the first target playlist on the operation interface, the user only adds the target audio to the first target playlist from the operation interface, and also needs to add the target audio to the first target playlist in the database. At this time, the user's playlist processing request is to add the target audio to the first target playlist in the database.

[0082] After responding to the playlist processing request, it is first necessary to determine whether the target audio meets the joining restriction conditions of the first target playlist.

[0083] The adding restriction condition may be configured according to the actual scenario, and the design principle of the adding restriction condition is: mutually exclusive restrictions and binding rules for audio to be added to the playlist.

[0084] Among them, the mutually exclusive restriction means that an audio content can only be added to one paid playlist or multiple free playlists, but cannot be associated with a paid playlist and a free playlist at the same time.

[0085] The binding rule means that the payment type of the audio is automatically determined by the type of the playlist it is associated with. If the audio is associated with a paid playlist, the payment type of the audio is paid; otherwise, the payment type is free.

[0086] Due to the above-mentioned mutual exclusion restrictions and binding rules for adding audio to a playlist, in high-concurrency scenarios, for example, when a large number of users simultaneously initiate operations on the association between audio and playlists, the logical mechanism that relies on reading the database for verification can easily cause the above-mentioned mutual exclusion restrictions and binding rules to be destroyed, resulting in a significant reduction in system reliability.

[0087] To this end, in an embodiment of the present application, in order to avoid the destruction of the above-mentioned mutually exclusive restrictions and binding rules, first, based on the payment type of the target audio and the payment type of the first target playlist, it is determined whether the target audio meets the joining restriction conditions of the first target playlist.

[0088] In one implementation, determining whether the target audio meets the inclusion restriction condition of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist may include:

[0089] 1) Query the payment type of the first target playlist in the playlist configuration information, and query the payment type of the target audio in the audio configuration information.

[0090] In a specific implementation, the playlist configuration information can be the aforementioned playlist table "broadlist," and the audio configuration information can be the aforementioned audio table "audioinfo." The playlist configuration information and audio configuration information can be stored in a relational database for association constraint verification. In addition to storing the playlist configuration information and audio configuration information, the relational database can also store the aforementioned playlist-audio relationship table "broadlistAudio."

[0091] In specific implementation, there are many associated constraints when adding audio to a playlist. In the initial screening stage of the audio addition request, this embodiment directly queries the relational database to perform associated constraint verification to ensure that the verification result is based on the system's only trusted data source, providing a benchmark for subsequent high-concurrency verification. This embodiment uses the scenario of concurrently adding audio to a playlist as an example for illustration. The playlist table broadlist is configured with the payment type of the playlist, which can be paid or free. The audio table audioinfo is configured with the payment type of the audio, which can be paid or free. The playlist audio relationship table broadlistAudio stores the correspondence between the playlist and the audio, such as playlist 1 includes audio A, B, and C.

[0092] In this embodiment, the payment type of the first target playlist requested by the user is first queried from the playlist table broadlist. The payment type can be paid or free. Furthermore, the payment type of the target audio is also queried from the audio table audioinfo. The payment type can be paid or free. In one implementation, to distinguish between paid and free, paid can be referred to as the first type, and free can be referred to as the second type.

[0093] 2) When the payment type of the target audio is the first type, it is determined that the target audio meets the joining restriction condition of the first target playlist.

[0094] Among them, the first type refers to payment. When the user requests to add the target audio to the first target playlist, when the payment type of the target audio is paid, it means that the target audio has been added to other paid playlists, which makes the payment type of the target audio paid. At this time, it means that the target audio meets the joining restriction conditions of the first target playlist. The target audio is not allowed to be added to the first target playlist, and an error prompt is returned to the user: "The audio has been associated with a paid playlist and cannot be added to other playlists."

[0095] 3) In the case where the payment type of the target audio is the second type, if the payment type of the first target playlist is the second type, it is determined that the target audio does not meet the joining restriction conditions of the first target playlist, or, if the payment type of the first target playlist is the first type and the target audio has been added to other playlists, it is determined that the target audio meets the joining restriction conditions of the first target playlist, or, if the payment type of the first target playlist is the first type and the target audio has not been added to other playlists, it is determined that the target audio does not meet the joining restriction conditions of the first target playlist.

[0096] The second type is free. If the payment type of the target audio is free, and the payment type of the first target playlist is the second type (i.e., free), then the free target audio needs to be added to the free playlist. According to the aforementioned mutual exclusion restriction, since a free audio can be added to multiple free playlists, this indicates that the target audio does not meet the addition restriction conditions of the first target playlist, that is, it passes the conditional judgment. Subsequently, after passing the corresponding atomic concurrency check, the target audio can be added to the first target playlist.

[0097] If the payment type of the first target playlist is the first type (i.e. paid) and the target audio has been added to other playlists, according to the above-mentioned mutual exclusion restriction, one audio content can only be added to one paid playlist. At this time, it is determined that the target audio meets the adding restriction conditions of the first target playlist, and the target audio is not allowed to be added to the first target playlist.

[0098] If the payment type of the first target playlist is the first type (ie paid) and the target audio has not been added to other playlists, satisfying the above-mentioned mutual exclusion restriction, it is determined that the target audio does not meet the joining restriction condition of the first target playlist.

[0099] In specific implementation, this step can be implemented through the database authority verification module. The processing logic of the database authority verification module is as follows: when a user requests that an audio be added to a playlist, the module first determines whether the audio in the request is paid. If it is paid, it returns an error message "The audio is already associated with a paid playlist and cannot be added to another playlist." Otherwise, if the audio is free, it continues to check whether the playlist in the request is paid. If the playlist is free, it enters the atomic audio addition to free playlist concurrent verification module. Otherwise, if the playlist is paid, it determines whether the audio is associated with other playlists. If so, it returns an error message "The audio is already associated with other playlists and cannot be added to paid playlists." Otherwise, it enters the atomic audio addition to paid playlist concurrent verification module.

[0100] Among them, the atomic concurrency verification module is an independent module from the database authority verification module. The atomic concurrency verification module is used to process playlist requests that pass the database authority verification module. In the final execution stage, it adopts Redis-based enhanced verification, that is, atomically executing association constraint verification through Lua scripts to solve the phantom read / dirty read problems caused by the database read committed isolation level in high-concurrency scenarios, and completely avoid the risk of data inconsistency.

[0101] S13. Based on the preset atomization script in Redis, using the distributed lock configuration method that matches the payment type of the first target playlist, a target distributed lock that matches the payment type of the first target playlist is configured for the target audio.

[0102] Among them, this step is implemented through the above-mentioned atomic concurrency verification module, and the preset atomic script in Redis is a Lua script.

[0103] The atomic concurrent verification module consists of three parts: the concurrent verification module for adding audio to free playlists, the concurrent verification module for adding audio to paid playlists, and the lock release module. Each module is an independent Lua script, and its operations are atomic, which can ensure data consistency.

[0104] Step S13 in this embodiment can be implemented by adding audio to a free playlist concurrent verification module or audio to a paid playlist concurrent verification module. When the payment type of the first target playlist is free, step S13 can be implemented by adding audio to a free playlist concurrent verification module. When the payment type of the first target playlist is paid, step S13 can be implemented by adding audio to a paid playlist concurrent verification module.

[0105] In one implementation, step S13 may include:

[0106] 1) When the payment type of the first target playlist is the first type, a conditional distributed lock configuration method is used to configure a target distributed lock corresponding to the first type for the target audio.

[0107] Among them, the first type is paid. When the payment type of the first target playlist is paid, there is a mutual exclusion restriction for audio to be added to the paid playlist, that is, the same audio can only be added to one paid playlist at most. Therefore, set ex nx is used to obtain a paid distributed lock. The conditional distributed lock configuration method in this embodiment is the set ex nx command.

[0108] set ex nx is a command combination in Redis, mainly used to set key-value pairs with conditions and expiration time. The specific meaning is as follows:

[0109] set: This is the command used by Redis to set key-value pairs.

[0110] nx (notexists): This is an optional parameter that ensures that the value will be set only if the key does not already exist. If the key already exists, the command will not do anything.

[0111] ex (expire): This is also an optional parameter that is used to set the expiration time of the key (in seconds). When the specified time is reached, the key will be automatically deleted.

[0112] In specific implementations, if the payment type of the first target playlist is paid, use set ex nx to obtain a paid distributed lock and configure a target distributed lock corresponding to the payment type for the target audio. This target distributed lock specifically refers to the paid distributed lock. In actual scenarios, if a user has already configured a target distributed lock corresponding to the payment type for the target audio, due to the set ex nx command's limitation of "setting the value only when the key does not exist", this user cannot use set exnx to configure a target distributed lock corresponding to the payment type for the target audio. This ensures that only one user can configure a target distributed lock corresponding to the payment type for the target audio at a time.

[0113] In one embodiment, if a problem occurs in the Redis server due to network jitter or other reasons, and the acquisition of the paid distributed lock fails, a fallback strategy is designed to return an error message "Operation Conflict" to the user.

[0114] 2) When the payment type of the first target playlist is the second type, a target distributed lock corresponding to the second type is configured for the target audio using a distributed lock configuration method without conditions.

[0115] In actual scenarios, there is no mutual exclusion restriction when audio is added to multiple free playlists at the same time. Therefore, set ex is used to obtain a free distributed lock. The unconditional distributed lock configuration method in the embodiment of this application is the set ex command. The set ex command is used to set a value to a key and set the expiration time of the key.

[0116] In specific implementations, if the payment type of the first target playlist is free, use set ex to obtain a free distributed lock and configure a target distributed lock corresponding to free for the target audio. This target distributed lock specifically refers to a free distributed lock. In actual scenarios, multiple users can simultaneously use set ex to obtain a free distributed lock and configure a target distributed lock corresponding to free for the target audio.

[0117] In one embodiment, if a problem occurs in the Redis server due to network jitter or other reasons, and the acquisition of the paid distributed lock fails, a fallback strategy is designed to return an error message "Operation Conflict" to the user.

[0118] S14. Determine whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; if not, execute step S15; if so, execute step S17.

[0119] Before performing any operation on the target audio, configure the corresponding distributed lock for the target audio. For example, when changing the payment type of a playlist from free to paid, you need to add a non-transferable distributed lock to each audio in the playlist. If adding an audio to a paid playlist, you should also add a paid distributed lock to it. If adding an audio to a free playlist, you should also add a free distributed lock to it. Other operations should also be configured with corresponding non-distributed locks.

[0120] In specific implementation, if a free distributed lock is added for the target audio, the distributed lock that conflicts with the playlist processing request can be a paid distributed lock or a free transfer distributed lock.

[0121] If a paid distributed lock is added for the target audio, the distributed lock that conflicts with the playlist processing request can be a free distributed lock.

[0122] If the target audio has at least one distributed lock configured that conflicts with the playlist processing request, the conflicting distributed lock will prevent the audio from being added to the playlist normally, and an "Operation Conflict" error will be returned. If the target audio does not have at least one distributed lock configured that conflicts with the playlist processing request, the concurrency verification module can perform subsequent audio playlist association operations.

[0123] S15: Execute the operation of adding the target audio to the first target playlist.

[0124] Specifically, if the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request, that is, if the target audio is added to the first target playlist at this time, an operation of adding the target audio to the first target playlist is executed from the database. The operation of adding the target audio to the first target playlist is also called an audio playlist association operation.

[0125] S16. Release the target distributed lock.

[0126] In specific implementation, if the target audio has been successfully added to the first target playlist in the database or the addition has failed, that is, regardless of whether the addition is successful or not, the user's playlist processing request has been processed and the audio addition playlist process has ended. The target distributed lock can be released so that other users can continue to operate on the target audio.

[0127] In one implementation, releasing the target distributed lock may include:

[0128] Get the reception time of the playlist processing request, and use the reception time to determine whether the user is a distributed lock holder. If so, release the target distributed lock.

[0129] When releasing a target distributed lock, in high-concurrency scenarios, multiple people may simultaneously lock the target audio. In this case, the lock holder must be verified. After verification, the corresponding free or paid distributed lock is released. For example, user 1 submits a playlist processing request at 11:50:00.000 (the time the playlist processing request is submitted is also the time the playlist processing request is received) and configures a free distributed lock for audio A, with the millisecond timestamp of the current request as the distributed lock value, recorded as timestamp 1. User 2 submits a playlist processing request at 11:50:00.010 and also configures a free distributed lock for audio A, with the millisecond timestamp of the current request as the distributed lock value, recorded as timestamp 2. After adding audio A to the corresponding playlist process, it is necessary to determine whether to release the free distributed lock added by user 1 or user 2.

[0130] When determining the lock holder, the system first verifies the lock holder based on the timestamp of the playlist processing request's reception time. For example, after user 1 completes the operation process, it obtains the value of the target distributed lock, namely the current timestamp in the cache. User 1 compares timestamp 1 held by user 1 with the current timestamp in the cache. If they are equal, the distributed lock was set by user 1's request, and the distributed lock is released. Specifically, the target distributed lock key is deleted to release the lock. If they are not equal, the distributed lock was set by another user's request, and the lock is not released.

[0131] In addition, in this embodiment, the expiration time of the target distributed lock can also be set to avoid certain emergencies that cause the lock to be not released normally. At this time, if the expiration time of the lock is reached, the lock is released.

[0132] The lock release operation process may be implemented by the lock release module described above.

[0133] S17: Outputting operation conflict prompt information.

[0134] After executing step S17, the process returns to executing step S16.

[0135] Specifically, if the target audio has at least one distributed lock configured that conflicts with the playlist processing request, an operation conflict prompt message will be output. The specific implementation process is described above. In addition, if the target audio has at least one distributed lock configured that conflicts with the playlist processing request, it indicates an operation conflict and the user will not be allowed to continue the operation. The target distributed lock configured for this user will be released.

[0136] In this embodiment, after a screening is performed based on the joining restriction conditions of the first target playlist, a target distributed lock that matches the payment type of the first target playlist is configured for the target audio using a preset atomic script based on Redis, and it is determined whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request. If the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, an operation conflict prompt message is output. Only when the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request will the operation of adding the target audio to the first target playlist be executed, ensuring that at the same time, only one user performs a playlist joining operation on the same target audio, avoiding the violation of the business rules for binding audio and playlists caused by multiple users performing playlist joining operations on the same target audio at the same time, reducing the reliability of the association operation, and improving the accuracy of the operation of the association relationship between audio and playlists. In addition, the present application can also release the target distributed lock to ensure that other users can normally perform the association operation between audio and playlists.

[0137] In addition, compared with other types of locks such as pessimistic locks, the distributed lock of this application is based on memory operations, with excellent performance and high efficiency. It can quickly release the data of the configured lock, avoid long-term monopoly, improve processing performance, avoid deadlocks, and reduce costs.

[0138] Based on any of the above embodiments, various locks in the above embodiments, such as free distributed locks, paid distributed locks, and transfer-free distributed locks, need to be stored in advance. In one implementation, a hash algorithm can be used to store the distributed locks corresponding to each operation.

[0139] In specific implementation, this embodiment uses Redis HashTag {audioid%16} to calculate the storage location of the distributed lock key and perform corresponding storage operations to ensure that the distributed lock key in the Lua script is on the same Redis shard node and to minimize data skew.

[0140] Based on any of the above embodiments, refer to Figure 2, determining whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, including:

[0141] S21. Determine whether the target audio has been configured with a distributed lock corresponding to the first type; if so, execute step S22; if not, execute step S23.

[0142] Specifically, if the payment type of the first target playlist is the second type (i.e., free), step S21 is executed to determine whether the target audio has been configured with a distributed lock corresponding to the first type (i.e., paid). In actual scenarios, if the payment type of the first target playlist is the second type (i.e., free), the target audio needs to be added to the free playlist. The above-mentioned audio addition to free playlist concurrent verification module is used to perform the specific implementation of this embodiment.

[0143] When the concurrent verification module for adding audio to a free playlist is running, it first uses set ex to obtain a free distributed lock. If the acquisition fails, an error message "Operation conflict" is returned. Otherwise, it continues to check whether a paid distributed lock exists. If so, an error message "Operation conflict" is returned. In actual high-concurrency scenarios, two users may configure a free distributed lock and a paid distributed lock for the same target audio, respectively. Assuming that the user who configured the paid distributed lock operates first, after adding the target audio to the paid playlist, the paid distributed lock is not released for a short time. At this time, since the operation of adding the target audio to the paid playlist has ended, the operation of the user who configured the free distributed lock can be responded to. At this time, it will be determined whether there is a paid distributed lock corresponding to the payment, that is, the paid distributed lock. Since the paid distributed lock has not been released, it is considered that the target audio has been configured with a paid distributed lock. It is then determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, and an error message "Operation conflict" is returned.

[0144] S22: Determine that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request.

[0145] The specific implementation of this step refers to the corresponding instructions above.

[0146] S23. Determine whether the target audio has been configured with a distributed lock corresponding to the payment type conversion operation; if so, execute step S22; if not, execute step S24.

[0147] S24: Determine that the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request.

[0148] Specifically, when a user requests a change in the payment type of a playlist, a distributed lock corresponding to the payment type conversion operation will be configured for the requested playlist. This distributed lock can be a no-transfer distributed lock. In actual scenarios, if the payment type of a playlist changes from free to paid, the distributed lock corresponding to the payment type conversion operation will be a no-transfer distributed lock. If the payment type of a playlist changes from paid to free, since there is no mutual exclusion restriction for the paid-to-free conversion, the paid-to-free distributed lock can be omitted.

[0149] After determining that no paid distributed lock is configured, continue to determine whether the target audio has been configured with a distributed lock corresponding to the paid type conversion operation (i.e., the above-mentioned free-transfer distributed lock). If the free-transfer distributed lock has been configured, it means that the target audio has been changed from a free playlist to a paid playlist by other users, and the current user's operation is to add the target audio to the free playlist. The two operations conflict, then it is determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, and an error prompt "Operation conflict" is returned.

[0150] If the target audio is not configured with a free-transfer distributed lock, it is considered that the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request. At this time, it is determined that the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request. The free playlist concurrency verification module is added through the audio to perform subsequent audio playlist association operations.

[0151] S25. Determine whether the target audio has been configured with a distributed lock corresponding to the second type; if so, execute step S22; if not, execute step S24.

[0152] Specifically, if the payment type of the first target playlist is the first type (i.e., paid), a determination is made as to whether the target audio has been configured with a distributed lock corresponding to the second type (i.e., free). If so, the target audio is determined to have been configured with at least one distributed lock that conflicts with the playlist processing request. If not, the target audio is determined to not have been configured with at least one distributed lock that conflicts with the playlist processing request.

[0153] Specifically, the specific implementation of this embodiment is achieved through the above-mentioned audio added to the paid playlist concurrent verification module. The implementation principle of the audio added to the paid playlist concurrent verification module is as follows:

[0154] First, use set ex nx to obtain the paid distributed lock. If the acquisition fails, an error message "Operation conflict" is returned. Otherwise, continue to check whether there is a free distributed lock (because the operations of adding audio to the free playlist and adding it to the paid playlist conflict). If so, an error message "Operation conflict" is returned. Otherwise, the audio is added to the paid playlist through the concurrent verification module to perform the audio playlist association operation.

[0155] In order to enable those skilled in the art to more clearly understand the specific implementation of this application, Figure 3 This article provides examples for the specific implementation of the database authority verification module and the atomic concurrent verification module.

[0156] like Figure 3 As shown, when a user requests to add an audio to a playlist, the system first checks whether the requested audio is paid. If so, it returns an error message stating "This audio is already associated with a paid playlist and cannot be added to another playlist." Otherwise, if the audio is free, the system continues to check whether the requested playlist is paid. If so, it enters the atomic audio addition to free playlist concurrent verification module. Otherwise, if the playlist is paid, it determines whether the audio is associated with another playlist. If so, it returns an error message stating "This audio is already associated with another playlist and cannot be added to a paid playlist." Otherwise, it enters the atomic audio addition to paid playlist concurrent verification module.

[0157] Atomic concurrent verification process for adding audio to free playlists:

[0158] First, obtain a free distributed lock. If the acquisition fails, an error message "Operation conflict" is returned; otherwise, continue to check whether there is a paid distributed lock. If so, an error message "Operation conflict" is returned; otherwise, continue to check whether there is a free transfer distributed lock. If so, an error message "Operation conflict" is returned; otherwise, the audio playlist association operation is performed through the concurrent verification module.

[0159] There is no mutual exclusion restriction when audio is added to multiple free playlists at the same time, so set ex is used to obtain a free distributed lock.

[0160] Concurrent verification process for adding audio to paid playlists:

[0161] First, obtain the paid distributed lock. If the acquisition fails, an error message "Operation conflict" is returned; otherwise, continue to check whether there is a free distributed lock. If so, an error message "Operation conflict" is returned; otherwise, the audio playlist association operation is performed through the concurrent verification module.

[0162] There is a mutual exclusion restriction when adding audio to a paid playlist, that is, the same audio can only be added to one paid playlist at most. Therefore, use set ex nx to obtain a paid distributed lock.

[0163] Release the operating logic of the lock module:

[0164] When the audio is added to the playlist, the free / paid distributed lock is released. Specifically, the timestamp is used to verify whether the lock holder is the owner. If so, the distributed lock key is deleted to release the lock. Otherwise, the process ends.

[0165] In this embodiment, through the database authority verification module and the atomic concurrency verification module, when performing high-concurrency operations of adding audio to playlists, through the verification of mutual exclusion restrictions and binding rules and atomic operations, when a large number of users simultaneously initiate operations on the association relationship between audio and playlists, the audio playlist association constraint rules, namely the mutual exclusion restrictions and binding rules, are ensured not to be destroyed, thereby improving system reliability.

[0166] The above embodiment introduces the specific implementation of adding the target audio to the first target playlist. In another implementation of this application, the user is also supported to change the payment type of the playlist. Figure 4 , the data processing method further includes:

[0167] S31. When the playlist processing request is used to change the payment type of the second target playlist, a producer module is used to construct a structured message of the playlist processing request, and the structured message is stored in a preset message queue.

[0168] The playlist processing request can be to change the payment type of the second target playlist from free to paid, or vice versa. Regardless of the change method, the payment type asynchronous cascade update module in this embodiment is implemented. This payment type asynchronous cascade update module uses a decoupled producer-consumer model to update the payment type, ensuring that the throughput of the main service link is not affected by the cascade operation.

[0169] like Figure 5 As shown, the user requests a change in the payment type of the second target playlist. After the main business module writes the change in the playlist processing request (including the identification information of the second target playlist that needs to be changed (such as ID (Identity document, identity identification number) and the payment type after the change) into the database, the producer encapsulates the change event into a lightweight structured message (playlist change message) and delivers it to the preset message queue, which can be a rocketmq (RocketMessage Queue) message queue.

[0170] S32. When the payment type of the second target playlist is changed from the first type to the second type, the consumer module is used to obtain a structured message from the preset message queue to change the payment type of each audio in the second target playlist from the first type to the second type.

[0171] Specifically, the consumer module asynchronously receives playlist change messages from a pre-set message queue and executes the payment type change operation. Specifically, it first obtains all audio tracks in the playlist (up to 800 tracks). If the payment type changes from paid to free, the payment type of all audio tracks in the second target playlist is directly updated to free, as there is no mutual exclusion restriction between free and paid conversions.

[0172] S33. When the payment type of the second target playlist is changed from the second type to the first type, the consumer module is used to obtain a structured message from the preset message queue, and a distributed lock corresponding to the payment type conversion operation is set for each audio in the second target playlist, and the payment type of each audio in the second target playlist is changed from the second type to the first type.

[0173] The consumer module asynchronously receives playlist change messages from the preset message queue. When performing the payment type change operation, if the payment type is changed from the second type (i.e. free) to the first type (i.e. paid), in order to prevent other users from operating the audio in the playlist at the same time, an audio free-to-paid distributed lock (referred to as a free-to-pay distributed lock) can be set for each audio in the playlist, and the payment type of all audio in the playlist can be updated to paid.

[0174] The producer and consumer modules can be located in the same server or in different servers, depending on the actual configuration.

[0175] Among them, you can use set ex to set the audio's transfer-free distributed lock.

[0176] In one implementation, the distributed lock in this embodiment is mainly used in distributed scenarios. Distributed scenarios can use a distributed configuration center, such as Apollo. Apollo can centrally manage the configuration of different application environments and different clusters. After the configuration is modified, it can be pushed to the application end in real time. It also has standardized permissions, process governance and other features, and is suitable for microservice configuration management scenarios.

[0177] In this embodiment, in this distributed scenario, audio can be added to the playlist or the playlist type can be changed. In addition, the error prompt text can be modified without releasing the service, the lock expiration time can be modified and made effective, etc.

[0178] It should be noted that for the scenario of deleting a playlist, or deleting one or more audios in a playlist, you can directly delete them without setting the corresponding distributed lock.

[0179] In this embodiment, the payment type asynchronous cascade update module adopts the producer-consumer model to decouple the update process, ensuring that the throughput of the main business link is not affected by the cascade operation.

[0180] Based on the above embodiment of the data processing method, another embodiment of the present application provides a data processing device, referring to Figure 6 , which may include:

[0181] Request acquisition module 11, used to obtain the user's playlist processing request;

[0182] a determination module 12 for determining, when the playlist processing request is for adding the target audio to the first target playlist, whether the target audio satisfies a restriction condition for adding the target audio to the first target playlist based on the payment type of the target audio and the payment type of the first target playlist;

[0183] Configuration module 13 is configured to configure a target distributed lock for the target audio file that matches the payment type of the first target playlist based on a preset atomization script in the remote dictionary service Redis and using a distributed lock configuration method that matches the payment type of the first target playlist if the inclusion restriction condition of the first target playlist is not met;

[0184] The judging module 14 is configured to judge whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; wherein, before operating the target audio, the distributed lock corresponding to the operation is configured for the target audio;

[0185] An operation execution module 15 is configured to execute an operation of adding the target audio to the first target playlist if the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request;

[0186] Release module 16, used to release the target distributed lock;

[0187] Output module 17, configured to output operation conflict prompt information if the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request;

[0188] The release module 16 is further configured to release the target distributed lock after the output module 17 outputs the operation conflict prompt information.

[0189] In one implementation, the determining module 12 includes:

[0190] A query submodule, configured to query the payment type of the first target playlist in the playlist configuration information, and query the payment type of the target audio in the audio configuration information;

[0191] A first determining submodule, configured to determine, when the payment type of the target audio is the first type, that the target audio satisfies a restriction condition for joining the first target playlist;

[0192] The second determination submodule is used to determine that the target audio does not meet the joining restriction conditions of the first target playlist if the payment type of the target audio is the second type, or to determine that the target audio meets the joining restriction conditions of the first target playlist if the payment type of the first target playlist is the first type and the target audio has been added to other playlists, or to determine that the target audio does not meet the joining restriction conditions of the first target playlist if the payment type of the first target playlist is the first type and the target audio has not been added to other playlists.

[0193] In one implementation, the configuration module 13 includes:

[0194] A first configuration submodule is configured to configure a target distributed lock corresponding to the first type for the target audio using a conditional distributed lock configuration method when the payment type of the first target playlist is the first type;

[0195] The second configuration submodule is used to configure a target distributed lock corresponding to the second type for the target audio using a distributed lock configuration method without conditions when the payment type of the first target playlist is the second type.

[0196] In one implementation, the judgment module 14 includes:

[0197] A first judgment submodule is configured to, when the payment type of the first target playlist is the second type, determine whether the target audio has been configured with a distributed lock corresponding to the first type; if so, determine that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; if not, determine whether the target audio has been configured with a distributed lock corresponding to a payment type conversion operation; if so, determine that the target audio has been configured with a distributed lock corresponding to a payment type conversion operation;

[0198] The second judgment submodule is used to determine whether the target audio has been configured with a distributed lock corresponding to the second type when the payment type of the first target playlist is the first type. If a distributed lock corresponding to the second type has been configured, it is determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request.

[0199] In one implementation, the release module 16 includes:

[0200] The acquisition submodule is used to obtain the reception time of the playlist processing request;

[0201] The third judgment submodule is used to use the reception time to determine whether the user is a distributed lock holder, and if so, release the target distributed lock.

[0202] In one implementation, the method further includes:

[0203] a message processing module configured to construct a structured message of the playlist processing request using the producer module when the playlist processing request is for changing the payment type of the second target playlist, and store the structured message in a preset message queue;

[0204] A first changing module is configured to, when the payment type of the second target playlist is changed from the first type to the second type, obtain a structured message from a preset message queue using the consumer module, and change the payment type of each audio in the second target playlist from the first type to the second type;

[0205] The second change module is used to use the consumer module to obtain structured messages from the preset message queue when the payment type of the second target playlist is changed from the second type to the first type, set a distributed lock corresponding to the payment type conversion operation for each audio in the second target playlist, and change the payment type of each audio in the second target playlist from the second type to the first type.

[0206] In one implementation, the method further includes:

[0207] The lock storage module is used to store the distributed locks corresponding to each operation using a hash algorithm.

[0208] In this embodiment, after a screening is performed based on the joining restriction conditions of the first target playlist, a target distributed lock that matches the payment type of the first target playlist is configured for the target audio using a preset atomic script based on Redis, and it is determined whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request. If the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, an operation conflict prompt message is output. Only when the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request will the operation of adding the target audio to the first target playlist be executed, ensuring that at the same time, only one user performs a playlist joining operation on the same target audio, avoiding the violation of the business rules for binding audio and playlists caused by multiple users performing playlist joining operations on the same target audio at the same time, reducing the reliability of the association operation, and improving the accuracy of the operation of the association relationship between audio and playlists. In addition, the present application can release the target distributed lock to ensure that other users can normally perform the association operation between audio and playlists.

[0209] It should be noted that, for the working process of each module and sub-module in this embodiment, please refer to the corresponding description in the above embodiment, which will not be repeated here.

[0210] An embodiment of the present application further provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0211] Memory is used to store computer programs;

[0212] The processor is used to execute the computer program so that the electronic device can implement the above-mentioned data processing method.

[0213] refer to Figure 7 , which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present application. The electronic device in the embodiments of the present application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 7 The electronic device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0214] like Figure 7 As shown, the electronic device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 602 or programs loaded from a storage device 608 into a random access memory (RAM) 603. When the electronic device is powered on, the RAM 603 also stores various programs and data required for the operation of the electronic device. The processing device 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0215] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a memory card, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Figure 7 The electronic device is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead.

[0216] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any data processing method provided in the embodiment of the present application.

[0217] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any data processing method provided in the embodiment of the present application.

[0218] It should also be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines.

[0219] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course can also be implemented by special hardware including application-specific integrated circuits, special CPUs, special memories, special components, etc. In general, all functions performed by computer programs can be easily implemented with corresponding hardware, and the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits or special circuits, etc. However, for the present application, software program implementation is a better implementation method in most cases. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer's floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk or optical disk, etc., and includes a number of instructions to enable a computer device (which can be a personal computer, training equipment, or network equipment, etc.) to execute the methods described in each embodiment of the present application.

[0220] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0221] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, a computer, a training device or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website, a computer, a training device or a data center. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

Claims

1. A data processing method, characterized in that: include: Get the user's playlist processing request; In a case where the playlist processing request is used to add the target audio to the first target playlist, determining whether the target audio meets the addition restriction condition of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist; If the inclusion restriction condition of the first target playlist is not met, a target distributed lock matching the payment type of the first target playlist is configured for the target audio using a distributed lock configuration method matching the payment type of the first target playlist based on a preset atomization script in the remote dictionary service Redis; Determining whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; wherein, before performing an operation on the target audio, configuring a distributed lock corresponding to the operation for the target audio; If the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request, performing an operation of adding the target audio to the first target playlist; Release the target distributed lock; If the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request, an operation conflict prompt message is output and the target distributed lock is released.

2. The data processing method according to claim 1, wherein: Determining whether the target audio meets a restriction condition for joining the first target playlist based on the payment type of the target audio and the payment type of the first target playlist includes: Querying the payment type of the first target playlist in the playlist configuration information, and querying the payment type of the target audio in the audio configuration information; When the payment type of the target audio is the first type, determining that the target audio meets the joining restriction condition of the first target playlist; In the case where the payment type of the target audio is the second type, if the payment type of the first target playlist is the second type, it is determined that the target audio does not meet the joining restriction conditions of the first target playlist, or, if the payment type of the first target playlist is the first type and the target audio has been added to other playlists, it is determined that the target audio meets the joining restriction conditions of the first target playlist, or, if the payment type of the first target playlist is the first type and the target audio has not been added to other playlists, it is determined that the target audio does not meet the joining restriction conditions of the first target playlist.

3. The data processing method according to claim 1, wherein: Utilizing a distributed lock configuration method that matches the payment type of the first target playlist, configuring a target distributed lock that matches the payment type of the first target playlist for the target audio, including: In a case where the payment type of the first target playlist is the first type, a target distributed lock corresponding to the first type is configured for the target audio using a conditional distributed lock configuration method; In the case that the payment type of the first target playlist is the second type, a target distributed lock corresponding to the second type is configured for the target audio using a distributed lock configuration method without conditions.

4. The data processing method according to claim 1, wherein: Determining whether the target audio is configured with at least one distributed lock that conflicts with the playlist processing request includes: In a case where the payment type of the first target playlist is the second type, determining whether the target audio has been configured with a distributed lock corresponding to the first type; If a distributed lock corresponding to the first type has been configured, it is determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; If the distributed lock corresponding to the first type is not configured, determining whether the target audio has been configured with a distributed lock corresponding to the payment type conversion operation; If a distributed lock corresponding to the payment type conversion operation has been configured, it is determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; In a case where the payment type of the first target playlist is the first type, determining whether the target audio has been configured with a distributed lock corresponding to the second type; If a distributed lock corresponding to the second type has been configured, it is determined that the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request.

5. The data processing method according to claim 1, wherein: Releasing the target distributed lock includes: Obtaining the reception time of the playlist processing request; Using the reception time to determine whether the user is a distributed lock holder; If so, the target distributed lock is released.

6. The data processing method according to claim 1, wherein: Also includes: In the case where the playlist processing request is used to change the payment type of the second target playlist, a producer module is used to construct a structured message of the playlist processing request, and the structured message is stored in a preset message queue; In a case where the payment type of the second target playlist is changed from the first type to the second type, the consumer module is used to obtain the structured message from the preset message queue, and the payment type of each audio in the second target playlist is changed from the first type to the second type; In the case where the payment type of the second target playlist is changed from the second type to the first type, the consumer module is used to obtain the structured message from the preset message queue, and a distributed lock corresponding to the payment type conversion operation is set for each audio in the second target playlist, and the payment type of each audio in the second target playlist is changed from the second type to the first type.

7. The data processing method according to claim 1, wherein: Also includes: Use hash algorithm to store the distributed locks corresponding to each operation.

8. A data processing device, characterized in that: include: Request acquisition module, used to obtain the user's playlist processing request; a determination module configured to, when the playlist processing request is for adding the target audio to the first target playlist, determine whether the target audio satisfies a restriction condition for adding the target audio to the first target playlist based on a payment type of the target audio and a payment type of the first target playlist; a configuration module configured to, if the inclusion restriction condition of the first target playlist is not met, configure a target distributed lock for the target audio that matches the payment type of the first target playlist using a distributed lock configuration method that matches the payment type of the first target playlist based on a preset atomization script in the remote dictionary service Redis; a determination module, configured to determine whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; wherein, before performing an operation on the target audio, a distributed lock corresponding to the operation is configured for the target audio; an operation execution module, configured to, if the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request, execute an operation of adding the target audio to the first target playlist; A release module, configured to release the target distributed lock; an output module, configured to output an operation conflict prompt message if the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; The release module is further configured to release the target distributed lock after the output module outputs the operation conflict prompt information.

9. An electronic device, characterized in that: comprising at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program so that the electronic device can implement the data processing method according to any one of claims 1 to 7.

10. A computer storage medium, characterized in that The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the data processing method according to any one of claims 1 to 7.

Images