A data processing method and related apparatus

Abstract

This application provides a data processing method and related apparatus, relating to the field of data processing technology. After initial screening based on the addition restrictions of a first target playlist, an atomic script is used to configure a target distributed lock for the target audio that matches the payment type of the first target playlist. It is then determined whether the target audio has already been configured with at least one distributed lock that conflicts with the playlist processing request. Only if 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. This ensures that at any given time, only one user performs a playlist addition operation on the same target audio, avoiding the problem of multiple users performing playlist addition operations on the same target audio at the same time, which would violate the business rules of audio-playlist binding and reduce the reliability of the association operation, thus improving the accuracy of the audio-playlist association operation.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data processing method and related apparatus. Background Technology

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

[0003] In real-world scenarios, audio content management platforms face a situation where a large number of users simultaneously initiate operations on the association between audio and playlists (including but not limited to adding, removing, converting free playlists to paid ones, and converting paid playlists to free ones). Ensuring the accuracy of these operations is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of the above problems, this application provides a data processing method and related apparatus to improve the operational accuracy of the correlation between audio and playlists. The specific solution is as follows:

[0005] The first aspect of this application provides a data processing method, including:

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

[0007] When the playlist processing request is used to add the target audio to the first target playlist, it is determined whether the target audio meets the addition restriction conditions 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 conditions for adding the first target playlist are not met, based on the preset atomic script in the remote dictionary service Redis, a distributed lock matching the payment type of the first target playlist is configured for the target audio using a distributed lock configuration method that matches the payment type of the first target playlist.

[0009] Determine whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; wherein, before operating on the target audio, a distributed lock corresponding to the operation is configured 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, the operation of adding the target audio to the first target playlist is performed;

[0011] Release the target distributed lock;

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

[0013] In one possible implementation, determining whether the target audio meets the joining restrictions 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] 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;

[0015] If the payment type of the target audio is the first type, it is determined that the target audio meets the inclusion restriction conditions of the first target playlist;

[0016] If the payment type of the target audio is type two, and the payment type of the first target playlist is type two, then it is determined that the target audio does not meet the addition restriction conditions of the first target playlist. Alternatively, if the payment type of the first target playlist is type one and the target audio has been added to other playlists, then it is determined that the target audio meets the addition restriction conditions of the first target playlist. Alternatively, if the payment type of the first target playlist is type one and the target audio has not been added to other playlists, then it is determined that the target audio does not meet the addition restriction conditions of the first target playlist.

[0017] In one possible implementation, a distributed lock configuration method matching the payment type of the first target playlist is used to configure a target distributed lock for the target audio that matches the payment type of the first target playlist, including:

[0018] When 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] 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.

[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] If 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;

[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 no distributed lock corresponding to the first type is configured, then determine 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] If the payment type of the first target playlist is the first type, determine whether the target audio has been configured with a distributed lock corresponding to the second type;

[0026] If a distributed lock of 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 one possible implementation, releasing the target distributed lock includes:

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

[0029] The receiving time is used to determine whether the user is a distributed lock holder;

[0030] If so, then release the target distributed lock.

[0031] One possible implementation also includes:

[0032] When the playlist processing request is used to change the payment type of the second target playlist, the producer module constructs a structured message for the playlist processing request and stores the structured message in a preset message queue.

[0033] When the payment type of the second target playlist is changed from the first type to the second type, the consumer module retrieves the structured message from the preset message queue and changes the payment type of each audio in the second target playlist from the first type to the second type.

[0034] When the payment type of the second target playlist is changed from the second type to the first type, the consumer module retrieves the structured message from the preset message queue, sets a distributed lock corresponding to the payment type conversion operation for each audio in the second target playlist, and changes the payment type of each audio in the second target playlist from the second type to the first type.

[0035] One possible implementation also includes:

[0036] A hash algorithm is used to store the distributed locks corresponding to each operation.

[0037] A second aspect of this application provides a data processing apparatus, comprising:

[0038] The request retrieval module is used to retrieve users' playlist processing requests;

[0039] The determining module is configured to, when the playlist processing request is used to add the target audio to the first target playlist, determine whether the target audio meets the addition restriction conditions of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist.

[0040] The configuration module is used to configure a target distributed lock for the target audio that matches the payment type of the first target playlist if the addition restriction conditions of the first target playlist are not met. This is based on a preset atomic script in the remote dictionary service Redis and uses a distributed lock configuration method that matches the payment type of the first target playlist.

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

