WO2023193653A1

WO2023193653A1 - Content operation method and apparatus, and server and storage medium

Info

Publication number: WO2023193653A1
Application number: PCT/CN2023/085155
Authority: WO
Inventors: 汪强; 郑海源
Original assignee: 百果园技术(新加坡)有限公司; 汪强
Priority date: 2022-04-08
Filing date: 2023-03-30
Publication date: 2023-10-12
Also published as: CN114820218A

Abstract

The embodiments of the present application belong to the field of the Internet. Disclosed are a content operation method and apparatus, and a server and a storage medium. The method comprises: acquiring n candidate tasks from a target queue, wherein a candidate task is used for instructing a robot to execute an operation on candidate release content at a candidate time point, and n is a positive integer (201); determining a target task from among the n candidate tasks, wherein a target time point that is indicated by the target task is not later than the current time point (202); determining a target robot from a target robot candidate set corresponding to target release content, which is indicated by the target task, wherein the target robot candidate set includes a robot for executing an operation on the target release content (203); and executing the operation on the target release content by means of the target robot (204). In the embodiments of the present application, an operation on release content can be automatically completed at a preset time point, which facilitates the improvement of the efficiency and accuracy of content operations.

Description

Content operation method, device, server and storage medium

This application claims priority to the Chinese patent application with application number 202210368042.5 and the invention name "Content Operation Method, Device, Server and Storage Medium" submitted on April 8, 2022, the entire content of which is incorporated into this application by reference. .

Technical field

Embodiments of the present application relate to the field of the Internet, and in particular to a content operation method, device, server and storage medium.

Background technique

With the rapid popularity of social software, more and more people are beginning to use social software to record and share their lives.

Since the interestingness and shooting quality of published content vary, and high-quality and interesting content is more popular with the public, the more common or unpopular content cannot be viewed and interacted with, which dampens the enthusiasm of users to publish content.

Contents of the invention

Embodiments of the present application provide a content operation method, device, server and storage medium. The technical solutions are as follows:

On the one hand, embodiments of the present application provide a content operation method, which method includes:

Obtain n candidate tasks from the target queue, the candidate tasks are used to instruct the robot to perform operations on the candidate release content at the candidate time point, n is a positive integer;

Determine the target task among the n candidate tasks, and the target time point indicated by the target task is no later than the current time point;

Determine the target robot from the target robot candidate set corresponding to the target published content indicated by the target task, and the target robot candidate set includes robots used to perform operations on the target published content;

The target posted content is acted upon by the target bot.

On the other hand, embodiments of the present application provide a content operation device, which includes:

The acquisition module is configured to acquire n candidate tasks from the target queue. The candidate tasks are used to instruct the robot to perform operations on the candidate release content at the candidate time point, and n is a positive integer;

The first determination module is configured to determine a target task among the n candidate tasks, and the target time point indicated by the target task is no later than the current time point;

The second determination module is configured to determine the target robot from the target robot candidate set corresponding to the target published content indicated by the target task, and the target robot candidate set includes robots for performing operations on the target published content;

An execution operation module is configured to perform an operation on the target published content through the target robot.

On the other hand, embodiments of the present application provide a server, which includes a processor and a memory. A memory; at least one program is stored in the memory, and the at least one program is loaded and executed by the processor to implement the content operation method as described in the above aspect.

On the other hand, embodiments of the present application provide a computer-readable storage medium that stores at least one instruction, and the at least one instruction is executed by a processor to implement content operations as described above. method.

On the other hand, embodiments of the present application provide a computer program product. The computer program product includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the content operation method provided by the above aspect.

Description of the drawings

Figure 1 is a schematic diagram of the system architecture provided by an exemplary embodiment of the present application;

Figure 2 is a flow chart of a content operation method provided by an exemplary embodiment of the present application;

Figure 3 shows a schematic diagram of a content operation method provided by an exemplary embodiment of the present application;

Figure 4 shows a flow chart of a content operation method provided by another exemplary embodiment of the present application;

Figure 5 shows a candidate task arrangement using temporal gradients provided by another exemplary embodiment of the present application;

Figure 6 shows a schematic diagram of a content processing method using temporal gradient provided by another exemplary embodiment of the present application;

Figure 7 shows a flow chart of a method for updating a robot candidate set provided by an exemplary embodiment of the present application;

Figure 8 is a schematic diagram of a method for updating a robot candidate set provided by an exemplary embodiment of the present application;

Figure 9 shows a complete flow chart of a content operation provided by an exemplary embodiment of the present application;

Figure 10 shows a structural block diagram of a content operating device provided by an exemplary embodiment of the present application.

Detailed ways

