WO2016127854A1

WO2016127854A1 - Information processing method and device

Info

Publication number: WO2016127854A1
Application number: PCT/CN2016/073144
Authority: WO
Inventors: 于君泽
Original assignee: 阿里巴巴集团控股有限公司; 于君泽
Priority date: 2015-02-09
Filing date: 2016-02-02
Publication date: 2016-08-18
Also published as: CN105991571B; CN105991571A

Abstract

Provided are an information processing method and device, the method comprising: generating a hot-spot account that corresponds to an activity, wherein the hot-spot account comprises a pre-set number of detail records, the detail records comprising an identifier of the activity, the identifiers of the detail records, the states of the detail records and a subject matter parameter; in response to an access request sent by a user with regard to the activity, searching for a corresponding current detail record for each user from the hot-spot account, wherein the state of the current detail record is idle; and allocating the current detail record to the corresponding user, and updating the state of the current detail record to be occupied. In this way, the technical problem in the prior art that the capability of an application server processing concurrent accesses is limited in a scenario of very high millisecond concurrent amount can be solved.

Description

Information processing method and device

Technical field

The present application relates to the field of network data processing, and in particular, to an information processing method and device.

Background technique

With the rapid development of information technology, the interaction of digital electronic means using electronic and electronic technology has become more and more popular. During the interaction process, there may be a situation in which a large number of users concurrently access the same application account, causing the accessed account to become a hotspot account. If the concurrent access volume cannot be reduced, the response speed of the application to the user access may be reduced, and even the case where the user cannot respond may be encountered. , affecting the user's access experience. +

At present, most of the hot-spot accounts are used to reduce the concurrent access volume of hotspot accounts. For example, in the case of a red envelope in a marketing business, a hot account with a hot account of 1 million yuan can be split into 100 sub accounts, and activity information is configured for each sub account to form a sub account. For the configuration list, refer to the schematic diagram shown in Figure 1. When the client user receives the red envelope through the application page, the application server can be triggered to assign a specified activity to the user from 100 activities, and route the user's access to the specified activity, so that the user corresponds to the child corresponding to the specified activity. Red envelopes are collected from the account. For example, the application server routes user A to activity 003, and user A can receive red packets from sub-account 003.

In the above solution, if the second-level concurrency of the red envelope account is tens of thousands of users, the second-level concurrency of each sub-account can be reduced to hundreds of users. However, the premise of the implementation of the above solution requires the + operator to make a precise estimation of the business needs and split the red envelope account into a reasonable number of sub-accounts.

If the number of split sub-accounts is large, the cost of the activity information configuration will be increased, and the correctness check between the plurality of sub-accounts will increase the configuration complexity and consume the processing resources of the application server.

If the number of split sub-accounts is small, the second-level concurrency of each sub-account may still be high during the activity, and it is necessary to urgently issue a re-split account instruction to the application server to further split each sub-account. Will inevitably affect the current activities, and In the process of splitting again, not only the activity information configuration, the correctness check of the split account, but also a large amount of data migration is involved. The implementation process is complicated and difficult, and the processing resources of the application server are still consumed.

In addition, in the above scheme for splitting hotspot accounts, in order to ensure the thread security of concurrent access, the application processor uses a lock method for the user to modify the hotspot account data, that is, only one user is allowed to read and Modify the data of the hotspot account.

For example, the above-mentioned red envelope is used as an example. Whether it is for the 1 million yuan red envelope account before the split or the 10,000 yuan sub-account after the split, when there are multiple users concurrent access, the lock problem will be involved. For example, three users A, B, and C concurrently access the sub-account 003, and the three users are routed to the sub-account 003 by the application server, and the timestamps are sequentially ranked as A, B, and C. Then, the user A reads the sub-account 003. The account balance, when receiving the red envelope, will lock the sub-account 003, prohibiting users B and C from reading the account balance of the sub-account 003, and only after the user A receives and modifies the account balance of the sub-account 003, the sub-account 003 is unlocked, allowing Other users read the account balance of sub-account 003.

The above is only a case of locking processing when three users concurrently access, for a brief introduction. In practical applications, the number of concurrent concurrency may be tens of thousands of users. If the application server cannot process or release these users in time, Concurrent access, as the workload continues to increase, the application server is likely to be dragged.

In summary, the scheme of splitting the hotspot account can reduce the concurrent access volume of the sub-account to a certain extent, but the locking problem will still severely limit the ability of the application server to respond to concurrent access.