[0042] An operation execution module is used to add 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.

[0043] The release module is used to release the target distributed lock;

[0044] The output module is used 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 also used to release the target distributed lock after the output module outputs the operation conflict prompt information.

[0046] A third aspect of this 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-described data processing method.

[0049] A fourth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to perform the data processing method described above.

[0050] By employing the above technical solution, this application provides a data processing method and related apparatus. In this application, after initial filtering based on the addition restrictions of a first target playlist, a target distributed lock matching the payment type of the first target playlist is configured for the target audio using a preset atomic script based on Redis. It is then 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 is output. Only when the target audio has not been 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. This ensures that at any given time, only one user performs a playlist addition operation on the same target audio, avoiding the problem of multiple users performing playlist addition operations on the same target audio at the same time, which would violate the business rules of audio-playlist binding and reduce the reliability of association operations, thus improving the accuracy of audio-playlist association operations. Furthermore, this application can also release the target distributed lock to ensure that other users can normally perform audio-playlist association operations. Attached Figure Description

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

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

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

[0054] Figure 3A flowchart illustrating audio playlist association constraints is provided for embodiments of this application.

[0055] Figure 4 A flowchart illustrating a playlist type change is provided in this application embodiment;

[0056] Figure 5 A flowchart illustrating an asynchronous cascading update process for a paid type is provided in this application embodiment;

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

[0058] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0059] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0060] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0061] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0062] To enable those skilled in the art to better understand this application, the technical terms used in this application are explained below.

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

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

[0065] Playlist-associated audio: Approved PUGC audio is added to a specified playlist in a certain order and included in the playlist distribution sequence.

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

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

[0068] Redis HashTag: Refers to a data routing rule in Redis sharded clusters (Cluster mode). It forces keys with the same hash tag (HashTag) to be assigned to the same shard node by enclosing a specific substring in the key name in curly braces {}.

[0069] In audio content management systems, to improve user experience and content distribution efficiency, platforms typically categorize, aggregate, and recommend audio content through playlists (or albums, song lists, etc.). A key operation in playlist management is adding audio content to a specified playlist. However, this operation is not a simple data association; 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 queries to complete a series of precondition verifications and add the audio content to a specified playlist. Taking mutual exclusion and binding rules as business rules, and using "adding audio to a playlist" as an example, the detailed process is as follows:

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

[0072] 2. Playlist Attribute Validation: Query the target playlist information from the broadcastlist table. 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 verification: Query the broadlistAudio playlist relationship table to see if the target audio already exists in other playlists. If the audio is already associated with other playlists, the current 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, when a large number of users initiate operations on the association between audio and playlists almost simultaneously, the lack of a concurrency control mechanism can easily lead to the violation of business rules and make it impossible to guarantee the accuracy of the operation on the association between audio and playlists.

[0075] To address this, this application provides a data processing method and related apparatus. In this application, after initial filtering based on the addition restrictions of a first target playlist, a target distributed lock matching the payment type of the first target playlist is configured for the target audio using a preset atomic script in Redis. It then determines whether the target audio has already 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 warning is output. Only when the target audio has not been 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. This ensures that at any given time, only one user performs a playlist addition operation on the same target audio, avoiding the problem of multiple users performing playlist addition operations on the same target audio at the same time, which could violate the business rules of audio-playlist binding and reduce the reliability of the association operation, thus improving the accuracy of the audio-playlist association operation. Furthermore, this application can also release the target distributed lock to ensure that other users can normally perform audio-playlist association operations.

[0076] Based on the above, one embodiment of this application provides a data processing method, the executing entity of which may be a server, processor, or other device. (See also...) 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 the user interface. Playlist processing requests can include: ordinary users or operations personnel adding audio to a paid playlist, or operations personnel changing a playlist from free to paid. For example, an operations person can add audio 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 restrictions of the first target playlist; if not, proceed to step S13.

[0080] Specifically, when a playlist processing request is used to add a target audio to a first target playlist, the system determines whether the target audio meets the addition restrictions of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist.

[0081] In practice, if a user adds the target audio to the first target playlist through the user interface, the user is only adding the target audio to the first target playlist through the user interface. The target audio also needs to be added to the first target playlist from the database. In this case, the user's playlist processing request is to add the target audio to the first target playlist from the database.