With the rapid popularity of social software, more and more people are beginning to use social software to record and share their lives. A large amount of published content is produced every day, but the quality of this content varies greatly. The public prefers high-quality and interesting content. Content, resulting in those relatively ordinary contents not being viewed and interacted with, which greatly discourages users from publishing content.

In view of this, in the embodiment of the present application, after the server obtains the candidate tasks from the queue, it determines the target task from the candidate tasks, and determines the target robot from the target robot candidate set corresponding to the target task instruction target release content, and then uses the target robot Perform operations on the target published content; using the solution provided by the embodiments of this application, the operation on the published content can be automatically completed at a preset time point, which helps to improve the efficiency of content operations. Figure 1 shows a schematic diagram of the system architecture provided by an exemplary embodiment of the present application.

The system architecture may include: a terminal device 110 and a server 120, wherein the terminal device 110 is installed with social software that can publish content.

The number of terminal devices 110 is usually multiple, and each server 120 can interact with multiple terminal devices 110 . The terminal device 110 is used to publish content and perform operations on the published content. The operations may include editing, deleting, liking, forwarding, etc.

The server 120 is a backend server for social software, and is mainly used to publish content uploaded by the terminal device 110, make content recommendations, and so on. For example, post a video to a video sharing platform.

In the embodiment of the present application, the server 120 is also used to associate and store the published content and the time point at which the operation is performed. After the terminal device 110 publishes content, the server 120 stores the published content and its corresponding time point in the queue, and generates a corresponding robot candidate set for the published content. The server 120 obtains the candidate tasks from the queue, determines the target task from the candidate tasks, and determines the target robot from the target robot candidate set corresponding to the target release content indicated by the target task, and then uses the target robot to perform operations on the target release content.

Please refer to Figure 2, which shows a flow chart of a content operation method provided by an exemplary embodiment of the present application. The method may include the following steps:

Step 201: Obtain n candidate tasks from the target queue. The candidate tasks are used to instruct the robot to perform operations on the candidate release content at the candidate time points, and n is a positive integer.

In a possible implementation, the content form of the published content may be videos, articles, pictures, music, dynamics, etc. The embodiments of this application do not limit the specific content form.

The server operates the published content through robots, which refer to some virtual users with real user information.

In order to be able to perform operations on published content in an orderly manner, in one possible implementation, the server stores the published content and its corresponding operation time point in the queue. A piece of published content and its corresponding time point is a candidate task. When an operation needs to be performed, the server obtains n candidate tasks from the target queue, where n is a positive integer.

Among them, the candidate task is used to instruct the robot to perform operations on the candidate release content at the candidate time point. The robot refers to some virtual users with real user information.

Step 202: Determine the target task among the n candidate tasks, and the target time point indicated by the target task is no later than the current time point.

The server pre-stipulates the time points for each task execution operation. For example, the specified time points are the 1st minute, 2nd minute, 3rd minute, 5th minute, 10th minute, etc. after the content is published. The server only executes the execution time when the operation is reached. For tasks at a time point, not all of the n candidate tasks obtained by the server from the target queue need to be executed. In a possible implementation, the n candidate tasks need to be screened to filter out the time point. Candidate tasks that are earlier than or equal to the current time point are identified as target tasks that require action.

Step 203: Determine the target robot from the target robot candidate set corresponding to the target published content indicated by the target task. The target robot candidate set includes robots used to perform operations on the target published content.

The server generates a total set of robot candidates in advance. Corresponding to the published content, the robots that perform operations on the published content are obtained from the total set to generate a robot candidate set. In order to avoid large-scale overlap between different robot candidate sets, the server uses random acquisition to generate robots. candidate set.

Among them, different robot candidate sets can be completely different or partially overlap. The robots in the robot candidate set can perform different operations. For example, some robots perform viewing operations, and some robots perform like operations.

Optionally, the server can generate a robot candidate set in advance or generate a robot candidate set on-the-fly. This method is to randomly generate a robot candidate set when the time point of task execution is reached.

After the server determines the target task from the candidate tasks, in response to the target release content indicated by the target task, it determines the target robot from the target robot candidate set corresponding to the target release content. The target robot candidate set includes robots used to perform operations on the target release content. .

Optionally, the server determines the target robot from the target robot candidate set corresponding to the target published content in a random or sequential manner, which is not limited in this embodiment.

Optionally, the robots in the robot candidate set can be robots that perform a certain operation. For example, a like robot can only perform a like operation, and a comment robot can only perform a comment operation. The robot candidate set is generated from the total robot candidate set according to the release Robots with different content allocations form a robot candidate set. For example, if a content release requires 100 robots to watch and 20 robots to comment, then 100 viewing robots and 20 commenting robots are randomly obtained from the total robot candidate set to form a robot candidate set. If the current The operation required to publish the content at the operation time point is a viewing operation, and the server determines a viewing robot from the robot candidate set.