Summary of the invention

The technical problem to be solved by the present application is to provide an information processing method for solving the technical problem that the application server has limited concurrent access capability in a scenario where the second-level concurrency is high.

The present application also provides an information processing apparatus for ensuring the implementation and application of the above method in practice.

In order to solve the above problem, the present application discloses an information processing method, including the following steps:

Generating a hotspot account corresponding to the activity, where the hotspot account includes a detailed record of the preset number of items, The detailed record includes an identifier of the activity, an identifier of the detailed record, a status of the detailed record, and a target parameter;

Responding to an access request sent by the user for the activity, searching for a corresponding current detail record for each user from the hotspot account, the status of the current detail record is idle;

Assigning the current detail record to the corresponding user, and updating the status of the current detail record to occupy.

Correspondingly, the present application also discloses an information processing apparatus, the apparatus comprising:

a generating unit, configured to generate a hotspot account corresponding to the activity, where the hotspot account includes a preset number of detailed records, where the detailed record includes an identifier of the activity, an identifier of the detailed record, a status of the detailed record, and Subject parameter

a searching unit, configured to search for a corresponding current detail record for each user from the hotspot account in response to an access request sent by the user for the activity, where the status of the current detail record is idle;

And an allocating unit, configured to allocate the current detailed record found by the searching unit to a corresponding user, and update the status of the current detailed record to occupy.

Compared with the prior art, the present application includes the following advantages:

In the account configuration phase, the application does not need to perform account splitting, activity information configuration, and sub-account correctness check as in the prior art, and only needs to generate a detailed record with no difference in the preset bar, and the generation process is simple and easy to implement, and can be solved. The prior art is a technical problem of a large amount of consumption of application server processing resources caused by reducing the second-level concurrency of hotspot accounts.

In addition, in the activity stage, the present application converts the behavior of processing the user's parallel access request into a process of matching the detailed record, and does not need to modify the account data in real time, thereby ensuring the thread security of concurrent access and helping to improve the application server. The ability to respond to concurrent access.

DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present application. Other drawings may also be obtained from those of ordinary skill in the art in view of the drawings.

1 is a schematic diagram of a sub-account configuration list in the prior art;

2 is a flowchart of Embodiment 1 of an information processing method of the present application;

Figure 3 is a schematic diagram of a detailed record in the present application;

Figure 4 is another schematic diagram of the detailed record in the present application;

5 is a flowchart of Embodiment 2 of an information processing method of the present application;

Fig. 6 is a block diagram showing the structure of an information processing apparatus of the present application.

detailed description

The technical solutions in the embodiments of the present application are clearly and completely described in the following with reference to the drawings in the embodiments of the present application. It is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

Referring to FIG. 2, a flowchart of Embodiment 1 of the information processing method of the present application is shown, which may include the following steps:

Step 101: Generate a hotspot account corresponding to the activity, where the hotspot account includes a preset number of detail records, where the detailed record includes an identifier of the activity, an identifier of the detailed record, a status of the detailed record, and a target object parameter.

In the solution of the embodiment of the present application, a detailed record with no difference in the preset bar may be generated according to the activity requirement, and the detailed record may include an activity identifier, a detailed record identifier, a detailed record status, and a target parameter. Specifically, the activity identifier may be an activity name and/or an activity ID; the detail record identifier may be a detail record name and/or a detail record ID; the detail record status may be idle or occupied, wherein if the detail record is assigned to the user, The state is occupied, otherwise the state is idle, usually the initial state of the detail record is idle; the target parameter can be the number of objects, usually for different activities, the object parameters can be expressed in different forms, for example, if The activity is to grab the red envelope. The target parameter can be the red envelope amount, for example, 5 yuan, 10 yuan, etc.; if the activity is to grab the goods, the target parameter can be the quantity of the goods purchased. If the goods are mobile phones, the target parameter can be 1 set. , 2 sets, etc. In a practical application, the specific expression form of the information included in the detailed record may not be specifically limited in the embodiment of the present application. As an example, the detailed record can be embodied as the schematic shown in FIG.

It should be noted that the application server can set the target parameters according to the default configuration, or The application server can set the target parameter according to the manual configuration of the operator. The embodiment of the present application does not specifically limit this. Generally, the application server does not set the target parameter in real time according to the information input by the client user. For example, the application server can set the red envelope amount of all the detailed records to 5 yuan, or the red envelope amount of all the detailed records can be set to 10 yuan; or, the red envelope amount of a part of the detailed records can be set to 5 yuan. Set the red envelope amount of another part of the detailed record to 10 yuan; however, usually the application server does not respond to the client user in real time, and sets the red envelope amount according to the value entered by the user.