[0082] After responding to the playlist processing request, the first step is to determine whether the target audio meets the inclusion criteria of the first target playlist.

[0083] Among them, the added restrictions can be configured according to the actual scenario. The design principle of adding restrictions is: mutual exclusion restrictions and binding rules exist for audio added to playlists.

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

[0085] The binding rule means that the payment type of 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] Because of the aforementioned mutual exclusion restrictions and binding rules when adding audio to a playlist, in high-concurrency scenarios, such as when a large number of users simultaneously initiate operations on the association between audio and playlists, the logic mechanism that relies on reading the database for verification is very likely to cause the aforementioned mutual exclusion restrictions and binding rules to be violated, resulting in a significant reduction in system reliability.

[0087] Therefore, in this embodiment of the application, in order to avoid the above mutual exclusion restrictions and binding rules being violated, it is first determined whether the target audio meets the joining restriction conditions of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist.

[0088] In one implementation, determining whether the target audio meets the joining restrictions 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 practice, the playlist configuration information can be the aforementioned playlist table `broadlist`, and the audio configuration information can be the aforementioned audio table `audioinfo`. Both playlist and audio configuration information can be stored in a relational database for association constraint validation. In addition to storing playlist and audio configuration information, the relational database can also store the aforementioned playlist-audio relationship table `broadlistAudio`.

[0091] In practical implementation, adding audio to a playlist involves many associated constraints. This embodiment directly queries a relational database to verify these constraints during the initial screening stage of audio playlist addition requests. This ensures the verification result is based on the system's unique and trusted data source, providing a baseline for subsequent high-concurrency verification. This embodiment uses a scenario of concurrent audio playlist additions as an example. The playlist table `broadlist` is configured with the playlist's payment type, which can be paid or free. The audio table `audioinfo` is configured with the audio's payment type, which can also be paid or free. The playlist-audio relationship table `broadlistAudio` stores the correspondence between playlists and audio files; for example, playlist 1 includes audio files A, B, and C.

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

[0093] 2) If the payment type of the target audio is the first type, determine that the target audio meets the inclusion restriction conditions of the first target playlist.

[0094] The first type refers to paid content. When a user requests to add a target audio to the first target playlist, if the target audio's payment type is paid, it means that the target audio has already been added to another paid playlist, which is why the target audio's payment type is paid. In this case, it means that the target audio meets the addition restrictions of the first target playlist and cannot be added to the first target playlist. Therefore, the user is returned an error message: "This audio is already associated with a paid playlist and cannot be added to other playlists."

[0095] 3) If the payment type of the target audio is type 2, and the payment type of the first target playlist is type 2, then the target audio does not meet the addition restriction conditions of the first target playlist. Alternatively, if the payment type of the first target playlist is type 1 and the target audio has been added to other playlists, then the target audio meets the addition restriction conditions of the first target playlist. Alternatively, if the payment type of the first target playlist is type 1 and the target audio has not been added to other playlists, then the target audio does not meet the addition restriction conditions of the first target playlist.

[0096] The second type is free. If the target audio's payment type is free, and the first target playlist's payment type is the second type (i.e., free), then the free target audio needs to be added to the free playlist. According to the mutual exclusion constraint mentioned above, since a free audio can be added to multiple free playlists, this means the target audio does not meet the addition constraint condition of the first target playlist, i.e., it has passed the condition judgment. After passing the corresponding atomic concurrency check, the operation of adding the target audio to the first target playlist can be performed.

[0097] If the first target playlist has a payment type of Type 1 (i.e., paid) and the target audio has already been added to other playlists, according to the mutual exclusion restriction mentioned above, an audio content can only be added to one paid playlist. In this case, it is determined that the target audio meets the addition 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 type 1 (i.e., paid) and the target audio has not been added to other playlists, satisfying the above mutual exclusion constraint, then it is determined that the target audio does not meet the addition constraint conditions of the first target playlist.

[0099] In practice, this step can be implemented using a database authoritative verification module. The processing logic of the database authoritative verification module is as follows: When a user requests to add audio to a playlist, it first determines whether the requested audio is paid. If it is paid, it returns an error message: "This audio is already associated with a paid playlist and cannot be added to other playlists." Otherwise, if the audio is free, it continues to check whether the requested playlist is paid. If the playlist is free, it enters the atomic audio adding free playlist concurrent verification module; otherwise, if the playlist is paid, it determines whether the audio is associated with other playlists. If associated, it returns an error message: "This audio is already associated with other playlists and cannot be added to paid playlists." Otherwise, it enters the atomic audio adding paid playlist concurrent verification module.