Optionally, the robots in the robot candidate set can also be robots that perform any operation. For example, any robot can perform either a like operation or a comment operation. When generating a robot candidate set from the total robot candidate set, the robot candidate set is allocated according to the published content. Robots can form a robot candidate set. For example, if a published content requires 100 robots to watch and 20 robots to comment, then 120 robots are randomly obtained from the total robot candidate set to form a robot candidate set. If the target publishing content at the current operation time point needs to be If the operation is viewing, the server can determine any robot from the robot candidate set.

Step 204: Use the target robot to perform operations on the target published content.

In a possible implementation, after the target robot is determined from the corresponding target robot candidate set based on the target published content, the target robot performs operations on the target published content.

Optionally, the operation may be a viewing operation, a like operation, a sharing operation, a collection operation, a comment operation, a forwarding operation, etc., which are not limited in this embodiment.

Schematically, as shown in Figure 3, there are m candidate tasks in the target queue, the server obtains n candidate tasks from it, and determines the target task based on the time points of these n candidate tasks, where m and n are both positive integers and m Greater than or equal to n, the server determines the target robot from the target robot candidate set corresponding to the target published content indicated by the target task, and the target robot operates on the published content. If the server determines the candidate task corresponding to content 1 from n candidate tasks as the target task, Then the server determines a robot from the robot candidate set corresponding to content 1 as the target robot to perform operations on content 1. If the robot candidate set corresponding to content 1 includes robots 1, 2, 3... When content 1 needs to perform an operation at the execution time point, the server will determine the robot from robots 1, 2, 3... as the target robot for the content. 1Perform the operation.

To sum up, in the embodiment of this application, after the server obtains n candidate tasks from the target queue, it determines the target task among the n candidate tasks, and then determines the target from the target robot candidate set corresponding to the target release content indicated by the target task. The robot performs operations on the target published content through the target robot; using the solution provided by the embodiment of the present application, the operation on the published content can be automatically completed at a preset time point, which helps to improve the efficiency and accuracy of content operations.

In order to make it easier and more efficient to publish content, the time point at which operations are performed on the published content, and the contents of the published content, The corresponding robot candidate set is stored and obtained. In one possible implementation, the published content and the corresponding robot candidate set are stored in the redis cache in the form of key-value, where key is the content identifier of the published content, and value is the robot identification of each robot in the robot candidate set; the task is stored in the zset queue in the form of score-member, where score is the time point when the robot performs operations on the published content, and member is the content identification of the published content.

In a possible implementation, the user can send a content publishing instruction or a content deletion instruction to the server by adding published content or deleting published content on the terminal. The two situations are schematically explained below.

1. Add publishing content

In a possible implementation, when a user publishes content through a terminal, the server determines the published content as the first published content, and the server generates a first published content for the first published content in response to a content publishing instruction corresponding to the first published content. Robot candidate set. The method of generating the first robot candidate set can refer to step 203. This embodiment will not be repeated here. The first robot candidate set includes robots used to perform operations on the first published content. The server is based on the first published content. and time gradient information corresponding to the first published content, to generate a first task corresponding to the first published content, and the server adds the first task to the queue based on the load balancing policy.

Optionally, the time gradient information refers to the information obtained by the server arranging the N operation time points of the first content and the execution operations at the corresponding time points from small to large time points.

Optionally, the first task consists of the first release content and its corresponding time point.

Optional, load balancing strategies are mainly divided into two categories: static and dynamic. Static load balancing allocates tasks with a fixed probability without considering the status information of the server, such as round-robin algorithm balancing, weighted round-robin algorithm balancing, etc. Dynamic load balancing uses the real-time load status information of the server to determine task allocation, such as minimum connection method balancing, Weighted least connection method balancing, etc., the embodiments of this application do not limit the specific load balancing strategy.

2. Delete published content

In another possible implementation, when the user deletes published content through the terminal, the server determines the published content as the second published content, and in response to the content deletion instruction corresponding to the second published content, the server deletes the second published content The second task corresponding to the second published content is deleted from the queue according to the corresponding relationship with the second robot candidate set.

Optionally, the second task consists of the second release content and its corresponding time point.

Optionally, the server deletes the corresponding relationship between the second published content and the second robot candidate set, which can be by deleting the second robot candidate set or clearing the robots in the second robot candidate set. The second robot candidate set does not exist or the second robot candidate set does not exist. When the candidate set is empty, the server deletes the second task corresponding to the second published content from the queue.

Due to the large amount of content published on social software, in the embodiment of this application, the candidate tasks in the target queue are arranged in the order of time points, so that the robot can operate the published content more accurately and timely. Please refer to Figure 3, which shows a flow chart of a content operation method provided by another exemplary embodiment of the present application. The method may include the following steps:

Step 401: Obtain the first n candidate tasks in the target queue.

In a possible implementation, the server stores the candidate tasks in the target queue in the zset queue. In the embodiment of this application, score is the time point when the robot performs operations on the published content, member is the content identifier of the published content, and the server After the candidate tasks are stored in zest, zest sorts the members according to the score. That is, zest sorts the content identifiers of the published content according to the time point when the robot performs the operation on the published content. After sorting, the candidate tasks in the target queue are arranged in order of time points. Arranged in order, the server obtains the first n candidate tasks in the target queue, n is a positive integer.

Schematically, as shown in Figure 5, the zset queue previously stored four candidate tasks. If a candidate task is written into the queue at this time, the zset queue will reorder the queue according to the time point of the candidate task. The sorted candidates Tasks are stored in the zset queue in order of time points.

Step 402: Based on the order of n candidate tasks, compare the candidate time points indicated by the candidate tasks with the current time point in order to obtain the target task.

In a possible implementation, after the server obtains the first n candidate tasks in the target queue, it compares the candidate time points of the candidate tasks and the current time point in the order of the candidate tasks, and obtains that the candidate time points are earlier than or equal to Candidate tasks at the current time point and use them as target tasks.

Optional, since these n candidate tasks are arranged in the order of time points, if the i-th candidate task is later than the current time point, then the candidate tasks after the i-th task are all later than the current time point, and subsequent tasks will no longer be considered. Candidate tasks are compared.

Step 403: If there is no target task, determine the sleep duration based on the candidate time point indicated by the first candidate task among the n candidate tasks and the current time point.

In a possible implementation, the server obtains the first n candidate tasks in the target queue and compares the candidate time points of the candidate tasks with the current time point according to the order of the candidate tasks, and then determines that all n candidate tasks are Later than the current time point, that is, the target task does not exist.

Optionally, since the n candidate tasks are arranged in the order of time points, the first candidate task is the earliest candidate task among the n candidate tasks. If the first candidate task is later than the current time point, then These n candidate tasks are all later than the current time point and no longer need to be compared.

In order to improve processing efficiency and reduce CPU consumption, in this embodiment, the server determines the sleep duration based on the candidate time point indicated by the first candidate task among the n candidate tasks and the current time point.

For example, as shown in Figure 6, there are m candidate tasks in the target queue. The time points of these m candidate tasks are arranged in order. The server obtains the first n candidate tasks in the target queue, where n and m are both positive integers. And m is greater than or equal to n, and then based on the order of n candidate tasks, sequentially compare the candidate time points indicated by the candidate tasks with the current time point. If the current time point is 11:59:00, then among the n candidate tasks The time points of the first candidate task are all later than the current time point, and there is no target task. The sleep duration t, t is calculated based on the current time point 11:59:00 and the time point 12:00:00 indicated by the candidate task. is 00:01:00.

Step 404: Stop obtaining candidate tasks from the target queue during the sleep period.

During the sleep period, the server controls the process of operating the published content through the robot to sleep and stops obtaining candidate tasks from the target queue.

Step 405: When the sleep duration is reached, continue to obtain candidate tasks from the target queue.

After the dormancy period is reached, the server controls the process of operating the published content through the robot to resume. Running status. Since the server is based on the candidate time point indicated by the first candidate task and the sleep duration determined at the current time point, after the process of operating the published content through the robot resumes the running status, it continues to obtain candidate tasks from the target queue. At this time, at least one candidate task among the candidate tasks is earlier than or equal to the current time point and can be executed.

Step 406: If a target task exists, determine the target robot from the target robot candidate set corresponding to the target release content indicated by the target task.

In a possible implementation, the server obtains the first n candidate tasks in the target queue and compares the candidate time points of the candidate tasks and the current time point according to the order of the candidate tasks, and obtains that the i candidate tasks are later than the current time point. Time point, that is, the i-th candidate task and the candidate tasks before it are all earlier than or equal to the current time point, and the candidate tasks after the i-th item are all later than the current time point. Take the first i candidate task and use it as the target task, from The target robot is determined from the target robot candidate set corresponding to the target release content indicated by the target task.

For example, as shown in Figure 6, if the current time point is 12:00:11, then the time points of the candidate tasks corresponding to content 4 and the candidate tasks before it are earlier than or equal to the current time point, and the time points corresponding to content 4 The time points of the candidate tasks after the candidate task are all later than the current time point. The candidate task corresponding to content 4 and the candidate tasks before it are regarded as the target tasks, and then the target is determined from the target robot candidate set corresponding to the target release content indicated by the target task. robot.

Step 407: Use the target robot to perform operations on the target published content.