In addition, it should be noted that the identifier of the activity is used to indicate which specific activity the detail record corresponds to. When the application server routes the user to the hotspot account and assigns the detailed record to the user in the subsequent processing process, the application may further verify the application by using the identifier of the activity. The accuracy of server routing. As an example, if the accuracy of the routing is not high, or only the only activity is currently performed, the identification of the activity may not be included in the detailed record. Of course, in order to ensure the accuracy of the routing of the application server, the activity record is included in the detailed record. The logo is optimal.

The detailed record of generating a preset bar without difference in the embodiment of the present application means that no distinction is made between each detailed record, and the detailed record can be allocated to the user as long as the detailed record is in an idle state. The preset number may be a preset number specified, for example, specifying that 10,000 detailed records are generated; or, the preset number may also be a calculated number obtained according to the total allocation number, the generation factor, and the target parameter, for example, The total distribution number is 1 million yuan red envelope, the generation factor is 0.8, and the target parameter is 5 yuan, then the calculation knows to generate 100*0.8/5=160,000 detailed records. It should be noted that the generation factor may be set randomly, or the generation factor may be set according to the experience of other related activities. Further, the generation factor may be set according to the historical data of the previous year of the activity, which may be specifically limited in this embodiment of the present application. .

In summary, in the account configuration stage before the activity starts, the embodiment of the present application does not need an application server to perform account splitting, and does not need to perform activity information configuration for each sub-account, and does not need to perform correctness check between each sub-account. It is only necessary to generate a detailed record with no difference in the preset bar. The generation process is simple and easy to implement, and the processing resources of the application server can be saved. In this way, the technical problem that the prior art reduces the amount of concurrent concurrency of the hotspot account and consumes a large amount of application server processing resources is solved.

Step 102, in response to an access request sent by the user for the activity, from the hotspot account In the household, each user is searched for a corresponding current detail record, and the status of the current detail record is idle.

Step 101 is mainly directed to the account configuration phase before the activity starts. Once the account configuration is completed, after the activity is started, the application server can directly perform step 102 to respond to the user's access request.

For example, the client user can view the activity page, and can send an access request to the application server by clicking or touching. The application server can receive the access request sent by the user, and can perform information processing according to the solution in the embodiment of the present application. For example, in the case of double 11 red envelopes, the activity page can display a 5 yuan red envelope collection button and a 10 yuan red envelope collection button. When user A clicks the 10 yuan red envelope collection button, an access request is sent to the application server, and the access request is used to indicate User A requests to receive a $10 red envelope for the Double 11 event.

Optionally, after receiving the access request, the application server may first authenticate the identity of the user A, the behavior of the user A to receive the red envelope, and the amount of the user A requesting to receive the red envelope. After the authentication is passed, the application server follows the application. Apply the embodiment scheme for information processing.

Specifically, in the embodiment of the present application, the information processing process of the application server may be implemented as: determining a hotspot account corresponding to the activity that the user participates in, and searching for a detailed record of the idle state for each user from the hotspot account, as The current detail record assigned to the user.

As an example, if only one user currently sends an access request to the application server, the application server may determine a current detail record for the user from all the detail records in which the hotspot account is in an idle state.

For example, the application server may randomly determine the current detailed record from all the detailed records in the idle state. For example, the detailed records with IDs of 10 to 20 are all idle, and the application server may randomly record the detailed records with the ID of 12. Determined as the current detail record. Alternatively, the application server may determine, in all the detailed records in the idle state, the detailed records with the largest ID or the smallest ID as the current detailed records. For example, the detailed records with the IDs of 10 to 20 are in the idle state, and the application server may set the minimum ID. A detailed record of 10 is determined as the current detail record. Alternatively, the application server may determine, according to the preset matching rule, a current detailed record matching the user ID from all the detailed records in the idle state, for example, the user ID is 123456, and the detailed records with IDs of 10-20 are in the Idle state, if the matching rule is the detail record ID The last bit is the same as the last digit of the user ID, and the application server can determine the detail record with ID 16 as the current detail record. Specifically, the embodiment of the present application determines the manner of the current detailed record, the specific implementation means of each mode, and the like, which are not limited by the application server.