[0100] Among them, the atomic concurrency verification module is a separate module from the database authoritative verification module. The atomic concurrency verification module is used to perform enhanced verification based on Redis in the final execution stage for playlist processing requests that have passed the database authoritative verification module. That is, it uses Lua scripts to atomically execute association constraint verification to solve the phantom read / dirty read problem caused by the database read committed isolation level in high concurrency scenarios, and completely avoids the risk of data inconsistency.

[0101] S13. Based on the preset atomic script in Redis, use the distributed lock configuration method that matches the payment type of the first target playlist to configure a target distributed lock for the target audio that matches the payment type of the first target playlist.

[0102] This step is implemented through the atomic concurrency verification module mentioned above, which is based on the preset atomic script in Redis, namely the Lua script.

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

[0104] In this embodiment, step S13 can be implemented by adding audio to a free playlist concurrent verification module or adding 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) If the payment type of the first target playlist is the first type, use the conditional distributed lock configuration method to configure the target audio with the target distributed lock corresponding to the first type.

[0107] Among them, the first type is paid. When the paid type of the first target playlist is paid, the audio is added to the paid playlist with mutual exclusion restriction, that is, the same audio can be added to a paid playlist at most. Therefore, the paid distributed lock is obtained by using set ex nx. 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, primarily used to set conditional expiration times for key-value pairs. Its specific meaning is as follows:

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

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

[0111] `ex` (expire): This is also an optional parameter used to set the key's expiration time (in seconds). The key will be automatically deleted after the specified time has elapsed.

[0112] In practical implementation, when the payment type of the first target playlist is paid, `set ex nx` is used to acquire a paid distributed lock, and a target distributed lock corresponding to the paid content is configured for the target audio. Specifically, this target distributed lock refers to the paid distributed lock. In real-world scenarios, if a user has already configured a paid target distributed lock for the target audio, due to the limitation of the `set ex nx` command that "a value is only set if the key does not exist," this user cannot use `set ex nx` to configure a paid target distributed lock for the target audio, ensuring that at any given time, only one user can configure a paid target distributed lock for the target audio.

[0113] In one embodiment, if the Redis server malfunctions due to network jitter or other reasons, resulting in failure to acquire the paid distributed lock, a fallback strategy is designed to return an error message "operation conflict" to the user.

[0114] 2) If the payment type of the first target playlist is the second type, use the distributed lock configuration method without conditions to configure a target distributed lock for the target audio that corresponds to the second type.

[0115] In real-world scenarios, there is no mutual exclusion restriction when multiple free playlists are added to audio simultaneously. Therefore, the `set ex` command is used to acquire a free distributed lock. In this embodiment, the distributed lock configuration method without conditions is the `set ex` command. The `set ex` command is used to set a value to a key and set the expiration time of that key.

[0116] In practical implementation, when the payment type of the first target playlist is free, `set ex` is used to acquire a free distributed lock, and a target distributed lock corresponding to the free type is configured for the target audio. This target distributed lock specifically refers to the free distributed lock. In real-world scenarios, multiple users can be allowed to simultaneously use `set ex` to acquire a free distributed lock and configure a target distributed lock corresponding to the free type for the target audio.

[0117] In one embodiment, if the Redis server malfunctions due to network jitter or other reasons, resulting in failure to acquire the paid distributed lock, 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, proceed to step S15; if yes, proceed to step S17.

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

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

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

[0122] If the target audio file already has at least one distributed lock configured that conflicts with the playlist processing request, then that conflicting distributed lock will not allow the audio to be added to the playlist normally, and an "operation conflict" error message will be returned. If the target audio file does not have at least one distributed lock configured that conflicts with the playlist processing request, then subsequent audio playlist association operations can be performed through the concurrency verification module.

[0123] S15, Perform 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, then the operation of adding the target audio to the first target playlist is performed from the database. This operation of adding the target audio to the first target playlist is also known as the audio playlist association operation.

[0125] S16. Release the target distributed lock.