For the implementation of this step, reference may be made to step 204, which will not be described again in this embodiment.

In this embodiment, the target tasks are sorted in the order of time points to be operated, and the smallest time point is compared with the current time point. If the target task exists, the published content is operated, and if there is no target task, the published content is operated. In this case, the sleep time is calculated and the operation is performed after the sleep period is over. While the operation is completed accurately, useless read and write operations are reduced, the sleep strategy is implemented, the processing efficiency is greatly improved, and the CPU consumption is reduced.

In order to avoid the situation where repeated robots perform operations on the target published content, in this embodiment, the candidate set is updated by removing robots that have already operated from the target robot candidate set. Please refer to Figure 7, which shows a The exemplary embodiment provides a flow chart of a robot candidate set updating process. The method may include the following steps.

Step 701: Remove the target robot from the target robot candidate set.

In a possible implementation, the published content and the corresponding robot candidate set are stored in the redis cache in the form of key-value, where the key is the content identifier of the published content, and the value is the robot identifier of each robot in the robot candidate set. , after the target robot performs operations on the target published content, the server updates the target robot candidate set by removing the target robot from the target robot candidate set, that is, updating the robot identification value corresponding to the content identification key, and the server will update the robot candidate set The corresponding value is written back to the redis cache.

Schematically, as shown in Figure 8, after a robot performs an operation on the content, the robot candidate set is updated by removing the robot from the robot candidate set corresponding to the content, and the updated robot candidate set is written back to the redis cache.

Step 702: When the target robot candidate set is empty, remove the target task from the target queue.

In a possible implementation, if after the target robot candidate set is updated, there are no unoperated robots in the target robot candidate set, that is, when the target robot candidate set is empty, it indicates that all time points of the target release content indicated by the target task have been After the operation is completed, this target task no longer requires robot operation, and this target task is removed from the target queue.

Schematically, as shown in Figure 8, after robot 4 performs an operation on content 4, the server updates the robot candidate set by removing robot 4 from the robot candidate set corresponding to content 2. After the robot candidate set corresponding to content 2 is updated, Since there are no unoperated robots in the robot candidate set, that is, the robot candidate set is empty, it indicates that the operations have been completed at all time points of content 2. The target task corresponding to content 2 no longer requires robot operation. The target task corresponding to content 2 is removed from the robot candidate set. removed from the target queue.

Step 703: If the target robot candidate set is not empty, update the target time point indicated by the target task based on the time gradient information corresponding to the target release content.

In another possible implementation, if after the target robot candidate set is updated, there are unoperated robots in the target robot candidate set, that is, when the target robot candidate set is not empty, it indicates that the target release content indicated by the target task still exists at a time point. For unfinished operations, based on the time gradient information corresponding to the target release content, calculate the next time point that requires the operation closest to the current time point, and update it to the target task as the target time point.

Schematically, as shown in Figure 8, after robot 1 performs an operation on content 1, the robot candidate set is updated by removing robot 1 from the robot candidate set corresponding to content 1. After the robot candidate set corresponding to content 1 is updated, Since there are unoperated robots in the robot candidate set, that is, the robot candidate set is not empty, it indicates that content 1 still has unfinished operations at time points. Based on the time gradient information corresponding to content 1, the next operation that needs to be performed closest to the current time point is calculated. The time point is 12:00:07. Update the time point 12:00:07 to the target task.

Step 704: Write the updated target task back to the target queue.

After the target time point in the target task is updated, the server writes the updated target task back to the target queue. That is, after the score is updated, the server writes the member and its corresponding score back to the zset queue.

In this embodiment, the candidate set is updated by removing robots that have already been operated from the target robot candidate set, so as to avoid repeated processing operations on the same target content by the same robot, and to provide users with a better experience as much as possible. At the same time, When the target robot candidate set is empty, removing the target task from the target queue can prevent the server from reading and writing invalid target tasks, causing errors in server operation.

In order to ensure that different queues can trigger robot operations at the same time, in one possible implementation, the queue processing thread is used to seize distributed locks to operate the content published in the queue.

In order to ensure that each queue processing thread only processes one queue and that one queue can only be processed by one queue processing thread at the same time, in a possible implementation, by using distributed locks, each queue corresponds to a distributed lock. After the queue processing thread seizes the distributed lock of the target queue, it becomes the target queue processing thread. The target queue processing process obtains n candidate tasks from the target queue.

Optionally, in order to ensure disaster tolerance, that is, the target queue processing process is abnormal and cannot work normally, in the embodiment of this application, more queue processing processes than the number of queues are allocated, but only those that seize the distributed lock corresponding to the queue are allocated. The queue processing process can handle the queue normally.

Optionally, distributed locks have the following features:

1. In a distributed lock environment, a queue can only be executed by one thread at the same time;