As an example, if multiple users currently send an access request to the application server concurrently, the application server may determine at least one current content for each user from all the detailed records of the hotspot account in an idle state in at least three ways as described below. Detailed record. Here are three explanations for the application server to determine the current detail record. For details, please refer to the following.

Step 103: Assign the current detailed record to the corresponding user, and update the status of the current detailed record to occupy.

Whether it is single-user access or multi-user concurrent access, the application server can assign a corresponding current detail record to each user. It can be understood that assigning the current detailed record to the corresponding user refers to establishing a correspondence between the current detailed record and the corresponding user. For example, the

detailed records

10, 11, 12 are sequentially assigned to the users A, B, and C. If the

detailed records

10, 11, 12 are represented as shown in FIG. 3, step 103 assigns the current detailed records to the corresponding user representations. User A receives a red envelope of 5 yuan, user B receives a red envelope of 5 yuan, and user C receives a red envelope of 10 yuan. If the

detailed records

10, 11, and 12 appear as shown in FIG. 4, step 103 assigns the current detailed record to the corresponding one. The user indicated that users A, B and C snapped up one mobile phone respectively.

In the embodiment of the present application, each detailed record can be uniquely assigned to only one user. Therefore, after establishing the correspondence between the current detailed record and the corresponding user, the status of the current detailed record can be updated, and the idle status is changed to the occupied status. To indicate that the detail record has been assigned to the user.

In summary, the embodiment of the present application converts the behavior of the user to receive the red envelope or snapped up the product into a matching detailed record processing process, and does not need to modify the account balance or the number of remaining commodities in real time, thereby ensuring the thread safety of concurrent access and helping. Improve the ability of the application server to respond to concurrent access.

It should be noted that the solution of the embodiment of the present application is mainly directed to a marketing service, but is essentially a technical problem that is solved in the process of implementing the business by using technical means.

For the steps mentioned in step 102, the application server determines three ways of the current detail record, which are explained below.

Implementation one

If the identifier of the detail record included in the hotspot account adopts an auto-increment design, the application server may determine the current detail record in the following manner: obtain the detailed record identifier assigned to each user by the cache server, and the identifier is the cache server according to each user. The timestamps of the sending access requests are sorted and assigned according to the self-incrementing design; according to the identifiers, each user is searched for a corresponding current detailed record.

In order to prevent the concurrent users from preempting the same detailed record and implementing the lock-free processing, the embodiment of the present application may allocate a detailed record identifier to each user according to the order of the timestamps of the access request sent by the user through the cache server. In this example, The identifier of the detail record can be embodied as a detail record ID. For example, the current value of a detail record ID can be maintained in the distributed cache server. When user A and B access concurrently, if user A arrives first with B, the current value (+1) can be assigned to user A. At the same time, the cache server maintains (current value +1). When user B arrives, it assigns (current value +2) to user B and continues to maintain (current value +2). By the way, when the other user sends an access request to the application server, the cache server can assign a corresponding detail record ID to each user. The specific process is not described here. As an example, the cache server can assign each user a corresponding detail record ID through redis' incr operation: redis->incr('preRecordNum_activity001'). It should be noted that, in the above example, the value of the self-incremental variable is set to 1. In a specific application, the value of the self-incrementing variable may be set as needed, and the embodiment of the present application may not specifically limit this.

For example, the cache server allocates a detailed record ID of 10 for user A, and a detailed record ID of 11 for user B, and the application server can establish a correspondence between user A and a detailed record with ID 10 according to the The correspondence between the user B and the detailed record with the ID of 11 is established. According to the schematic diagram shown in FIG. 3, the user A can receive a red envelope of 5 yuan, and the user B can receive a red envelope of 5 yuan.

Implementation 2

The application server can determine the current detail record as follows: Send access based on each user The timestamps of the requests are sorted, and each user is searched for a corresponding current detail record in order from all the detailed records in which the hotspot account is in an idle state.

In order to prevent the concurrent users from preempting the same detailed record and implementing the lock-free processing, the embodiment of the present application may sequentially assign a corresponding current detailed record to each user according to the order of the timestamps of the access requests sent by the user. For example, the detailed records with IDs of 10 to 20 are in idle state. Users A and B concurrently access, and user A arrives with respect to B first. The application server can be random, from all the detailed records in the idle state, in order. Users A and B each determine a current detail record. For example, the ID of the current detail record determined for user A is 10, and the ID of the current detail record determined for user B is 12. Alternatively, the application server may sort according to the size of the detail record ID, and sequentially determine a current detail record for each of the users A and B. For example, the detail records are arranged in ascending order of the ID, and the ID of the current detail record determined for the user A is 10, which is the user. The ID of the current detail record determined by B is 11; or, the detailed records are arranged in descending order of ID, the ID of the current detail record determined for user A is 20, and the ID of the current detail record determined for user B is 19.