[0126] In practice, if the target audio has been successfully added to the first target playlist in the database or if the addition has failed, regardless of whether the addition was successful or not, the user's playlist processing request has been completed and the audio addition 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] Obtain 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 users may simultaneously lock the target audio file. In such cases, it's necessary to verify the lock holder. Only after successful verification can the corresponding free or paid distributed lock be released. For example, User 1 outputs a playlist processing request at 11:50:00.000 (the time of outputting the playlist processing request is also the time of receiving the request) and configures a free distributed lock for audio A, using the current request's millisecond timestamp as the lock's value, denoted as timestamp 1. User 2 outputs a playlist processing request at 11:50:00.010, also configuring a free distributed lock for audio A, using the current request's millisecond timestamp as the lock's value, denoted as timestamp 2. After adding audio A to the corresponding playlist process, it's 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 whether the user is the lock holder based on the timestamp of the playlist processing request's reception time. For example, after user 1's operation process ends, the value of the target distributed lock is obtained, which is the current timestamp in the cache. User 1 compares their own timestamp (1) with the current timestamp in the cache. If they are equal, it means the distributed lock was set by user 1, and the distributed lock is released. Specifically, to release the distributed lock, the target distributed lock key is deleted. If they are not equal, it means the distributed lock was set by another user, and no lock release operation is performed.

[0131] In addition, in this embodiment, an expiration time for the target distributed lock can be set to avoid the lock not being released normally due to certain unforeseen circumstances. If the lock expires, the lock will be released.

[0132] The process of releasing the lock can be implemented through the aforementioned lock release module.

[0133] S17. Output operation conflict prompt message.

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

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

[0136] In this embodiment, after initial filtering based on the inclusion restrictions of the first target playlist, a target distributed lock matching the payment type of the first target playlist is configured for the target audio using a preset atomic script in Redis. It is then determined whether the target audio already has at least one distributed lock conflicting with the playlist processing request. If the target audio does have at least one conflicting distributed lock, an operation conflict warning is output. Only when the target audio does not have at least one conflicting distributed lock will the operation of adding the target audio to the first target playlist be executed. This ensures that only one user performs a playlist addition operation on the same target audio at any given time, avoiding the problem of multiple users performing playlist addition operations on the same target audio simultaneously, which could violate the business rules of audio-playlist binding and reduce the reliability of the association operation, thus improving the accuracy of the audio-playlist association operation. Furthermore, this application can also release the target distributed lock to ensure that other users can perform audio-playlist association operations normally.

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

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

[0139] In this specific implementation, the Redis HashTag {audioid%16} is used 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 2Determine whether the target audio file is already 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 of the first type; if yes, proceed to step S22; if no, proceed to 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 a real-world scenario, if the payment type of the first target playlist is the second type (i.e., free), and it is necessary to add the target audio to the free playlist, then the above-mentioned audio addition to free playlist concurrency verification module is used to execute the specific implementation in this embodiment.

[0143] When the audio addition to the free playlist concurrency verification module is running, it first uses `set ex` to acquire the free distributed lock. If this fails, it returns the error message "Operation conflict". Otherwise, it continues to check if a paid distributed lock exists. If it does, it returns the error message "Operation conflict". In actual high-concurrency scenarios, there may be two users who have configured a free distributed lock and a paid distributed lock for the same target audio. Assuming the user with the paid distributed lock operates first, and after adding the target audio to the paid playlist, the paid distributed lock is not released within a short period of time, the operation of adding the target audio to the paid playlist has already ended, and the operation of the user with the free distributed lock can be responded to. At this time, it checks if a paid distributed lock exists. Since the paid distributed lock has not been released, it is assumed that the target audio has a paid distributed lock. Therefore, it is determined that the target audio has at least one distributed lock that conflicts with the playlist processing request, and the error message "Operation conflict" is returned.

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

[0145] The specific implementation of this step is described in 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 yes, proceed to step S22; if no, proceed to step S24.

[0147] S24. It is determined 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 is configured for the requested playlist. This distributed lock can be a no-transfer-to-payment distributed lock. In practice, if the playlist's payment type changes from free to paid, the distributed lock corresponding to the payment type conversion operation is a no-transfer-to-payment distributed lock. If the playlist's payment type changes from paid to free, since there is no mutual exclusion restriction for the paid-to-free conversion, a no-transfer-to-payment distributed lock is not required.