2. Highly available lock acquisition and lock release;

3. High-performance lock acquisition and lock release;

4. It has reentrant characteristics;

5. It has a lock failure mechanism to prevent deadlock, that is, setting the lock failure time, and after reaching the lock failure time, the lock is released;

6. It has non-blocking lock characteristics, that is, if the lock is not acquired, it will directly return failure to acquire the lock.

Among them, distributed locks have three implementation methods, namely distributed locks based on database, distributed locks based on cache (Redis, etc.), and distributed locks based on Zookeeper (a distributed, open source distributed application coordination service, which is a Distributed service framework) implements distributed locks, which is not limited in this embodiment.

In a possible implementation, when the target queue processing thread preempts the target distributed lock corresponding to the target queue, the target queue processing thread performs a lock renewal operation on the pair every second time period.

Optionally, since the distributed lock is set with a lock expiration time, the distributed lock will be released after the time is reached. Therefore, the server presets a second time period. The second time period is less than or equal to the lock expiration time, and the queue processing process preempts it. After the distributed lock corresponding to the queue is obtained, the lock renewal operation needs to be performed every second interval to prevent the distributed lock from being released.

For example, if the lock expiration time is 30s, the server pre-sets the second time duration. The second time duration is less than or equal to the lock expiration time. The second time duration can be 25s. In order to prevent the distributed lock from being released due to reaching the lock expiration time, the target queue processing thread The lock renewal operation is performed every second period of time, that is, 25 seconds, so that the target queue processing thread continues to occupy the target distributed lock corresponding to the target queue and continues to process the target queue.

In another possible implementation, when an exception occurs in the target queue processing thread, the target distributed lock is released.

When an exception occurs in the target queue processing process and cannot work normally, the target queue processing thread cannot continue to occupy the target distributed lock corresponding to the target queue. The target distributed lock is released and other queue processing threads continue to preempt it.

In a possible implementation, when the target queue processing thread preempts the target distributed lock corresponding to the target queue, n candidate tasks are obtained from the target queue through the target queue processing thread. However, since more queue processing processes than the number of queues are allocated in the embodiment of this application, only the queue processing processes that have preempted the distributed lock corresponding to the queue can process the queue normally, and there are no queue processing processes that have preempted the distributed lock corresponding to the queue. The queue cannot be processed. Therefore, in another possible implementation, when the target queue processing thread does not seize the distributed lock, the target queue processing thread is controlled to enter the sleep state, and the duration of the sleep state is the first duration, When the first duration is reached, the target queue processing thread is awakened, and the awakened target queue processing thread continues to seize the distributed lock.

Optionally, the queue processing thread that has not preempted the distributed lock will enter the dormant state and remain dormant for a certain period of time. This period can be set to 15s, 20s, 30s, etc., and this period is the dormancy duration.

In this embodiment, more queue processing processes than the number of queues are allocated, and distributed locks are used to ensure that each queue can be processed. At the same time, after an exception occurs in the queue processing process, the distributed lock will be released. The remaining queue processing processes seize the distributed lock and continue to process the queue. At the same time, by setting the sleep duration, the queue processing threads that have not preempted the distributed lock are prevented from performing useless preemption operations. While making the server run efficiently and reliably, it ensures that the operation process is Disaster tolerance reduces CPU consumption.

Combined with the above embodiments, Figure 9 provides a complete process of content operation:

Step 901: In response to the content deletion operation, delete the correspondence between the published content and the robot candidate set.

Step 902: In response to a content publishing operation, generate and publish a content robot candidate set.

Step 903: Generate a target task based on the published content and its corresponding time gradient information.

Step 904: Add the target task to the target queue based on the load balancing policy.

Step 905: The queue processing thread seizes the distributed lock of the target queue. If the lock is not obtained, it enters the sleep state for the first duration.

Step 906: After reaching the first duration, wake up the queue processing thread, and continue to seize the distributed lock after the queue processing thread wakes up.

Step 907: The queue processing thread seizes the distributed lock of the target queue. If the lock has been acquired, the lock renewal operation is performed every second time.

Step 908: Obtain the first n candidate tasks from the target queue through the target queue processing thread.

Step 909: Based on the order of n candidate tasks, compare the candidate time points indicated by the candidate tasks with the current time point in order to obtain the target task.

Step 910: If there is no target task, determine the sleep duration based on the candidate time point indicated by the first candidate task among the n candidate tasks and the current time point.

Step 911: Stop obtaining candidate tasks from the target queue during the sleep period.

Step 912: When the sleep duration is reached, continue to obtain candidate tasks from the target queue.

Step 913: If there is a target task, determine the target robot from the target robot candidate set corresponding to the target release content indicated by the target task.