Optionally, the implementation manner 2 can also cooperate with the implementation manner 1 to determine a corresponding current detailed record for the user, which can be embodied by: the application server can first use the implementation manner 1 to determine the current detailed record for the user by using the cache server. When the cache server is faulty, the second implementation mode is used to determine the current detail record for the user. For example, the application server can determine whether the cache server is faulty by monitoring the heartbeat of the cache server.

Implementation mode three

The application server may determine the current detail record in the following manner: obtaining a detailed record of the specified number of pieces from all the detailed records in which the hotspot account is in an idle state; using the identification of each user, the detailed record from the specified number of pieces In the middle, a corresponding current detail record is determined for each user.

In order to prevent concurrent users from preempting the same detailed record and implementing lock-free processing, the embodiment of the present application may first capture the detailed records of the specified number from all the detailed records in the idle state, and then combine the user IDs according to the A certain matching rule determines a corresponding current detail record for each user from the specified number of detailed records. For example, if the number of specified records is 10 and the ID records with IDs from 001 to 100 are idle, the application server captures the details. The ID of the fine record is 001 to 010. If the ID of user A is 123456 and the ID of user B is 654321, the matching rule is: based on the specified digit of the user ID, the current detail record corresponding to the user is determined in the captured detail record. The location in . For example, if the specified bit is the penultimate bit of the user ID, the current detail record corresponding to the user A in the captured detail record is 5, that is, the detail record with the ID 005; the current detail record corresponding to the user B. The position in the captured detail record is 2, that is, the detail record with ID 002.

It should be noted that, in this embodiment, multiple matching rules may be set in sequence. If the current matching rule cannot be used to determine the detailed record for the user, the next matching rule may be used to perform detailed record matching until the user is determined to correspond. Current detail record. Alternatively, if a plurality of detailed records are determined for the user by using the current matching rule, the current detailed record may be randomly determined from the determined plurality of detailed records, or the corresponding current detailed record may be determined for the user in combination with other matching rules. This embodiment of the present application may not specifically limit this, as long as a current detailed record is determined for each user.

For example, the matching rule in the embodiment of the present application may be: matching the specified bit of the user ID and the detailed record ID, so that the two are the same or have a preset corresponding relationship, which may be specifically limited in this application.

Referring to FIG. 5, a flowchart of Embodiment 2 of the information processing method of the present application is shown, which may include the following steps:

Step 201: Generate a hotspot account corresponding to the activity, where the hotspot account includes a preset number of detailed records, where the detailed record includes an identifier of the activity, an identifier of the detailed record, a status of the detailed record, and a subject matter parameter.

For the implementation process of step 201, refer to step 101 shown in FIG. 2 above, and details are not described herein again.

Step 202: Determine, according to the access request sent by the user for the activity, whether the number of the detailed records of the hotspot account in an idle state is lower than a preset value, and if no, perform step 203.

The embodiment of the present application is directed to a scenario in which the number of concurrent transmissions is very high. In order to avoid the insufficient allocation of detailed records, that is, the number of detailed records in the idle state is smaller than the number of concurrently accessed users, the application server allocates a corresponding number for each user. Before the current detail record, It is first determined whether the number of detailed records currently in the idle state is lower than a preset value, and if not lower than the preset value, the step of determining the current detailed record for the user may be continued.

For example, the preset value may be a preset specified value. For example, if the specified value is 100, that is, when the number of the detailed records of the hotspot account in the idle state is greater than 100, the execution may determine the current details for the user. The steps of recording. Alternatively, the preset value may be a preset ratio, for example, the ratio is 20%, that is, when the number of the detailed records of the hotspot account in the idle state is greater than 20% of the preset number, the execution may be continued to determine the current for the user. The steps for detail recording. Alternatively, the preset value may be the number of concurrently accessed users. For example, the number of concurrently accessed users is 100. That is, when the number of detailed records of the hotspot account in the idle state is greater than 100, the current detailed record may be determined for the user. A step of.

Step 203: Find, from the hotspot account, a corresponding current detail record for each user, where the status of the current detail record is idle.