[0149] After determining that no paid distributed lock is configured, the system continues to check whether the target audio has a distributed lock corresponding to the paid type conversion operation (i.e., the aforementioned non-transferable distributed lock). If the non-transferable distributed lock is configured, it means that the target audio has been changed from a free playlist to a paid playlist by another user, while this user's operation is to add the target audio to a free playlist. The two operations conflict, so it is determined that the target audio has at least one distributed lock configured that conflicts with the playlist processing request, and the error message "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. In this case, it is determined that the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request, and the audio is added to the free playlist concurrency verification module to perform subsequent audio playlist association operations.

[0151] S25. Determine whether the target audio has been configured with a distributed lock of the second type; if yes, proceed to step S22; if no, proceed to step S24.

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

[0153] Specifically, the implementation in this embodiment is achieved through the aforementioned audio-to-paid playlist concurrency verification module. The implementation principle of the audio-to-paid playlist concurrency verification module is as follows:

[0154] First, use `set ex nx` to acquire the paid distributed lock. If acquisition fails, return the error message "Operation conflict"; otherwise, continue to check if a free distributed lock exists (because adding audio to a free playlist and adding it to a paid playlist conflict). If it exists, return the error message "Operation conflict"; otherwise, use the audio to add paid playlist concurrency verification module to perform the audio playlist association operation.

[0155] To enable those skilled in the art to more clearly understand the specific implementation of this application, the following is combined with... Figure 3 Examples illustrating the specific implementation of the database authoritative verification module and the atomic concurrent verification module.

[0156] like Figure 3 As shown, when a user requests to add audio to a playlist, the system first checks if the requested audio is a paid playlist. If it is, an error message is returned: "This audio is already associated with a paid playlist and cannot be added to other playlists." Otherwise, if the audio is free, the system continues to check if the requested playlist is paid. If the playlist is free, the system enters the atomic audio-to-free playlist concurrency verification module; otherwise, if the playlist is paid, the system checks if the audio is associated with other playlists. If so, an error message is returned: "This audio is already associated with another playlist and cannot be added to a paid playlist." Otherwise, the system enters the atomic audio-to-paid playlist concurrency verification module.

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

[0158] First, try to acquire a free distributed lock. If the acquisition fails, return the error message "Operation conflict". Otherwise, continue to check if a paid distributed lock exists. If it exists, return the error message "Operation conflict". Otherwise, continue to check if a free-to-pay distributed lock exists. If it exists, return the error message "Operation conflict". Otherwise, perform the audio playlist association operation through the concurrency verification module.

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

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

[0161] First, acquire the paid distributed lock. If acquisition fails, return the error message "Operation conflict"; otherwise, continue to check if a free distributed lock exists. If it exists, return the error message "Operation conflict"; otherwise, perform the audio playlist association operation through the concurrency verification module.

[0162] Adding audio to a paid playlist is mutually exclusive, meaning that the same audio can only be added to one paid playlist at most. Therefore, `set ex nx` is used to acquire a paid distributed lock.

[0163] The operating logic of the lock release module:

[0164] Once the audio is added to the playlist process is complete, the free / paid distributed lock is released. Specifically, first, the system verifies whether the user is the lock holder based on the timestamp. If so, the distributed lock key is deleted to release the lock; otherwise, the process ends.

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

[0166] The above embodiments describe the specific implementation of adding target audio to a first target playlist. Another implementation of this application also supports users changing the payment type of the playlist. Specifically, refer to... Figure 4 Data processing methods also include:

[0167] S31. When a playlist processing request is used to change the payment type of the second target playlist, the producer module is used to construct a structured message for the playlist processing request and store the structured message 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 from paid to free. Regardless of the method of change, it is implemented by the asynchronous cascading update module for payment type in this embodiment. The asynchronous cascading update module for payment type updates the payment type in a producer-consumer model decoupling manner, ensuring that the throughput of the main business link is not affected by the cascading operation.

[0169] like Figure 5 As shown, when a user requests a change in the pay type of the second target playlist, the main business module writes the change request (including the identification information of the second target playlist to be changed (such as ID (Identity document) and the changed pay type)) into the database. Then, the producer encapsulates the change event into a lightweight structured message (playlist change message) and delivers it to a preset message queue. The preset message queue 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 retrieves a structured message from the preset message queue and changes 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 preset message queue and performs a payment type change operation. Specifically, it first retrieves all audio files (maximum 800) under the playlist. If the payment type changes from paid to free, since there is no mutual exclusion restriction between free and paid conversions, it directly updates the payment type of all audio files in the second target playlist to free.

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