Step 914: Use the target robot to perform operations on the target published content.

Step 915: After the operation, update the target robot candidate set by removing the target robot from the target robot candidate set.

Step 916: When the target robot candidate set is not empty, update the target time point and write the updated target task back to the target queue.

Step 917: If the target robot candidate set is empty, remove the target task from the target queue.

Please refer to Figure 10, which shows a structural block diagram of a content operating device provided by an embodiment of the present application. The device can be implemented as all or part of the server through software, hardware, or a combination of both. The device includes:

The acquisition module 1001 is configured to acquire n candidate tasks from the target queue. The candidate tasks are used to instruct the robot to perform operations on the candidate release content at the candidate time point, and n is a positive integer;

The first determination module 1002 is configured to determine a target task among the n candidate tasks, and the target time point indicated by the target task is no later than the current time point;

The second determination module 1003 is configured to determine the target robot from the target robot candidate set corresponding to the target published content indicated by the target task, and the target robot candidate set includes robots for performing operations on the target published content;

The operation module 1004 is configured to perform operations on the target published content through the target robot.

Optionally, the candidate tasks in the target queue are arranged in order of time points;

The acquisition module 1001 is configured as:

Obtain the first n candidate tasks in the target queue;

The first determination module 1002 is configured as:

Based on the arrangement order of the n candidate tasks, the candidate time points indicated by the candidate tasks and the current time point are sequentially compared to obtain the target task.

Optionally, the device also includes:

The first sleep module is configured to determine the sleep duration based on the candidate time point indicated by the first candidate task among the n candidate tasks and the current time point when the target task does not exist;

The acquisition module 1001 is configured as:

Within the sleep duration, stop obtaining the candidate tasks from the target queue;

When the sleep duration is reached, continue to obtain the candidate task from the target queue.

Optionally, the device also includes:

a robot removal module configured to remove the target robot from the target robot candidate set;

A task removal module configured to remove the target task from the target queue when the target robot candidate set is empty.

Optionally, the device also includes:

A task update module configured to update the target time point indicated by the target task based on the time gradient information corresponding to the target release content when the target robot candidate set is not empty, and the time gradient The information includes the time point at which the operation is performed on the target published content, and the target time point after the update is later than the target time point before the update;

Write the updated target task back to the target queue.

Optionally, the acquisition module 1001 is configured as:

The n candidate tasks are obtained from the target queue through a target queue processing thread, which has a target distributed lock corresponding to the target queue.

Optionally, the number of queue processing threads is greater than the number of queues;

The acquisition module 1001 is configured to acquire n items from the target queue through the target queue processing thread when the target queue processing thread preempts the target distributed lock corresponding to the target queue. The candidate tasks;

The device also includes:

The second sleep module is configured to control the target queue processing thread to enter a sleep state when the target queue processing thread does not seize the distributed lock, and the duration of the sleep state is the first time length;

The wake-up module is configured to wake up the target queue processing thread when the first duration is reached, wherein the wake-up target queue processing thread continues to seize the distributed lock.

Optionally, when the target queue processing thread preempts the target distributed lock corresponding to the target queue, the target queue processing thread performs a lock renewal operation every second time period;

When an exception occurs in the target queue processing thread, the target distributed lock is released.

Optionally, the device also includes:

A generation module configured to generate a first robot candidate set for the first published content in response to a content publishing instruction corresponding to the first published content, where the first robot candidate set includes information for performing operations on the first published content. robot;

The generation module is further configured to generate a first task corresponding to the first published content based on the first published content and the time gradient information corresponding to the first published content;

Add a module configured to add the first task to the queue based on the load balancing policy.

Optionally, the device also includes:

a deletion module configured to delete the corresponding relationship between the second published content and the second robot candidate set in response to a content deletion instruction corresponding to the second published content;

The deletion module is also configured to delete the second task corresponding to the second published content from the queue.

Optionally, the published content and the corresponding robot candidate set are stored in the redis cache in key-value format, where the key is the content identifier of the published content, and the value is the robot identifier of each robot in the robot candidate set;

Tasks are stored in the zset queue in the form of score-member, where score is the time point when the robot performs operations on the published content, and member is the content identifier of the published content.

An embodiment of the present application also provides a server. The server includes a processor and a memory. At least one program is stored in the memory. The at least one program is loaded and executed by the processor to implement the above embodiments. How to operate the content described above.

Embodiments of the present application also provide a computer-readable storage medium that stores at least one program, and the at least one program is executed by a processor to implement the content operation method as described in the above embodiments.

Embodiments of the present application provide a computer program product. The computer program product includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the server device executes the content operation method provided by the above embodiments.

Claims

A content operation method, wherein the method includes:

Obtain n candidate tasks from the target queue, the candidate tasks are used to instruct the robot to perform operations on the candidate release content at the candidate time point, n is a positive integer;

Determine the target task among the n candidate tasks, and the target time point indicated by the target task is no later than the current time point;

Determine the target robot from the target robot candidate set corresponding to the target published content indicated by the target task, and the target robot candidate set includes robots used to perform operations on the target published content;

The target posted content is acted upon by the target bot.
The method according to claim 1, wherein the candidate tasks in the target queue are arranged in order of time points;

Obtaining n candidate tasks from the target queue includes:

Obtain the first n candidate tasks in the target queue;

Determining the target task among the n candidate tasks includes:

Based on the arrangement order of the n candidate tasks, the candidate time points indicated by the candidate tasks and the current time point are sequentially compared to obtain the target task.
The method of claim 2, further comprising:

When the target task does not exist, determine the sleep duration based on the candidate time point indicated by the first candidate task among the n candidate tasks and the current time point;

Within the sleep duration, stop obtaining the candidate tasks from the target queue;

When the sleep duration is reached, continue to obtain the candidate task from the target queue.
The method according to any one of claims 1 to 3, wherein the method further includes:

Remove the target robot from the target robot candidate set;

If the target robot candidate set is empty, the target task is removed from the target queue.
The method according to claim 4, wherein after removing the target robot from the target robot candidate set, the method further includes:

When the target robot candidate set is not empty, the target time point indicated by the target task is updated based on the time gradient information corresponding to the target release content, where the time gradient information includes the The time point at which the target published content performs the operation, and the target time point after the update is later than the target time point before the update;

Write the updated target task back to the target queue.
The method according to any one of claims 1 to 3, wherein said obtaining n candidate tasks from the target queue includes:

The n candidate tasks are obtained from the target queue through a target queue processing thread, which has a target distributed lock corresponding to the target queue.
The method of claim 6, wherein the number of queue processing threads is greater than the number of queues;

The target queue processing thread obtains n candidate tasks from the target queue, including:

When the target queue processing thread preempts the target distributed lock corresponding to the target queue, obtain n candidate tasks from the target queue through the target queue processing thread;

The method also includes:

When the target queue processing thread does not seize the distributed lock, control the target queue processing thread to enter a sleep state, and the duration of the sleep state is the first time length;

When the first duration is reached, the target queue processing thread is awakened, wherein the awakened target queue processing thread continues to seize the distributed lock.
The method of claim 7, wherein

When the target queue processing thread preempts the target distributed lock corresponding to the target queue, the target queue processing thread performs a lock renewal operation on the pair every second period of time;

When an exception occurs in the target queue processing thread, the target distributed lock is released.
The method according to any one of claims 1 to 3, wherein the method further includes:

In response to a content publishing instruction corresponding to the first published content, generate a first robot candidate set for the first published content, where the first robot candidate set includes robots for performing operations on the first published content;

Generate a first task corresponding to the first published content based on the first published content and the time gradient information corresponding to the first published content;

The first task is added to the queue based on a load balancing policy.
The method according to any one of claims 1 to 3, wherein the method further includes:

In response to the content deletion instruction corresponding to the second published content, delete the corresponding relationship between the second published content and the second robot candidate set;

Delete the second task corresponding to the second published content from the queue.
The method according to any one of claims 1 to 3, wherein,

The published content and the corresponding robot candidate set are stored in the redis cache in the form of key-value, where the key is the content identifier of the published content, and the value is the machine of each robot in the robot candidate set. Robot identification;

Tasks are stored in the zset queue in the form of score-member, where score is the time point when the robot performs operations on the published content, and member is the content identifier of the published content.
A content operation device, wherein the device includes:

The acquisition module is configured to acquire n candidate tasks from the target queue. The candidate tasks are used to instruct the robot to perform operations on the candidate release content at the candidate time point, and n is a positive integer;

The first determination module is configured to determine a target task among the n candidate tasks, and the target time point indicated by the target task is no later than the current time point;

The second determination module is configured to determine the target robot from the target robot candidate set corresponding to the target published content indicated by the target task, and the target robot candidate set includes robots for performing operations on the target published content;

An execution operation module is configured to perform an operation on the target published content through the target robot.
A server, wherein the server includes a processor and a memory; at least one program is stored in the memory, and the at least one program is loaded and executed by the processor to implement any one of claims 1 to 11 Content operation method.
A computer-readable storage medium, wherein the computer-readable storage medium stores at least one program, and the at least one program is used to be executed by a processor to implement the content operation method as described in any one of claims 1 to 11 .
A computer program product, wherein the computer program product includes computer instructions, the computer instructions are stored in a computer-readable storage medium; a processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes The computer instructions enable the computer device to implement the content operation method as described in any one of claims 1 to 11.