Step 204: Assign the current detailed record to the corresponding user, and update the status of the current detailed record to occupy.

For the implementation process of the

steps

203 and 204, refer to the

steps

102 and 103 shown in FIG. 2 above, and details are not described herein again.

Optionally, the hotspot account further includes a pre-allocated number and/or an unallocated number, and when it is determined in step 202 that the number of the detailed records of the hotspot account in the idle state is lower than a preset value, the application server may further perform the following steps: determining the location Whether the unallocated number is greater than zero, and if so, generating a new detailed record by using the unallocated number, and performing the searching for a corresponding current detailed record for each user.

In the embodiment of the present application, the pre-allocation number refers to the sum of the object parameters of the predetermined number of detailed records, and the unallocated number refers to the difference between the total number of allocations and the pre-allocated number. For example, in the above article, the total redemption activity is 1 million yuan, the generation factor is 0.8, and the red envelope amount is 5 yuan. The pre-allocation number corresponding to 160,000 detailed records is 16*5=800,000 yuan. The unallocated number is 100-80=200,000 yuan.

If the unallocated number is greater than zero, it indicates that the red envelope or the commodity currently has a margin, and can be combined with the unallocated number to continue to generate a new detailed record, which is allocated by the server. It should be noted that The server may first determine the current detailed record for the user from the remaining detailed records (ie, the detailed records in the idle state of the predetermined number of detailed records), and determine the current detailed record for the user from the new detailed record when insufficient. . Alternatively, the application server may first determine the current detail record for the user from the new detail record, and then determine the current detail record for the user from the remaining detail records when insufficient. Alternatively, the application server may not distinguish between the remaining detail records and the new detail records, and directly determine the current detail records for the user.

Optionally, as an example, the application server may also determine whether the pre-allocated number is less than the total allocation number, and if yes, generate a new detailed record by using the unallocated number, and then perform the method to find a corresponding current for each user. Detailed record. For the specific process, refer to the scheme introduced above for the unallocated number, and details are not described herein again.

Optionally, if it is determined that the unallocated number is equal to zero, or the pre-allocated number is equal to the total allocated number, in order to increase the speed of processing the user request, the application server may also calculate the number of detailed records in the idle state and the number of users concurrently accessed. The difference is sorted according to the timestamp of the concurrent access user sending the access request, and the activity end page is directly fed back to the user who matches the difference and is sorted backward (ie, the user who is not assigned the detailed record). For example, the remaining three records in the red envelope account are in the idle state. Currently, five users concurrently send access requests to the application server, and the five users are sorted by timestamps in order of 1, 2, 3, 4, and 5. Corresponding to this, the application server can respectively assign a current detail record to users 1, 2 and 3, that is, users 1, 2 and 3 respectively receive a red envelope, and at the same time, the application server can also return red packets to users 4 and 5. End page. In this way, the time for the application server to respond to users 4 and 5 can be shortened, and the user experience of users 4 and 5 can be improved.

In summary, in the embodiment of the present application, when the allocation is insufficient, a new detailed record can be generated according to the actual situation, and the data migration is not involved in the process, and the ongoing activity, the existing detailed record, and the established The correspondence between the detail record and the user has an influence.

Optionally, the embodiment of the present application may further include a settlement step after the activity ends. For example, for the redemption activity, the settlement step refers to calculating the red envelope balance; for the grab product activity, the settlement step refers to calculating the number of remaining products. Specifically, the embodiment of the present application provides the following two settlement implementation manners:

In the first implementation manner, the application server releases all the detailed records in the hotspot account that are in an idle state, and updates as follows: the pre-allocation number is zero, the unallocated number = the total allocation number - all the target parameters of the detailed records in the occupied state with. Among them, the unallocated number is the settlement value.

In the second implementation mode, the application server calculates the settlement value=unallocated number+the sum of the target parameters of all the detailed records in the idle state.

Corresponding to the method provided in Embodiment 1 of the information processing method of the present application, referring to FIG. 6, the present application further provides an embodiment 1 of an information processing apparatus. In this embodiment, the apparatus may include:

The generating unit 301 is configured to generate a hotspot account corresponding to the activity, where the hotspot account includes a preset number of detailed records, where the detailed record includes an identifier of the activity, an identifier of the detailed record, and a status of the detailed record And target parameters;

The searching unit 302 is configured to, according to the access request sent by the user for the activity, search for a corresponding current detail record for each user from the hotspot account, where the status of the current detail record is idle;