[0173] The consumer module asynchronously receives playlist change messages from the preset message queue. When performing a 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 on the audio in the playlist at the same time, a free-to-paid audio distributed lock (referred to as free-to-paid 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 on the same server or on different servers, depending on the actual configuration.

[0175] Among them, you can use `set ex` to set a non-transferable distributed lock for audio.

[0176] In one implementation, the distributed lock in this embodiment is mainly used in distributed scenarios. Distributed scenarios can use distributed configuration centers, such as Apollo. Apollo can centrally manage the configurations of different environments and clusters of applications. After the configuration is modified, it can be pushed to the application 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, audio can be added to a playlist or the playlist type can be changed in this distributed scenario. In addition, error message text can be modified and lock expiration time can be modified and made effective even when the service is not released.

[0178] It should be noted that for scenarios involving deleting a playlist, or deleting one or more audio files from a playlist, you can simply delete the playlist without setting up a distributed lock.

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

[0180] Based on the embodiments of the above data processing methods, another embodiment of this application provides a data processing apparatus, referring to... Figure 6 It can include:

[0181] Request retrieval module 11 is used to retrieve users' playlist processing requests;

[0182] The determination module 12 is used to determine whether the target audio meets the addition restriction conditions of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist when the playlist processing request is used to add the target audio to the first target playlist.

[0183] Configuration module 13 is used to configure a target distributed lock for the target audio that matches the payment type of the first target playlist if the addition restriction conditions of the first target playlist are not met. This is based on the preset atomic script in the remote dictionary service Redis and uses a distributed lock configuration method that matches the payment type of the first target playlist.

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

[0185] The operation execution module 15 is used to add 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 is used to release the target distributed lock;

[0187] Output module 17 is used 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.

[0188] The release module 16 is also used 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] The query submodule is used to query the payment type of the first target playlist in the playlist configuration information, and to query the payment type of the target audio in the audio configuration information.

[0191] The first determination submodule is used to determine whether the target audio meets the addition restrictions of the first target playlist when the payment type of the target audio is the first type.

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

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

[0194] The first configuration submodule is used 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 when the payment type of the first target playlist is the second type, using a distributed lock configuration method without conditions.

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

[0197] The first judgment submodule is used to determine whether the target audio has been configured with a distributed lock corresponding to the first type when the payment type of the first target playlist is the second 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 no distributed lock corresponding to the first type has been configured, it is determined 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.

[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 it has been configured with a distributed lock corresponding to the second type, 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 `get` submodule is used to obtain the reception time of the playlist processing request;

[0201] The third judgment submodule is used to determine whether the user is the holder of the distributed lock based on the receiving time. If so, the target distributed lock is released.

[0202] One implementation also includes:

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

[0204] The first modification module is used to change the payment type of each audio in the second target playlist from the first type to the second type when the payment type of the second target playlist is changed from the first type to the second type.

[0205] The second modification module is used to, when the payment type of the second target playlist is changed from the second type to the first type, retrieve structured messages from a preset message queue using the consumer module, 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] One implementation also 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 initial filtering based on the inclusion restrictions of the first target playlist, a target distributed lock matching the payment type of the first target playlist is configured for the target audio using a preset atomic script in Redis. It is then determined whether the target audio already has at least one distributed lock conflicting with the playlist processing request. If the target audio does have at least one conflicting distributed lock, an operation conflict warning is output. Only when the target audio does not have at least one conflicting distributed lock will the operation of adding the target audio to the first target playlist be executed. This ensures that only one user performs a playlist addition operation on the same target audio at any given time, avoiding the problem of multiple users performing playlist addition operations on the same target audio simultaneously, which could violate the business rules of audio-playlist binding and reduce the reliability of the association operation, thus improving the accuracy of the audio-playlist association operation. Furthermore, this application can release the target distributed lock to ensure that other users can perform audio-playlist association operations normally.

[0209] It should be noted that the working process of each module and sub-module in this embodiment is described in the corresponding descriptions in the above embodiments, and will not be repeated here.

[0210] This application also 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 computer programs so that electronic devices can perform the data processing methods described above.

[0213] refer to Figure 7 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this 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 impose any limitation on the functionality and scope of use of the embodiments of this application.

[0214] like Figure 7 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program 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 unit 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 can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, memory cards, hard drives, etc.; and communication devices 609. Communication device 609 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0216] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the data processing methods provided in this application.