The allocating unit 303 is configured to allocate the current detailed record found by the searching unit to the corresponding user, and update the status of the current detailed record to occupy.

The locating unit can determine a corresponding current detail record for each user according to the solution introduced in the method embodiment, and details are not described herein again.

For the multi-user concurrent access, the searching unit in the embodiment of the present application may be embodied in the following three implementation manners:

In a first implementation manner, if multiple users send an access request concurrently, and the identifier of the detailed record adopts an auto-increment design, the searching unit includes:

a first obtaining unit, configured to obtain a detailed record identifier allocated by the cache server for each user, where the identifier is sorted according to a timestamp of each user sending an access request, and is allocated according to an auto-increment design;

The first search subunit is configured to find, for each user, a corresponding current detail record according to the identifier.

In a second implementation manner, if multiple users send an access request concurrently, the searching unit includes:

The second search sub-unit is configured to sort the timestamps of the access requests sent by each user, and sequentially search for a corresponding current detailed record for each user from all the detailed records in which the hotspot account is in an idle state.

In a third implementation manner, if multiple users send an access request concurrently, the searching unit includes:

a second obtaining unit, configured to obtain a detailed record of the specified number of pieces from all the detailed records in which the hotspot account is in an idle state;

And a third search subunit, configured to determine, by using the identity of each user, a corresponding current detail record for each user from the specified record of the specified number of records.

Optionally, based on the foregoing solution, the device further includes:

a first determining unit, configured to determine, before the searching unit searches for the current detailed record, whether the number of detailed records in which the hotspot account is in an idle state is lower than a preset value, and if not, notifying the searching unit to search The current detail record.

Optionally, if the number of the detailed records of the hotspot account in an idle state is lower than the preset value, and the hotspot account further includes a pre-allocated number and/or an unallocated number, the pre-allocated number is the And the unassigned number is the difference between the total number of allocations and the pre-allocated number, and the device further includes:

a second determining unit, configured to determine, when the number of the detailed records in which the hotspot account is in an idle state, is lower than the preset value, whether the unallocated number is greater than zero, and if yes, generate the unallocated number a new detail record, and notifying the lookup unit to find the current detail record; or,

a third determining unit, configured to determine, when the number of the detailed records of the hotspot account in an idle state is lower than the preset value, whether the pre-allocated number is less than the total allocation number, and if yes, using the The unassigned number generates a new detail record and notifies the lookup unit to look up the current detail record.

The application also provides a smart device, the aforementioned information processing device is integrated on the processor of the smart device.

It should be noted that each embodiment in the specification is described in a progressive manner, and each embodiment focuses on differences from other embodiments, and the same similar parts between the embodiments are referred to each other. can. For system class embodiments, due to its method The embodiments are basically similar, so the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.

Finally, it should also be noted that in this context, relational terms such as first and second are used merely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply these entities. There is any such actual relationship or order between operations. Furthermore, the term "comprises" or "comprises" or "comprises" or any other variations thereof is intended to encompass a non-exclusive inclusion, such that a process, method, article, or device that comprises a plurality of elements includes not only those elements but also Other elements, or elements that are inherent to such a process, method, item, or device. An element that is defined by the phrase "comprising a ..." does not exclude the presence of additional equivalent elements in the process, method, item, or device that comprises the element.

The information pushing method and device provided by the present application are described in detail above. The principles and implementation manners of the present application are described in the specific examples. The description of the above embodiments is only used to help understand the method of the present application. And the core ideas of the present invention; at the same time, those skilled in the art, according to the idea of the present application, there will be changes in the specific embodiments and application scopes. In summary, the contents of this specification should not be construed as limits.

Claims

An information processing method, characterized in that the method comprises the following steps:

Generating a hotspot account corresponding to the activity, where the hotspot account includes a predetermined number of detailed records, the detailed record including an identifier of the activity, an identifier of the detailed record, a status of the detailed record, and a target parameter;

Responding to an access request sent by the user for the activity, searching for a corresponding current detail record for each user from the hotspot account, the status of the current detail record is idle;

Assigning the current detail record to the corresponding user, and updating the status of the current detail record to occupy.
The method according to claim 1, wherein if a plurality of users send an access request concurrently, and the identifier of the detailed record adopts an auto-increment design, the user searches for a corresponding current detailed record for each user, specifically :