[0217] This application also provides a computer-readable storage medium that 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 of the data processing methods provided in this application.

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

[0219] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0220] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as 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, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A data processing method, characterized in that, include: Obtain the user's playlist processing request; When the playlist processing request is used to add the target audio to the first target playlist, it is determined whether the target audio meets the addition restriction conditions 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 conditions for adding the first target playlist are not met, based on the preset atomic script in the remote dictionary service Redis, a distributed lock matching the payment type of the first target playlist is configured for the target audio using a distributed lock configuration method that matches the payment type of the first target playlist. Determine whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; wherein, before operating on the target audio, a distributed lock corresponding to the operation is configured for the target audio; If the target audio is not configured with at least one distributed lock that conflicts with the playlist processing request, the operation of adding the target audio to the first target playlist is performed; Release the target distributed lock; If the target audio is configured with at least one distributed lock that conflicts with the playlist processing request, output an operation conflict prompt message and release the target distributed lock.

2. The data processing method according to claim 1, characterized in that, Based on the payment type of the target audio and the payment type of the first target playlist, determine whether the target audio meets the joining restrictions of the first target playlist, including: 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; If the payment type of the target audio is the first type, it is determined that the target audio meets the inclusion restriction conditions of the first target playlist; If the payment type of the target audio is type two, and the payment type of the first target playlist is type two, then it is determined that the target audio does not meet the addition restriction conditions of the first target playlist. Alternatively, if the payment type of the first target playlist is type one and the target audio has been added to other playlists, then it is determined that the target audio meets the addition restriction conditions of the first target playlist. Alternatively, if the payment type of the first target playlist is type one and the target audio has not been added to other playlists, then it is determined that the target audio does not meet the addition restriction conditions of the first target playlist.

3. The data processing method according to claim 1, characterized in that, Utilizing a distributed lock configuration method that matches the payment type of the first target playlist, a target distributed lock is configured for the target audio that matches the payment type of the first target playlist, including: When 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. 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.

4. The data processing method according to claim 1, characterized in that, Determining whether the target audio is already configured with at least one distributed lock that conflicts with the playlist processing request includes: If 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 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 no distributed lock corresponding to the first type is configured, then determine 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. If the payment type of the first target playlist is the first type, determine whether the target audio has been configured with a distributed lock corresponding to the second type; If a distributed lock of 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, characterized in that, Releasing the target distributed lock includes: Obtain the reception time of the playlist processing request; The receiving time is used to determine whether the user is a distributed lock holder; If so, then release the target distributed lock.

6. The data processing method according to claim 1, characterized in that, Also includes: When the playlist processing request is used to change the payment type of the second target playlist, the producer module constructs a structured message for the playlist processing request and stores the structured message in a preset message queue. When the payment type of the second target playlist is changed from the first type to the second type, the consumer module retrieves the structured message from the preset message queue and changes the payment type of each audio in the second target playlist from the first type to the second type. When the payment type of the second target playlist is changed from the second type to the first type, the consumer module retrieves the structured message from the preset message queue, sets a distributed lock corresponding to the payment type conversion operation for each audio in the second target playlist, and changes the payment type of each audio in the second target playlist from the second type to the first type.

7. The data processing method according to claim 1, characterized in that, Also includes: A hash algorithm is used to store the distributed locks corresponding to each operation.

8. A data processing apparatus, characterized in that, include: The request retrieval module is used to retrieve users' playlist processing requests; The determining module is configured to, when the playlist processing request is used to add the target audio to the first target playlist, determine whether the target audio meets the addition restriction conditions of the first target playlist based on the payment type of the target audio and the payment type of the first target playlist. The configuration module is used to configure a target distributed lock for the target audio that matches the payment type of the first target playlist if the addition restriction conditions of the first target playlist are not met. This is based on a preset atomic script in the remote dictionary service Redis and uses a distributed lock configuration method that matches the payment type of the first target playlist. The judgment module is used to determine whether the target audio has been configured with at least one distributed lock that conflicts with the playlist processing request; wherein, before operating on the target audio, a distributed lock corresponding to the operation is configured for the target audio; An operation execution module is used to add 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. The release module is used to release the target distributed lock; The output module is used 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 also used to release the target distributed lock after the output module outputs the operation conflict prompt information.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the data processing method as described in any one of claims 1 to 7.

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

Images