Obtaining, by the cache server, a detailed record identifier assigned to each user, where the identifier is sorted according to a timestamp of each user sending an access request, and is allocated according to an auto-increment design;

According to the identifier, each user is searched for a corresponding current detail record.
The method according to claim 1, wherein if a plurality of users concurrently send an access request, the user searches for a corresponding current detail record for each user, specifically:

According to the timestamp order of each user sending the access request, each user is searched for a corresponding current detail record in all the detailed records in which the hotspot account is in an idle state.
The method according to claim 1, wherein if a plurality of users concurrently send an access request, the user searches for a corresponding current detail record for each user, specifically:

Obtaining a detailed record of the specified number of entries from all the detailed records in which the hotspot account is in an idle state;

Using each user's identity, a corresponding current detail record is determined for each user from the specified number of detailed records.
The method according to any one of claims 1 to 4, wherein before the finding a corresponding current detail record for each user, the method further comprises:

Determining whether the number of detailed records in which the hotspot account is in an idle state is lower than a preset value, If not, then perform a search for each user to find a corresponding current detail record.
The method according to claim 5, wherein the hotspot account further comprises a pre-allocated number and/or an unallocated number, wherein the pre-allocated number is a sum of object parameters of the predetermined number of detailed records. And the unallocated number is the difference between the total number of allocations and the pre-allocated number, and the method further includes: when the number of the detailed records of the hotspot account being in an idle state is lower than the preset value, the method further includes:

Determining whether the unallocated number is greater than zero, and if yes, generating a new detailed record by using the unallocated number, and performing the searching for a corresponding current detailed record for each user;

or,

Determining whether the pre-allocated number is less than the total allocation number, and if so, generating a new detailed record by using the unallocated number, and performing the searching for a corresponding current detailed record for each user.
An information processing apparatus, characterized in that the apparatus comprises:

a generating unit, configured to generate a hotspot account corresponding to the activity, where the hotspot account includes a preset number of detailed records, where the detailed record includes an identifier of the activity, an identifier of the detailed record, a status of the detailed record, and Subject parameter

a searching unit, configured to search for a corresponding current detail record for each user from the hotspot account in response to an access request sent by the user for the activity, where the status of the current detail record is idle;

And an allocating unit, configured to allocate the current detailed record found by the searching unit to a corresponding user, and update the status of the current detailed record to occupy.
The apparatus according to claim 7, wherein if the plurality of users concurrently send an access request, and the identifier of the detailed record adopts an auto-increment design, the searching unit comprises:

a first obtaining unit, configured to obtain a detailed record identifier allocated by the cache server for each user, where the identifier is sorted according to a timestamp of each user sending an access request, and is allocated according to an auto-increment design;

The first search subunit is configured to find, for each user, a corresponding current detail record according to the identifier.
The apparatus according to claim 7, wherein if a plurality of users are concurrently issued Sending an access request, the searching unit includes:

The second search sub-unit is configured to sort the timestamps of the access requests sent by each user, and sequentially search for a corresponding current detailed record for each user from all the detailed records in which the hotspot account is in an idle state.
The apparatus according to claim 7, wherein if a plurality of users concurrently send an access request, the searching unit comprises:

a second obtaining unit, configured to obtain a detailed record of the specified number of pieces from all the detailed records in which the hotspot account is in an idle state;

And a third search subunit, configured to determine, by using the identity of each user, a corresponding current detail record for each user from the specified record of the specified number of records.
The device according to any one of claims 7 to 10, wherein the device further comprises:

a first determining unit, configured to determine, before the searching unit searches for the current detailed record, whether the number of detailed records in which the hotspot account is in an idle state is lower than a preset value, and if not, notifying the searching unit to search The current detail record.
The device according to claim 11, wherein the hotspot account further comprises a pre-allocated number and/or an unallocated number, wherein the pre-allocated number is a sum of object parameters of the predetermined number of detailed records. The unallocated number is the difference between the total number of allocations and the pre-allocated number, and the device further includes:

a second determining unit, configured to determine, when the number of the detailed records in which the hotspot account is in an idle state, is lower than the preset value, whether the unallocated number is greater than zero, and if yes, generate the unallocated number a new detail record, and notifying the search unit to find the current detail record;

or,

a third determining unit, configured to determine, when the number of the detailed records of the hotspot account in an idle state is lower than the preset value, whether the pre-allocated number is less than the total allocation number, and if yes, using the The unassigned number generates a new detail record and notifies the lookup unit to look up the current detail record.